Contrail Networking の分析

概要:分析

分析は、Juniper Cloud-Native Contrail® Networking™ リリース 22.1 のオプション機能セットです。Contrail NetworkingのコアCNIコンポーネントとは別にパッケージ化されており、独自のインストール手順を備えています。パッケージは、オープンソースソフトウェアとジュニパーが開発したソフトウェアの組み合わせで構成されています。

分析機能は、以下の大まかな機能領域に分類されます。

• メトリック—Contrail NetworkingコンポーネントとベースのKubernetesシステムから収集した統計時系列データ。
• フローおよびセッション レコード — Contrail Networking vRouter から収集されたネットワーク トラフィック情報。
• Sandesh User Visible Entities(UVE):Contrail Networking vRouter およびコントロール ノード コンポーネントから収集された外部に表示されるオブジェクトのシステム全体の状態を表すレコード。
• ログ — Kubernetesポッドから収集されたメッセージをログに記録します。
• イントロスペクション:Contrail Networking コンポーネントの内部状態を参照する機能を提供する診断ユーティリティです。

メトリック

メトリック情報は、数値的時系列データ モデルに基づいています。シリーズ内の各データ ポイントは、一定の間隔で収集されるいくつかのシステム状態のサンプルです。収集が発生したタイムスタンプと共に、サンプル値が記録されます。サンプルレコードには、ラベルと呼ばれるキーと値のペアのオプションセットを含めることもできます。ラベルは、同じメトリック名のラベルの特定の組み合わせがそのメトリックの特定のディメンションのインスタンス化を識別するメトリックのディメンション機能を提供します。たとえば、 という名前 api_http_requests_total のメトリックは、URL とメソッドタイプレベルでリクエスト数を可視化するためにラベルを使用できます。次の例では、サンプル値 10 のメトリック レコードに、要求のタイプを示す一連のラベルが含まれています。

api_http_requests_total{method="POST", handler="/messages"} 10

すべてのメトリック サンプル値は数値にすぎませんが、この数値データ モデル内には型の概念があります。メトリックは、以下のタイプのいずれかと見なされます。

• カウンター — 単調に増加する単一のカウンターを表す累積メトリック。値は再起動時にのみ増加またはゼロにリセットできます。
• ゲージ — 任意に上下できる単一の数値を表すメトリック。
• ヒストグラム — ヒストグラムサンプルのオブザベーション(通常はリクエスト時間や応答サイズなど)で、設定可能なバケットでカウントします。また、ヒストグラムは、すべての観測値の合計も提供します。
• まとめ — ヒストグラムと同様に、サマリーサンプルのオブザベーション(通常はリクエスト時間や応答サイズなど)また、オブザベーションの合計数と観測されたすべての値の合計も提供しますが、サマリーでは、スライドタイム ウィンドウ上で設定可能な分位数が計算されます。

Contrail Networkingのメトリック機能はPrometheusによって実装されています。メトリック データ モデルの詳細については、 Prometheus のマニュアルを参照してください。

サポートされているメトリック

分析ソリューションでサポートされるメトリックのセットは、以下に示すように分類されます。

• Contrail Networking Metric List — vRouter およびコントロール ノード コンポーネントから収集したメトリック。
• Kubernetes メトリック リスト — 、 、 などapiserveretcdkubelet、さまざまな Kubernetes コンポーネントから収集されたメトリック。
• クラスター ノード メトリック — Kubernetes クラスター ノードから収集されたホストレベルのメトリック。

アラート

アラートは、収集されたメトリック データの分析に基づいて生成されます。サポートされるすべてのアラートタイプは、以下の情報を含むルール定義に基づいています。

• アラート名 — アラート タイプの一意の文字列識別子。
• 条件式 — アラート条件が存在するかどうかを判断するために、収集されたメトリック値に対して評価される Prometheus クエリ言語式。
• 条件期間 — アラートを生成するために問題のある条件が存在する必要がある時間。
• 重大度 — アラート レベル(重大、メジャー、警告、情報)。
• まとめ — 問題のある状態の簡単な説明。
• 説明 — 問題のある状態の詳細な説明。

Contrail Networking 分析ソリューションは、 事前定義された一連のアラート ルールをインストールします。独自のカスタムアラートルールを定義することもできます。これは、分析ステアリングチャートが展開されている名前空間での PrometheusRule Kubernetesリソースの作成によってサポートされています。カスタムアラートルールの例を以下に示します。

生成されたアラートはPrometheusのレコードとして保存され、Grafana UIに表示できます。アラート通知用の PagerDuty、OpsGenie、電子メールなどの外部システムとの統合も、AlertManager コンポーネントでサポートされています。

アーキテクチャ

図 1 に示すように、Prometheus はメトリック アーキテクチャのコア コンポーネントです。Prometheusは以下の機能を実装しています。

• コレクション — 一連のメトリックの値を引き出すために、他のコンポーネント(エクスポータ)に対して API 呼び出しを呼び出す定期的なポーリング メカニズムです。
• ストレージ — エクスポート元から収集したメトリックを保持する時系列データベース。
• クエリ — データベースから履歴メトリック情報を取得できる PromQL (Prometheus クエリ言語) と呼ばれる式言語をサポートする API。
• アラート — 収集されたメトリック データで特定の条件が観察された場合にアラートを生成するルールを定義する機能を提供するフレームワーク。

メトリックアーキテクチャのその他のコンポーネントは次のとおりです。

• Grafana — メトリック データをグラフで視覚化できる Web UI インターフェイスを提供するサービスです。
• AlertManager — Prometheus によって生成されたアラートを外部システムに通知する統合サービス。

構成

メトリック機能は、エンドユーザーによる設定を必要としません。分析のインストールでは、上記の[ サポートされているメトリック] セクションで説明されているすべてのメトリックを提供する一連のエクスポータから収集するPrometheusを設定する必要があります。デフォルトのアラートルールのグループも、インストールの一環として自動的に設定されます。ただし、この基本機能は、インストール後の追加設定によってエンドユーザーによって拡張できます。たとえば、顧客固有のアラート ルールを定義し、AlertManager を構成して、お客様の環境でサポートされている外部システムのいずれかと統合できます。

Prometheus と AlertManager の構成には、Prometheus 演算子と呼ばれる追加のアーキテクチャ コンポーネントが含まれます。 図 2 に示すように、構成は Kubernetes カスタム リソースとして指定されています。オペレータは、これらのリソースのコンテンツをPrometheusコンポーネントが理解するネイティブ構成に変換し、それに応じてコンポーネントを更新し、特定の設定変更が再起動を必要とするたびにコンポーネントの再起動に対応する必要があります。

オペレータがサポートするリソースの全セットのドキュメントは 、Prometheus Operator APIで利用できます。ただし、アラート ルールの定義と外部システム統合に関連するリソース タイプのサブセットに限定することをお勧めします。

Grafana

メトリック データとアラートを表示するためのメイン UI は Grafana です。Grafana サービスはセットアップされ、分析インストールの一環として Prometheus をデータ ソースとして自動的に設定します。デフォルトダッシュボードのセットも作成されます。

Grafana Web UIにアクセスしてください: https://<k8sClusterIP>/grafana/login.デフォルトのログイン資格情報は、ユーザー admin とパスワード prom-operatorです。