第5章 ステータスおよびヘルス・モニタリング
システム・ヘルス・チェックおよびモニタリング・データは、問題検出の基盤です。 必要なトラブルシューティングおよびデバッグ情報はすべて単一のデータ・ストアで保持されるため、問題を調査する必要がある場合、個々のコンポーネントから収集する必要はありません。 システムの全体的な健全性は1箇所で取得されます: Grafana。
Oracleでは、デフォルトのダッシュボードおよびアラートがGrafanaに構築されており、Lokiに格納されているログを参照するためのメカニズムも構築されています。 お客様はこの設定を拡張およびカスタマイズすることを希望する場合がありますが、これはOracle Private Cloud Applianceドキュメントの範囲を超えています。
この機能の実装の詳細および技術的なバックグラウンド情報は、「Oracle Private Cloud Appliance概要ガイド」を参照してください。 「アプライアンス管理の概要」の章の「ステータスおよびヘルス・モニタリング」の項を参照してください。
5.1 Grafanaの使用
Grafanaを使用すると、管理者は、システムのすべてのレベルおよびすべてのコンポーネント全体で収集されたログおよびメトリックに対して、単一の視覚的指向のインタフェースを提供します。 この項では、Grafanaにアクセスし、ログおよびモニタリング・ダッシュボードをナビゲートするための基本的なガイドラインについて説明します。
-
サービスWeb UIを開き、ログインします。
-
ダッシュボードの右側にあるMonitoringタイルをクリックします。
Grafanaホーム・ページが新しいブラウザ・タブで開きます。 プロンプトが表示されたら、ユーザー名およびパスワードを入力します。
ログおよびメトリックがPrometheusに格納されると、アプライアンスの時間およびタイムゾーン設定に基づいてタイムスタンプが割り当てられます。 ただし、Grafanaは、ユーザー・プリファレンスに基づいて時間を表示します。異なるタイム・ゾーンにあるため、オフセットが発生する可能性があります。 Grafanaビジュアライゼーションのタイムラインをアプライアンスのタイムゾーンと同期することをお勧めします。
-
Grafanaホーム・ページを開きます。
-
左側のメニュー・バーで、(下部近くにある)ユーザー・アカウント・アイコンをクリックして、アカウント・プリファレンスを表示します。
-
プリファレンス・セクションで、タイムゾーン設定をアプライアンスと同じタイムゾーンに変更します。
-
下の保存ボタンをクリックして変更を適用します。
Oracle Private Cloud Applianceの事前定義済ダッシュボードは、Grafanaホーム・ページから直接アクセスすることはできませんが、最も使用頻度の高いダッシュボードは後でホーム・ページに表示されるように星付けできます。 ダッシュボードは、メイン・メニューのダッシュボード・セクションからアクセスするフォルダで構成されています。
-
左側のメニュー・バーで、Dashboards(ダッシュボード)をポイントし、Manage(管理)を選択します。
フォルダまたはダッシュボード・セットのリストが表示されます。
-
フォルダをクリックすると、そのフォルダに含まれるダッシュボードのリストが表示されます。 ダッシュボードをクリックしてそのコンテンツを表示します。
-
フォルダとダッシュボードのリストに戻るには、ステップ1で行ったようにメニュー・バーを使用します。
「マイ・サウロン(読取り専用)」ダッシュボード・セットを除き、すべての事前定義済ダッシュボードおよびパネルは設計によって編集可能です。 これらは、モニターする特定のメトリックを使用して変更することも、独自のメトリックを作成することもできます。 アラートにも同様です。
アラートは別の領域で管理されます。 Oracleには、利便性のために一連のアラートが事前に定義されています。
-
左側のメニュー・バーで、Alerting(ベル・アイコン)をクリックします。
現在のステータスを含む、定義されているすべてのアラート・ルールのリストが表示されます。
-
アラート・ルールをクリックして詳細パネルを表示し、そのステータスが時間の経過とともにどのように変化し、アラートしきい値に対する相対的なかを確認します。
-
アラート・ルールのリストに戻るには、ステップ1で行ったようにメニュー・バーを使用します。
-
アラート通知を構成するには、アラート・ページの「通知チャネル」タブに移動します。
独自の外部通知チャネルを使用してカスタム・アラートを構成する場合は、まずSauron APIエンドポイントを使用してGrafanaのプロキシを構成する必要があります。 これを行うには、管理仮想IPを所有する管理ノードにログインし、次のコマンドを実行します:
$ sudo curl -u<admin_user_name>
\ -XPUT 'https://api.<mypca>
.example.com/v1/grafana/proxy/config?http-proxy=<proxy_fqdn>:<proxy_port>
&https-proxy=<proxy_fqdn>:<proxy_port>
' Enter host password for user '<admin_user_name>
': Grafana proxy config successfully updated!
最後に、Grafanaは、Loki経由で集計されるアプライアンス・ログへのアクセスも提供します。 詳細は、第5.4項、「システム・ログへのアクセス」を参照してください。
5.2 ハードウェアおよびプラットフォーム・コンポーネントの健全性およびステータスの確認
ハードウェア層とプラットフォーム層は、システムアーキテクチャの基礎を形成します。 このレベルの異常な条件は、インフラストラクチャ・サービス内の操作に悪影響を及ぼすことが予想されます。 多数の事前定義済Grafanaダッシュボードを使用すると、これらの重要な下位レベルのコンポーネントのステータスを確認し、関連するメトリックのリアルタイムおよび履歴の詳細にドリルダウンできます。
この項で説明するダッシュボードは、基本的なシステム・ヘルス・チェックのスタート・ポイントと、問題が見つかった場合のトラブルシューティングに役立ちます。 かわりに、様々なダッシュボード、メトリックおよびビジュアライゼーションを使用することをお薦めします。 システム全体で収集される必要なデータはPrometheusに格納され、Grafanaを介して無数の方法で問合せおよび表示できます。
Grafanaフォルダ |
ダッシュボード |
説明 |
---|---|---|
サービスのモニタリング |
サーバー統計 |
この包括的なダッシュボードには、サーバー・ノードのテレメトリ・データが表示されます。 これには、CPUおよびメモリー使用率、ディスク・アクティビティ、ネットワーク・トラフィックなどのグラフが含まれます。 このダッシュボードの一部のパネルでは、1つのグラフに多数の「シリーズ」が表示されるため、1つのグラフをクリックして表示するか、グラフ上にカーソルを置いて時間軸の特定のポイントの詳細データを表示できます。 |
PCA 3.0サービス・アドバイザ |
プラットフォームのヘルス・チェック |
このダッシュボードは、アプライアンスのヘルス・チェック・メカニズムを、Grafanaがロギングおよびモニタリング用に提供する集中型アプローチに統合します。 デフォルトでは、Platform Health Checkダッシュボードに、すべてのヘルス・チェック・サービスの失敗が表示されます。 プラットフォーム・サービスのリストからヘルス・チェッカを選択してパネルの表示を変更でき、正常、異常またはすべての結果を表示するように選択できます。 通常、ヘルス・チェックの失敗が表示された場合は、トラブルシューティングを開始します。 そのため、各ヘルス・チェック結果には、関連するLokiログへの直接リンクとして機能するタイム・スタンプが含まれます。 ヘルス・チェックの結果に関連するログを表示するには、タイム・スタンプをクリックするだけです。 |
マイ・サウロン(読取り専用) |
ノード・エクスポータがいっぱいです |
このダッシュボードには、1つのコンピュートまたは管理ノードに対して多数の詳細なメトリック・パネルが表示されます。 リストからホストを選択してデータを表示します。 このダッシュボードは、サーバー統計ダッシュボードのファイングレイン拡張とみなすことができます。 さまざまなパネルでは、サーバー・ノードのハードウェア・ステータスとオペレーティング・システムのサービスとプロセスの詳細なカバレージが提供されます。 通常、各物理ノードのコマンド行で収集する情報は、1つのダッシュボードにまとめられ、ライブ・データとその推移が表示されます。 My Sauron (読取り専用)フォルダのすべてのダッシュボードには、システム・レベルの障害を解決する必要がある場合に重要なデータが表示されます。 したがって、これらのダッシュボードは変更または削除できません。 |
5.3 モニタリング・データの表示および解釈
プラットフォーム上に構築され、すべてのクラウド・ユーザーおよび管理者機能を有効にするインフラストラクチャ・サービス・レイヤーは、Grafanaダッシュボードの広範なコレクションで監視できます。 これらのマイクロサービスは、Kubernetesコンテナの3つの管理ノードにまたがってデプロイされるため、モニタリングは主にKubernetesノードおよびポッド・メトリックに基づきます。 Kubernetesクラスタもコンピュート・ノードに拡張され、Kubernetesワーカー・ノードはシステム操作およびモニタリングのために重要な追加データを収集します。
この項で説明するダッシュボードは、マイクロサービス・ヘルス・モニタリングの開始点となります。 かわりに、様々なダッシュボード、メトリックおよびビジュアライゼーションを使用することをお薦めします。 システム全体で収集される必要なデータはPrometheusに格納され、Grafanaを介して無数の方法で問合せおよび表示できます。
Grafanaフォルダ |
ダッシュボード |
説明 |
---|---|---|
サービスのモニタリング |
ClusterLabs HAクラスタの詳細 |
このダッシュボードでは、特注のPrometheusエクスポータを使用して、Pacemakerに基づいてHAクラスタのデータを表示します。 各HTTPリクエストでは、クラスタ・コンポーネント・ツールによって提供される既存の分散データを解析することで、クラスタ・ステータスをローカルで検査します。 モニタリング・データには、Pacemakerクラスタ・サマリー、ノードとリソース統計、Corosyncリング・エラーおよび定足数投票が含まれます。 |
サービスのモニタリング |
MySQLクラスタ・エクスポータ |
このダッシュボードには、MySQLデータベース・クラスタのパフォーマンス詳細が表示されます。 データには、稼働時間、接続統計、表ロック数などのデータベース・サービス・メトリック、およびMySQLオブジェクト、接続、ネットワーク・トラフィック、メモリーおよびCPU使用率に関するより一般的な情報が含まれます。 |
サービスのモニタリング |
サービス・レベル |
このダッシュボードには、基本的なアプライアンス・サービスによって受信されたRabbitMQリクエストに関する詳細情報が表示されます。 リクエスト数、リクエスト・レイテンシ、およびエラーの原因となったリクエストを監視できます。 |
サービスのモニタリング |
VM統計 |
この包括的なダッシュボードには、環境内のコンピュート・インスタンス全体のリソース消費情報が表示されます。 これには、CPUおよびメモリー使用率、ディスク・アクティビティ、ネットワーク・トラフィックなどのグラフが含まれます。 このダッシュボードのパネルには、1つのグラフに多数の「シリーズ」が表示されるため、1つのグラフをクリックして表示するか、グラフ上にカーソルを置いて時間軸の特定のポイントの詳細データを表示できます。 |
PCA 3.0サービス・アドバイザ |
Kubeエンドポイント |
このダッシュボードは、特にKubernetesエンドポイントに焦点を当て、エンドポイント・アラートを提供します。 これらのアラートは、選択した通知チャネルに送信できます。 |
PCA 3.0サービス・アドバイザ |
Kube Ingress |
このダッシュボードでは、Kubernetesサービスとそのポッドへのイングレス・トラフィックに関するデータが提供されます。 2つのアラートが組み込まれており、選択した通知チャネルに送信できます。 |
PCA 3.0サービス・アドバイザ |
Kubeノード |
このダッシュボードには、Kubernetesクラスタおよびホスト・マイクロサービス・ポッドに属するすべてのサーバー・ノード(管理およびコンピュート・ノード)のメトリック・データが表示されます。 ポッド数、CPUおよびメモリー使用量などを監視できます。 メトリック・パネルには、すべてのノードに関する情報が表示されます。 グラフ・ベースのパネルでは、クリックすると1つのノードだけの情報を表示できます。 |
PCA 3.0サービス・アドバイザ |
Kube Pod |
このダッシュボードには、マイクロサービス・ポッドのレベルでメトリック・データが表示され、ポッドの合計数およびそれらをノード間でどのように分散しているかを表示できます。 ネームスペースごとおよびサービスごとにステータスをモニターし、アラートがトリガーされたかどうかを確認できます。 |
PCA 3.0サービス・アドバイザ |
Kubeサービス |
このダッシュボードには、Kubernetesサービス・レベルのメトリック・データが表示されます。 データは特定のサービスに対してフィルタ処理できますが、デフォルトではすべてが表示されます。 2つのアラートが組み込まれており、選択した通知チャネルに送信できます。 |
Kubernetesモニタリング Kubernetesコンテナのモニタリング Kubernetesモニタリング・ノード |
(all) |
これらのフォルダには、広範なモニタリング・データを含む、大量のダッシュボード・コレクションが含まれます。Kubernetesクラスタの実質的にすべての側面について説明します。 データは、クラスタ、ノード、ポッドおよびコンテナ・レベルのKubernetesを対象としています。 メトリックは、デプロイメント、イングレス、CPU、ディスク、メモリーおよびネットワークの使用状況などについてのインサイトを提供します。 |
5.4 システム・ログへのアクセス
ログはシステム全体から収集され、Lokiで集計されます。 Grafanaの中央インタフェースを使用して、すべてのログ・データの問合せ、フィルタ処理および表示できます。
-
Grafanaホーム・ページを開きます。
-
左側のメニュー・バーで、エクスプローラ(コン・パス・アイコン)をクリックします。
デフォルトでは、ページの参照データ・ソースはPrometheusに設定されています。
-
ページ上部の左側にあるデータ・ソース・リストから「Loki」を選択します。
-
ログ・ラベル・リストを使用して、ログを問い合せてフィルタします。
ログはラベルに分類され、特定のタイプまたはカテゴリのログ・エントリを表示するために問合せできます。 Oracle Private Cloud Appliance内で使用される主なログ・ラベル・カテゴリは次のとおりです:
-
job
このカテゴリのログ・ラベルは、次の3つのカテゴリに分類されます:
-
プラットフォーム: アプライアンス・アーキテクチャの基礎レイヤーで実行されているサービスおよびコンポーネントからのログ。
このカテゴリのログ・ラベルには次が含まれます:
"him"
/"has"
/"hms"
(ハードウェア管理)、"api-server"
、"vault"
/"etcd"
(シークレット・サービス)、"corosync"
/"pacemaker"
/"pcsd"
(管理クラスタ)、"messages" (RabbitMQ)"pca-platform-l0"
、"pca-platform-l1api"
など。 -
インフラストラクチャ・サービス: プラットフォーム上にデプロイされたユーザー・レベルのクラウド・サービスおよび管理サービスからのログ。 これらのサービスは、名前で簡単に識別できます。
このカテゴリのログ・ラベルには次が含まれます:
"brs"
(バックアップ/リストア)、"ceui"
(コンピュートWeb UI)、"seui"
(サービスWeb UI)、"compute"
、"dr-admin"
(ディザスタ・リカバリ)、"filesystem"
、"iam"
(アイデンティティおよびアクセス管理)、"pca-upgrader"
など。 -
標準出力: コンテナ化されたインフラストラクチャ・サービスが
stdout
ストリームに送信したことをログに記録します。 この出力は、ユーザーがUI操作またはCLIコマンドを実行すると表示されます。ログ・ラベル
job="k8s-stdout-logs"
を使用して、標準出力ログをフィルタ処理します。 ログ・データはマイクロサービスのKubernetesコンテナから取得され、ポッドまたはコンテナ名(あるいはその両方)を指定してさらにフィルタできます。
-
-
k8s_app
このカテゴリのログ・ラベルを使用すると、標準出力ログを絞り込むことができます(
job="k8s-stdout-logs"
)。 そのログ・データはマイクロサービスのKubernetesコンテナから取得され、関心のある特定のサービスの名前に対応するラベルを選択してさらにフィルタできます。
job
またはk8s_app
ログ・ラベルのいずれかを選択して、ログをナビゲートします。 目的のサービスまたはアプリケーションに対応するラベルを選択し、ログのリストが時系列で逆に表示されます。 ログ・エントリの上に表示されている時間行の一部にズーム・インすることで、検索を絞り込むことができます。 カラー・コーディングは、注意が必要なアイテムを識別するのに役立ちます。たとえば、: 警告は黄色でマークされ、エラーは赤でマークされます。
監査ログ
監査ログは、個別のカテゴリとして参照できます。 ログ・ラベル・リストから、次の監査ラベルを選択できます:
-
job="vault-audit"
このログ・ラベルを使用して、ボールト・クラスタの監査ログをフィルタします。 シークレット・サービスのキー・コンポーネントであるボールトは、すべてのリクエストおよびレスポンスの詳細なログを保持します。 認証されたすべてのボールトとの相互作用(エラーを含む)を表示できます。 これらのログには機密情報が含まれているため、秘密情報が監査ログでプレーン・テキストで表示されないように、リクエストおよびレスポンス内の多くの文字列がハッシュされます。
-
job="kubernetes-audit"
このログ・ラベルを使用して、Kubernetesクラスタの監査ログをフィルタします。 Kubernetes監査ポリシーがリクエスト・メタデータを記録するように構成されています: ユーザー、タイム・スタンプ、リソース、動詞などのリクエスト・リクエスト本文およびレスポンス本文は監査ログには含まれません。
-
job="audit"
このログ・ラベルを使用して、Oracle Linuxカーネル監査デーモンのログをフィルタします。 カーネル監査デーモン(auditd)は、Linux監査システムのユーザー空間コンポーネントです。 システム・ログイン、アカウント変更、sudo操作などの特定のイベントを取得します。
-
log="audit"
このログ・ラベルを使用して、ZFSストレージ・アプライアンスの監査ログをフィルタ処理します。
リストのログ・ラベルを使用する以外に、カスタム問合せを作成することもできます。 たとえば、管理サービスおよびAPIサービスの監査ログをフィルタするには、ログ・ラベル・リストの横にあるフィールドに次の問合せを入力します:
{job=~"(admin|api-server)"} | json tag="tag" | tag=~"(api-audit.log|audit.log)"
実行するには、右上隅の問合せの実行ボタンをクリックするか、Shift
+ Enter
を押します。
5.5 自動サービス・リクエストの使用
Oracle Private Cloud ApplianceはOracle Auto Service Request (ASR)に対して修飾されています。 ASRは、サポートを目的としたソフトウェア機能です。 My Oracle Supportと統合されており、特定のハードウェア障害が発生したときにサービス・リクエストを自動的にオープンすることで、問題を迅速に解決できるようにします。 ASRの使用はオプションです: アプライアンスのサービスを登録して有効にする必要があります。
5.5.1 Oracle Auto Service Request (ASR)の理解
ASRは、特定のOracle Private Cloud Applianceハードウェア障害が発生したときにサービス・リクエストを自動的に開くように設計されています。 この機能を有効にするには、Oracle Private Cloud Applianceを構成して、ハードウェア障害テレメトリをOracleに直接(https://transport.oracle.com)、プロキシ・ホストまたは別のエンドポイントに送信する必要があります。 たとえば、データセンターにASR Managerソフトウェアがインストールされている場合、複数のシステムの集約ポイントとして別のエンドポイントを使用できます。
ハードウェアの問題が検出されると、ASRはサービス・リクエストをOracle Support Servicesに送信します。 多くの場合、管理者が問題を認識する前に、Oracleサポート・サービスで問題の解決作業を開始できます。
ASRは、ディスク、ファン、電源供給などの最も一般的なハードウェア・コンポーネントで障害を検出し、障害が発生するとサービス・リクエストを自動的に開きます。 ASRは、可能性のあるすべてのハードウェア障害を検出せず、顧客データセンター内のほかのモニタリング・メカニズム(SMTPアラートなど)を置き換えるものではありません。 交換ハードウェアの発送を促進および簡素化する補完メカニズムです。 ASRは、高優先度システムのダウンタイム・イベントに使用することはできません。 高優先度イベントの場合は、Oracleサポート・サービスまで直接ご連絡ください。
My Oracle Supportの電子メール・アカウントとOracle Private Cloud Applianceの技術的連絡先の両方に電子メール・メッセージが送信され、サービス・リクエストが作成されたことが通知されます。 サービス・リクエストは、場合によっては自動的に提出されないことがあります。 これは、SNMPプロトコルの信頼性が低いか、ASRへの接続が失われたために発生することがあります。 Oracleでは、サービス・リクエストが自動的に送信されたことが通知されない場合、顧客は障害の発生を監視し、Oracle Support Servicesをコールすることをお薦めしています。
ASRの詳細は、次のリソースを参照してください。
-
Oracle Auto Service Request webページ : http://www.oracle.com/technetwork/systems/asr/overview/index.html。
-
Oracle Auto Service Requestユーザー・ドキュメント: http://docs.oracle.com/cd/E37710_01/index.htm。
5.5.2 ASRの前提条件
ASRサービスに登録する前に、このセクションの前提条件が満たされていることを確認してください。
-
有効なMy Oracle Supportアカウントがあることを確認してください。
必要に応じて、https://support.oracle.comでアカウントを作成します。
-
My Oracle Supportで、次の項目が正しく設定されていることを確認します。
-
Oracle Private Cloud Applianceを担当する顧客サイトの技術担当者
-
Oracle Private Cloud Applianceが設置されている顧客サイトの有効な出荷先住所。これにより、部品を設置する必要があるサイトに配送します。
-
-
HTTPSを使用してインターネットへの接続を確認します。
たとえば、https://support.oracle.comにアクセスできるかどうかをテストするために
curl
を試行します。
5.5.3 ASR用のOracle Private Cloud Applianceの登録
ASRクライアントを登録するには、Oracle Private Cloud Applianceを、ハードウェア障害の遠隔監視をOracleに3つの方法(https://transport.oracle.comで直接、プロキシ・ホストまたは別のエンドポイント)のいずれかに送信するように構成する必要があります。 たとえば、データセンターにASR Managerソフトウェアがインストールされている場合、複数のシステムの集約ポイントとして別のエンドポイントを使用できます。
ASRにOracle Private Cloud Applianceを登録すると、サービスは自動的に有効になります。
サービスWeb UIの使用
-
ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。
-
「登録」ボタンをクリックします。
-
ユーザー名とパスワードを入力し、選択したフォン・ホーム構成のフィールドに入力します。
-
Username*: My Oracle Supportから取得できるOracle Single Sign On (SSO)資格証明を入力します。
-
Password*: SSOアカウントのパスワードを入力します。
-
プロキシ・ユーザー名: プロキシ・ホストを使用するには、そのホストにアクセスするためのユーザー名を入力します。
-
プロキシ・パスワード: プロキシ・ホストを使用するには、そのホストにアクセスするためのパスワードを入力します。
-
プロキシ・ホスト: プロキシ・ホストを使用するには、そのホストの名前を入力します。
-
プロキシ・ポート: プロキシ・ホストを使用するには、ホストへのアクセスに使用するポートを入力します。
-
エンドポイント: オプションで、アグリゲーション・ポイントまたはその他のエンドポイントをASRデータ統合に使用する場合は、そのエンドポイントを次の形式で入力します:
http://<host>[:<port>]/asr
*必須フィールド
-
サービスCLIの使用
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientRegister
カスタム・コマンドを使用して、アプライアンスを登録します。PCA-ADMIN> asrClientRegister username=asr-pca3_ca@example.com \ password=******** confirmPassword=******** \ endpoint=https://transport.us.oracle.com/ \ Command: asrClientRegister username=asr-pca3_ca@example.com \ password=***** confirmPassword=***** \ endpoint=https://transport.us.oracle.com/ Status: Success Time: 2021-07-12 18:47:14,630 UTC
-
構成を確認します。
PCA-ADMIN> show asrPhonehome Command: show asrPhonehome Status: Success Time: 2021-09-30 13:08:42,210 UTC Data: Is Registered = true Overall Enable Disable = true Username = asr.user@example.com Endpoint = https\://transport.us.oracle.com/ PCA-ADMIN>
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientRegister
カスタム・コマンドを使用して、アプライアンスを登録します。PCA-ADMIN> asrClientRegister username=asr-pca3_ca@oracle.com \ password=******** confirmPassword=******** \ proxyHost=zeb proxyPort=80 \ proxyUsername=support \ proxyPassword=**** proxyConfirmPassword=**** \
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientRegister
カスタム・コマンドを使用して、アプライアンスを登録します。PCA-ADMIN> asrClientRegister username=oracle_email@example.com \ password=******** confirmPassword=******** \ endpoint=https://transport.us.oracle.com/ \ Command: asrClientRegister username=oracle_email@example.com \ password=***** confirmPassword=***** \ endpoint=https://transport.us.oracle.com/ Status: Success Time: 2021-07-12 18:47:14,630 UTC
5.5.4 ASR構成のテスト
構成したら、ASR構成をテストして、エンド・ツー・エンドの通信が適切に機能していることを確認できます。
-
ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。
-
ControlsメニューでTest Registrationを選択します。
-
Test Registrationをクリックします。 テストが成功したかどうかを確認するダイアログが表示されます。
-
テストのステータスが成功でない場合は、ASR構成情報を確認し、テストを繰り返します。
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientsendTestMsg
カスタム・コマンドを使用して、ASR構成をテストします。PCA-ADMIN> asrClientsendTestMsg Command: asrClientsendTestMsg Status: Success Time: 2021-12-08 18:43:30,093 UTC PCA-ADMIN>
5.5.5 ASRのOracle Private Cloud Applianceの登録を解除しています
ASRのOracle Private Cloud Applianceを登録解除すると、サービスは自動的に無効になるため、そのステップを実行する必要はありません。
-
ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。
-
Unregisterボタンをクリックします。 プロンプトが表示されたら、操作を確認します。
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientUnregister
カスタム・コマンドを使用して、アプライアンスを登録します。PCA-ADMIN> asrClientUnregister Command: asrClientUnregister Status: Success Time: 2021-06-23 15:25:18,127 UTC PCA-ADMIN>
5.5.6 ASRの無効化
システムのメンテナンス時、またはその他の状況では、システムを登録解除せずに、構成済みのエンドポイントへの障害メッセージのフローを停止するために、アプライアンス上のASRを一時的に無効にする場合があります。
-
ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。
-
「無効化」ボタンをクリックします。 プロンプトが表示されたら、操作を確認します。
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientDisable
カスタム・コマンドを使用して、ASRサービスを停止します。PCA-ADMIN> asrClientDisable Command: asrClientDisable Status: Success Time: 2021-06-23 15:26:17,753 UTC PCA-ADMIN>
5.5.7 ASRの有効化
アプライアンスでASRを無効にしている場合は、次のいずれかのメソッドを使用してASRサービスを再起動します。
-
ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。
-
「有効化」ボタンをクリックします。 プロンプトが表示されたら、操作を確認します。
-
SSHを使用して、管理ノードVIPに
root
としてログインします。# ssh -l admin 100.96.2.32 -p 30006
-
asrClientEnable
カスタム・コマンドを使用して、ASRサービスを起動します。PCA-ADMIN> asrClientEnable Command: asrClientEnable Status: Success Time: 2021-06-23 15:26:47,632 UTC PCA-ADMIN>