ステータスおよびヘルス・モニタリング

モニタリング

組み込みの健全性検査とは関係なく、管理者はいつでもモニタリングデータを参照して、システムの全体的なステータスや特定のコンポーネントまたはサービスの状態を確認できます。これは、Prometheusに格納されたシステム全体のメトリック・データを問い合せることによって、Grafanaインタフェースを介して行われます。

Grafanaは、監視に視覚的なアプローチを提供します。これにより、多数のビジュアライゼーション・パネルで構成されるダッシュボードを作成できます。各パネルは、選択した形式で表示される単一のメトリック問合せまたはメトリック問合せの組合せに対応します。オプションには、グラフ、表、チャート、ダイアグラム、ゲージなどがあります。メトリック・パネルごとに、しきい値を定義できます。問合せ結果が指定のしきい値を超えたり下回ったりすると、表示の色が変わり、どの要素が正常であるか、調査が必要であるか、または誤動作しているかをすばやく確認できます。

管理者は、一連の事前定義済ダッシュボードを使用して、システムを起動して実行するとすぐにシステムの監視を開始できます。デフォルトのモニタリング・ダッシュボードは、次のカテゴリにグループ化されます。

デフォルトのダッシュボードには、システムの物理コンポーネント(サーバー、スイッチ、ストレージ・プロバイダ、オペレーティング・システムおよびファームウェア)のメトリック・データに加え、その論理コンポーネント(コントローラ・ソフトウェア、プラットフォーム、Kubernetesクラスタおよびマイクロサービス、コンピュート・インスタンスおよび仮想化リソース)が含まれます。これにより、管理者またはサポート・エンジニアは、両方のコンポーネント・カテゴリのヘルス・ステータスを個別に検証し、それらの間の相関関係を検索できます。たとえば、特定のマイクロサービスは、使用可能なメモリーが不足しているためパフォーマンスが低下する可能性があります。モニタリングデータは、これがシステム構成の問題、物理リソースの不足、またはハードウェア障害の症状であるかどうかを示します。モニタリングシステムには、ハードウェア障害を検出して報告できるアラートサービスがあります。管理者はオプションで、モニタリング・システムで定義されたルールに基づいてアラートを受信するように通知チャネルを構成できます。

サービスおよびサポート操作の一環として、Oracleでは、デフォルトのダッシュボードに表示される特定のメトリック・データをレポートするよう求められる場合があります。このため、デフォルトのダッシュボード構成は常に保持する必要があります。ただし、監視機能の一部が誤って変更または破損している場合は、デフォルトをリストアできます。同様に、Oracleでは、新しいダッシュボードを作成したり、監視を改善するために既存のダッシュボードを変更したり、正式なアップグレード手順を必要とせずにそれらを運用環境にプッシュできます。

ここで説明するすべてのオープン・ソースのモニタリングおよびロギング・ツールには、顧客が既存のヘルス・モニタリングおよびアラート・システムと統合できるパブリックAPIがあります。ただし、Oracleでは、このようなカスタム構成はサポートされません。

フォルト・ドメインの監視

アプライアンス・インフラストラクチャ、コンピュート・インスタンスおよびそれらの関連リソースを正常な状態で稼働させる場合、フォルト・ドメインは非常に重要な概念です。これは、障害またはメンテナンスによる停止時間イベントを分離することを目的として、インフラストラクチャ・コンポーネントのセットをグループ化し、他のフォルト・ドメインのリソースが影響を受けないようにします。

Oracle Cloud Infrastructureに沿って、Private Cloud Applianceには常に3つのフォルト・ドメインがあります。各フォルト・ドメインは、1つ以上の物理コンピュート・ノードに対応します。Grafanaを使用してシステム全体の監視データを調べる以外に、管理者はサービス・エンクレーブから直接フォルト・ドメインの主要な容量メトリックにアクセスすることもできます。

• フォルト・ドメイン当たりのコンピュート・ノード数

• フォルト・ドメイン当たりのRAMの合計および使用可能な量

• フォルト・ドメイン当たりのvCPUsの合計数および使用可能な数

• 未割当てのシステムCPUおよびRAM容量

フォルト・ドメイン・メトリックは、コンピュート・ノードでホストされているコンピュート・インスタンスによって消費できる実際の物理リソースを反映します。合計には、ハイパーバイザの操作用に予約されたリソース(40GB RAMおよび4 CPUコア(8 vCPUs)は含まれません。

3つの障害ドメインに加えて、サービス CLIには「Unassigned」カテゴリが表示されます。これは、プロビジョニングされていない、したがってまだフォルト・ドメインの一部ではない、インストール済のコンピュート・ノードを参照します。未割当ての計算ノードの場合、メモリー容量は計算できませんが、CPUメトリックが表示されます。

システムの健全性検査

ヘルス・チェックは最も基本的な検出形式です。これらは、通常のUNIX cronジョブに非常に似ているKubernetes CronJobサービスとして定期的に実行されます。ステータス・エントリは、すべてのヘルス・チェック結果に対して作成されます。これは、常に、正常または非正常の2つの可能性のいずれかです。すべてのステータス情報は、Prometheusでさらに処理するために保存されます。異常な結果では、トラブルシューティング・プロセスの進行に役立つ詳細を含むログ・エントリもLokiに生成されます。

ヘルス・チェックは、特定のシステム・コンポーネントのステータスを検証し、ステータス変更を検出することを目的としています。各ヘルス・チェック・プロセスは、現在の状態を記録し、期待される結果と比較するという同じ基本原則に従います。一致した場合、ヘルス・チェックは通過します。一致しない場合、ヘルス・チェックは失敗します。ステータスが正常から正常ではないに変更された場合は、トラブルシューティングが必要であることを示します。

トラブルシューティングの目的で、2つの主要なデータ・ソース(ログとメトリック)を使用できます。どちらのカテゴリのデータもシステム全体から収集され、中央の場所に格納されます。ログはLokiで集計され、Prometheusのメトリックです。どちらのツールにも、データをフィルタおよびビジュアル化できる問合せインタフェースがあり、どちらもGrafanaと統合できます。ブラウザベースのインタフェースには、サービスWeb UIからアクセスできます。

ヘルス・チェックが失敗する原因を調査するために、失敗のタイプに基づいてログおよびメトリック・データをフィルタ処理するのに役立ちます。Lokiは、ラベリング・システムでデータを分類し、選択したログ・ラベルに一致するログ・メッセージを表示します。リストからラベルを選択して、目的のサービスまたはアプリケーションのログを表示します。このリストでは、ヘルス・チェックだけでなく、内部および外部のアプライアンス・サービスも選択できます。

また、Grafanaにデフォルトで用意されているサービス・アドバイザ・ダッシュボード・セットの一部であるプラットフォーム・ヘルス・チェック・ダッシュボードには、各ヘルス・チェックの最新ステータスが表示されます。

Private Cloud Applianceでは、次に示すヘルス・チェックが実行されます。

集中ロギング

このプラットフォームは、システム全体の統合ロギングを提供します。Fluentdデータ・コレクタは、システム全体のコンポーネントからログを取得し、アプライアンスのテレメトリ・データとともに中央の場所に格納します。その結果、必要なすべてのトラブルシューティングおよびデバッグ情報が1つのデータ・ストアに保持されるため、問題を調査する必要がある場合は、様々なソースから収集する必要はありません。システムの全体的な状態は、1つのビュー(Grafanaダッシュボード)で取得されます。つまり、管理者が個々のコンポーネントをチェックする必要はありません。

Oracleからの支援を必要とする問題が見つかった場合、管理者はサービス・リクエストをログに記録します。通常、サポートバンドルはそのプロセスの一部として要求されます。集中管理されたロギングのおかげで、サポートバンドルは簡単に生成でき、システム操作が著しく危険にさらされた場合でも引き続き可能です。サポート・バンドルの生成は、単一の圧縮アーカイブ・ファイルを生成するスクリプト化された操作です。管理者は、統合ログおよびその他の診断データを含むアーカイブ・ファイルを手動でアップロードする必要があります。

Private Cloud ApplianceがASRに登録されると、特定のハードウェア障害によってサービス・リクエストが発生し、診断データがOracleサポートに自動的に送信されます。