機械翻訳について

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

システムの全体的なヘルス・ステータスは、ハードウェアおよびプラットフォーム・レイヤーからのリアルタイム・データを使用して継続的に監視されます。 システム・ヘルス・チェックおよびモニタリング・データは、問題検出の基盤です。 異常な状態が見つかると、管理者はこの情報を使用してトラブルシューティングを開始します。 必要に応じて、問題の解決を支援するためにサービス・リクエストをOracleに登録します。 Private Cloud ApplianceがOracle Auto Service Request (ASR)に登録されている場合、特定のハードウェア障害によって、サービス・リクエストおよび診断データがOracleサポートに自動的に送信されます。

モニタリング

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

Grafanaは、モニタリングに対する視覚的なアプローチを提供: 複数のビジュアライゼーション・パネルで構成されるダッシュボードを作成できます。 各パネルは、選択した形式で表示される単一のメトリック問合せまたはメトリック問合せの組合せに対応します。 オプションには、グラフ、表、チャート、図、ゲージなどが含まれます。 メトリック・パネルごとに、しきい値を定義できます。 問合せ結果が特定のしきい値を上回ったり下がったりすると、表示色が変わり、どの要素が正常であるか、調査が必要であるか、または機能不全であるかがすばやくわかります。

Oracleには事前定義済のダッシュボードのセットが用意されており、管理者はシステムの起動および実行直後にシステムのモニタリングを開始できます。 デフォルトのモニタリング・ダッシュボードは、次のカテゴリにグループ化されます:

モニタリング・ダッシュボード・セット	説明
サービス・アドバイザ	Kubernetesコンテナ・オーケストレーション環境、ホストするコンテナ化されたサービス、およびシステム・ヘルス・チェック・サービスをモニタリングするためのアプライアンス固有のダッシュボード・コレクション。
サービス・レベルのモニタリング	すべてのマイクロサービスの統計データを提供する、ダッシュボードの読取り専用コレクション。
Kubernetesモニタリング	Oracleクラウド・ネイティブ・モニタリングおよびビジュアライゼーションの専門家が提供するダッシュボードの追加コレクション。 これらは、Kubernetesクラスタとそのサービスに関する膨大な詳細情報を提供します。

デフォルトのダッシュボードには、システムの物理コンポーネントのメトリック・データが含まれます - サーバー、スイッチ、ストレージ・プロバイダ、およびそのオペレーティング・システムとファームウェア - 論理コンポーネント - コントローラ・ソフトウェア、プラットフォーム、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」には「未割当て」カテゴリが表示されます。 これは、プロビジョニングされていないためにまだフォルト・ドメインの一部ではないインストール済コンピュート・ノードを参照します。 割り当てられていないコンピュート・ノードの場合、メモリー容量は計算できませんが、CPUメトリックが表示されます。

システム・ヘルス・チェック

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

ヘルス・チェックは、特定のシステム・コンポーネントのステータスを検証し、ステータスの変更を検出するためのものです。 各ヘルス・チェック・プロセスは、同じ基本原則に従います: 現在の条件を記録し、予想結果と比較します。 一致した場合、ヘルス・チェックは合格します。異なる場合、ヘルス・チェックは失敗します。 ステータスが正常から「健全でない」に変更された場合、トラブルシューティングが必要であることを示します。

トラブルシューティングのために、自由に使用できる主要なデータ・ソースが2つあります: ログおよびメトリック。 両方のカテゴリのデータがシステム全体から収集され、中央のロケーションに格納されます: ログはLokiに集計され、メトリックはPrometheusに集計されます。 どちらのツールにも、データのフィルタ処理およびビジュアル化を可能にする問合せインタフェースがあります: 両方ともGrafanaと統合されています。 ブラウザベースのインタフェースには、「サービスWeb UI」からアクセスできます。

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

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

Private Cloud Applianceは、次に示すヘルス・チェックを実行します。

ヘルス・チェック・サービス	説明
cert-checker	証明書が期限切れでないことを各管理ノードで検証します。
flannel-checker	Flannelコンテナ・ネットワーク・サービスが各Kubernetesノードで完全に動作していることを確認します。
kubernetes-checker	Kubernetesノードおよびポッドのヘルス・ステータス、およびコンテナ化されたサービスとその接続エンドポイントを検証します。
mysql-cluster-checker	MySQLクラスタ・データベースのヘルス・ステータスを確認します。
l0-cluster-services-checker	低レベルのクラスタリング・サービスおよびハードウェアおよびプラットフォーム・レイヤー内の主要な内部コンポーネント(プラットフォームAPI、DHCPなど)が完全に動作していることを確認します。
network-checker	システム・ネットワーク構成が正しいことを確認します。
registry-checker	コンテナ・レジストリが各管理ノードで完全に動作していることを確認します。
vault-checker	各管理ノードでシークレット・サービスが完全に動作していることを確認します。
etcd-checker	etcdサービスが各管理ノードで完全に動作していることを確認します。
zfssa-analytics-exporter	ZFS Storage Applianceクラスタのステータス、アクティブな問題、および管理パスの接続情報を報告します。 また、構成可能なデータセットのリストのアナリティクス情報も報告します。

集中ロギング

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

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

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