Azure Operator 5G Core Preview での監視と分析
監視には、メトリック、トレース、ログの 3 つの柱があります。 Azure Operator 5G Core Preview には、問題の特定、調査、解決に役立つ、これらの監視ツールがバンドルされています。 さらに、Azure Operator 5G Core のアラートは、メトリックとログに基づいて通知を提供します。
監視の概要
次のコンポーネントは、Azure Operator 5G Core の監視を提供します。
監視のオープンソース コンポーネント
Azure Operator 5G Core では、監視機能に次のオープンソース コンポーネントが使われます。
| 監視のパラメーター | オープンソース コンポーネント |
|---|---|
| メトリック | Prometheus、AlertManager、Grafana |
| ログ | Elasticsearch、Fluentd、Kibana (EFK); Elastalert |
| トレース | Jaeger、OpenTelemetry Collector |
ログ記録フレームワーク
Elasticsearch、Fluentd、Kibana (EFK) は、マイクロサービスのトラブルシューティングのためのログの収集と視覚化に使われる分散ログ システムを提供します。
Architecture
次の図は、EFK のアーキテクチャを示したものです。
Note
次のリンクされたコンテンツのセクションは、現在の確認済みネットワーク サポート契約をお持ちのお客様のみが利用できます。 コンテンツにアクセスするには、Affirmed Networks ログイン資格情報が必要です。 サポートが必要な場合は、Affirmed Networks サポート チームにお問い合わせください。
ログ記録フレームワークには、次のコンポーネントが含まれます:
Fluentd: Fluentd はオープンソースのログ コレクターです。 Fluentd を使うと、データの使用と理解を向上させるため、データの収集と消費を統合できます。 Fluentd は、Kubernetes クラスターに DaemonSet としてデプロイされます。 それは、各 K8s ノードでログを収集して、Elasticsearch にログをストリーミングします。 Fluentd でサポートされているログに関する説明をご覧ください。
Elasticsearch: Elasticsearch は、オープンソースの分散型リアルタイム検索バックエンドです。 Elasticsearch はログを安全に格納し、ログ分析用の HTTP Web インターフェイスを提供します。
Kibana: Kibana は、Elasticsearch に格納されているログを視覚化するために使われます。 Kibana は Elasticsearch からログをプルします。
Elasticsearch と Kibana について詳しくは、Elasticsearch のドキュメントをご覧ください。
ElastAlert: ElastAlert は、Elasticsearch のデータから異常、スパイク、または他の興味深いパターンに関するアラートを生成するための簡単なフレームワークです。 Elasticsearch と 2 種類のコンポーネント (ルールの種類とアラート) を組み合わせることによって機能します。 定期的に Elasticsearch のクエリが実行されて、データがルールの種類に渡され、そこで一致が見つかった時点が決定されます。 一致が発生すると、一致に基づいて 1 つ以上のアラートがトリガーされます。
ElastAlert について詳しくは、ElastAlert のドキュメントをご覧ください。
機能
ログ記録フレームワークは次の機能を提供します:
ログ収集とストリーミング: Fluentd は、ログを収集して Elasticsearch にストリーミングします。
監査ログのサポート: Fluentd は Kubernetes マスター ノードから Kube-Apiserver 監査ログを読み取り、それらのログを Elasticsearch に書き込みます。 fed-paas-helpers で提供される
auditlogEnabledフラグは、監査ログの読み取りを有効または無効にするために使われます。 auditlogEnabled フラグが true に設定されている場合、Fluentd はワーカー ノードだけでなくマスター ノードにもデプロイされます。イベント ログ: Fluentd は、特定の名前空間のすべてのイベント ログに対して個別の Elasticsearch インデックスを作成します。 これは、より良い方法でルールを適用してイベント ログを検索するのに役立ちます。 インデックスは、プレフィックス
fluentd-eventで始まります。 他のすべての通常のデバッグ ログには、文字列fluentd-*で始まる別の Elasticsearch インデックスが作成されます。ログのストレージと分析: Elasticsearch はログを安全に格納し、ログを検索して分析するためのクエリ言語を提供します。
ログの視覚化: Kibana は Elasticsearch からログをプルし、ログを視覚化します。 Kibana を使うと、ログを視覚化するダッシュボードを作成できます。
アラート メカニズム: ElastAlert は、Elasticsearch でログのクエリを実行するためのルールを提供します。 一致が発生すると、アラートがトリガーされます。
Helm のカスタマイズ
Azure Operator 5G Core には既定の Helm 値のセットがあり、EFK ログ記録フレームワークのデプロイに使用できます。 必要に応じてこれらの値をカスタマイズし、スケーラビリティとパフォーマンスを高めることができます。
可観測性
このセクションでは、EFK ログ記録フレームワークの監視機能 (ダッシュボード、統計、ログ、アラーム) について説明します。
ダッシュボード
次のようなさまざまなダッシュボードがサポートされています:
- Grafana ダッシュボード (ログ記録フレームワークのダッシュボードに関する説明を参照)
- Kibana ダッシュボード (Kibana ダッシュボードの概要に関する説明を参照)
- Grafana Kibana ダッシュボード (Kibana Grafana ダッシュボードに関する説明を参照)
- Fluentd オペレーター ダッシュボード (Fluentd オペレーター Grafana ダッシュボードに関する説明を参照)
- Elasticsearch Grafana ダッシュボード (Elasticsearch ダッシュボードに関する説明を参照)
統計
EFK コンポーネントでサポートされている統計情報については、以下をご覧ください。
メトリック ベースのアラートについては、以下をご覧ください。
イベント
Elastic のイベントについては、Elastic のイベントに関する説明をご覧ください。
ログの視覚化
フレームワークは、Azure Operator 5G Core インストール内で実行されているノードとアプリケーションからログを集約します。 ログが有効になっていると、EFK フレームワークは Fluentd を使って、すべてのアプリケーションとノードのイベント ログを Elasticsearch に集約します。 また、EFK フレームワークでは集中型の Kibana Web UI も提供されており、ユーザーはログを表示したり、集約されたデータを使って充実した視覚化やダッシュボードを作成したりできます。
メトリック フレームワーク
メトリック フレームワークは、Prometheus、Grafana、AlertManager で構成されます。
オープンソースの Prometheus (メイン コンポーネント) は、メトリック ベースの監視システムです。 アプリケーションとインフラストラクチャのパフォーマンスを分析するための、データ モデルとクエリ言語が提供されています。 Prometheus は、インストルメント化されたジョブからメトリックを直接収集し、スクレイピングされたすべてのサンプルをローカル環境の外部ストレージに格納します。 定義されたルールに基づいて、Prometheus は既存のデータから新しい時系列を集計して記録するか、アラートを生成します。 AlertManager は、クライアント アプリケーションによって送信されたアラートを処理して、重複除去、グループ化、適切な受信者統合へのルーティングを行います。
Grafana には、収集されたデータを視覚化するためのダッシュボードが用意されています。
Architecture
次の図は、メトリック フレームワークのさまざまなコンポーネントが相互にどのように関係しているのかを示したものです。
メトリック フレームワークの主要なコンポーネントは次のとおりです。
- Prometheus サーバー: Prometheus サーバーは、構成されたターゲットから一定の間隔でメトリックを収集し、ルール式を評価し、結果を表示して、特定の条件が満たされた場合はアラートをトリガーします。 Azure Operator 5G Core は、必要最小限の構成で、Prometheus サーバーとすぐに統合できます。
- クライアント ライブラリ: クライアント ライブラリはアプリケーションのコードをインストルメント化します。
- AlertManager: AlertManager は、Prometheus サーバーなどのクライアント アプリケーションによって送信されたアラートを処理します。 重複除去、グループ化、適切な受信者統合 (メール、Slack など) へのアラートのルーティングを処理します。 AlertManager では、アラートの抑制と禁止もサポートされています。
- Grafana: Grafana には、収集されたデータのクエリ、視覚化、理解のための 3GPP や他の KPI を豊富に含む、すぐに使用できる一連のダッシュボードが用意されています。 Grafana の監査機能が提供するメカニズムにより、Grafana サーバー ポッドの再起動時に、Grafana サーバーでダッシュボードが復元または再作成されます。 監査機能は、Grafana サーバーから古いダッシュボードを削除するのにも役立ちます。
機能
メトリック フレームワークでは、次の機能がサポートされています。
- メトリック名とキーと値のペアによって識別される時系列データを含む多次元データ モデル。
- 多次元データを使う柔軟なクエリ言語である PromQL。
- 分散ストレージへの非依存: 単一サーバー ノードは自律的です。
- HTTP 経由のプル モデルを使用した時系列コレクション。
- ターゲットは、サービス検出または静的構成によって検出されます。
- グラフ作成とダッシュボード作成のサポートの複数のモード。
Prometheus について詳しくは、Prometheus のドキュメントをご覧ください。 Grafana について詳しくは、「Grafana オープンソースのドキュメント」を参照してください。
可観測性
このセクションでは、メトリック フレームワークによって提供される監視機能 (ダッシュボード、統計、ログ、アラーム) について説明します。
ダッシュボード
メトリック フレームワークでは、次のダッシュボードがサポートされています。
- Grafana ダッシュボード (Grafana ダッシュボードに関する説明を参照)
- Prometheus Grafana ダッシュボード (Prometheus Grafana ダッシュボードに関する説明を参照)
統計
メトリック フレームワーク コンポーネントでサポートされている統計情報については、以下をご覧ください。
Prometheus のメトリック ベースのアラートについては、Prometheus のメトリック ベースのアラートに関する説明をご覧ください。
イベントとログ
メトリック フレームワークのイベントについては、以下をご覧ください。
ネットワークと HTTP のエラーに関するメトリック ベースのアラート
Prometheus の警告ルールは、システムで HTTP とネットワークのエラーが検出された場合にアラートを生成します。 次のアラートがネットワーク エラーに対して生成されます。
アプリケーション レベルのグローバル アラート:
- IstioGlobalHTTP5xxRatePercentageHigh: Istio サービス メッシュの一部であるアプリケーションが 5xx エラーで応答しており、エラー率の割合が <構成値> % を超えています
- IstioGlobalHTTP4xxRatePercentageHigh: アプリケーションが 4xx エラーで応答しており、エラー率の割合が <構成値> % を超えています。 IstioHTTPRequestLatencyTooHigh: 要求に、<構成値> 秒を超える時間がかかっています。
ポッドとコンテナー レベルのアラート:
- HTTPServerError5xxPercentageTooHigh: HTTP サーバーが 5xx エラーで応答しており、エラーの割合が <構成値> % を超えています。
- HTTPServerError4xxPercentageTooHigh: HTTP サーバーが 4xx エラーで応答しており、エラーの割合が <構成値> % を超えています。
- HTTPServerRequestRateTooHigh - HTTP サーバーで受信した要求の合計が <構成値> を超えています。
- HTTPClientRespRcvd5xxPercentageTooHigh: HTTP クライアントが応答で 5xx エラーを受け取っており、受け取ったエラーの割合が <構成値> % を超えています。
- HTTPClientRespRcvd4xxPercentageTooHigh: HTTP クライアントが応答で 4xx エラーを受け取っており、受け取ったエラーの割合が <構成値> % を超えています。
トレース フレームワーク
OpenTelemetry プロトコルを使用した Jaeger トレース
Azure Operator 5G Core では、Jaeger トレースで OpenTelemetry プロトコル (OTLP) が使われます。 OTLP は、fed-paas-helpers の Jaeger エージェントに代わるものです。 Azure Operator 5G Core では、fed-otel_collector フェデレーションがデプロイされます。 OpenTelemetry (OTEL) コレクターは、fed-otel_collector 名前空間の一部として実行されます。
Jaeger トレースでは、次のワークフローが使われます。
- OTLP クライアント ライブラリを備えたアプリケーションが、OTLP GRPC プロトコルで OTEL コレクターにトレースを送信します。 OTEL コレクターには、レシーバー、プロセッサ、エクスポーターの 3 つのコンポーネントがあります。
- OTEL コレクターの OTLP GRPC レシーバーはトレースを受信し、それを Jaeger エクスポーターに送信します。
- Jaeger エクスポーターは、fed-jaeger の一部として実行されている Jaeger コレクターにトレースを送信します。
- Jaeger コレクターは、Elastic バックエンド ストレージ (fed-elastic) にトレースを格納します。
関連するコンテンツ
- Azure Operator 5G Core Preview とは
- クイック スタート: Azure Operator 5G Core の監視 (プレビュー) を Azure Kubernetes Services (AKS) にデプロイする
[def]: