Red Hat SummitNetwork Observability
OpenShift Container Platform での Network Observability Operator の設定と使用
概要
第1章 Network Observability Operator リリースノート
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の開発を追跡します。
Network Observability Operator の概要については、Network Observability について を参照してください。
1.1. Network Observability Operator 1.11.1 に関する勧告
Network Observability Operator 1.11.1 リリースに関するアドバイザリーを確認できます。
1.2. Network Observability Operator1.11.1 の不具合を修正しました
Network Observability Operator 1.11.1 リリースには、eBPF エージェントのパフォーマンスと OpenShift Container Platform の Web コンソールにおけるユーザーエクスペリエンスを向上させるための、いくつかの修正が含まれています。
- eBPF エージェントのメモリー使用量の最適化
今回のアップデート以前は、eBPF エージェントのリグレッションにより、無効化された機能のためにカーネルメモリーが意図せず予約されてしまうという問題が発生していました。その結果、エージェントのメモリー使用量が予想以上に増加した。
今回のアップデートにより、eBPF エージェントは、機能が無効化されている場合に、予約済みのカーネルメモリーを最小限に抑えるようにします。その結果、エージェントのメモリー使用量が削減され、リソース割り当てがより効率的になる。
- Prometheus 専用モードでの DNS グラフの可用性が向上しました
今回のアップデート以前は、Loki が無効で DNS トラッキングが有効になっている場合、OpenShift Container Platform コンソールプラグインは DNS グラフを表示できませんでした。その代わりに、有効な Prometheus データを持つグラフであっても、Prometheus メトリクスを使用してリクエストを実行できないというエラーが表示されました。
今回のアップデートにより、エラーは設定されたメトリクスがない特定のグラフに対してのみ表示されるようになりました。その結果、有効な DNS グラフはすべて Web コンソールに正しく表示されるようになりました。
- トポロジービューにおけるエラー処理の改善
今回のアップデート以前は、Loki がインストールされていない環境では、トポロジー ビューにおける特定のクエリーを実行すると、Prometheus メトリクスが欠落しているためにエラーが発生する可能性がありました。これらのエラーは、ブラウザーのキャッシュをクリアするまで解消されない場合がありました。
今回のアップデートにより、メトリクスの欠落によって発生する無効なスコープがコンソールに表示されなくなりました。さらに、コンソールのエラー処理が更新され、より実用的な情報を提供するようになったため、これらのシナリオでは手動でキャッシュをクリアする必要がなくなりました。
1.3. Network Observability Operator1.11 に関する勧告
Network Observability Operator1.11 リリースの勧告を確認できます。
1.4. Network Observability Operator1.11 の新機能と機能強化
Network Observability Operator 1.11 リリースにおける新機能と機能強化についてご紹介します。FlowCollectorSlice リソースを使用した階層型ガバナンス、新しいサービスデプロイメントモデル、およびヘルスルールの一般提供開始 など が含まれます。
- FlowCollectorSlice リソースを使用したテナントごとの階層型ガバナンス
今回のリリースでは、階層型ガバナンスをサポートする
FlowCollectorSliceAPI が導入され、プロジェクト管理者がそれぞれのネームスペースのサンプリングとサブネットのラベル付けを個別に管理できるようになります。この機能は、大規模環境において、個々のチームがクラスター全体の設定変更なしにセルフサービスによる可視性を必要とする場合に、グローバルな処理オーバーヘッドを削減し、テナントの自律性を提供するために実装されました。その結果、組織は集中型のクラスター制御を維持しながら、トラフィックと委譲データエンリッチメントタスクをプロジェクトレベルで選択的に収集できるようになります。
FlowCollectorリソースの新しいサービスデプロイメントモデル今回のリリースでは、
FlowCollectorカスタムリソースに新しいサービスデプロイメントモデルが導入されました。このモデルは、Direct モデルとKafkaモデルの中間的な選択肢を提供する。サービスモデルでは、eBPF エージェントはデーモンセットとしてデプロイされ、flowlogs-pipelineコンポーネントはスケーラブルなサービスとしてデプロイされます。このモデルは、コンポーネントインスタンス間でのキャッシュの重複を削減することで、大規模クラスターにおけるパフォーマンスを向上させます。
- 健康に関する規則は一般的に入手可能です
以前のバージョンでテクノロジープレビュー機能として導入されたヘルスアラート機能は、Network Observability Operator 1.11 リリースでヘルスルールとして完全にサポートされるようになりました。
重要ネットワークオブザーバビリティーのヘルスルールは、OpenShift Container Platform 4.16 以降で利用可能です。
この eBPF ベースのシステムは、ネットワークメトリクスとインフラストラクチャーメタデータを関連付けることで、トラフィックの急増や遅延傾向など、クラスターの状態に関するプロアクティブな通知と自動化された洞察を提供します。その結果、OpenShift Container Platform の Web コンソールにある ネットワークヘルス ダッシュボードを使用して、カテゴリー分けされたアラートを管理したり、しきい値をカスタマイズしたり、記録ルールを作成して視覚化のパフォーマンスを向上させることができます。
- ネットワークトラフィックの可視化とフィルタリング機能の強化
今回のリリースでは、OpenShift Container Platform の Web コンソールに、強化された視覚化ツールとフィルタリングツールが導入されました。
- インラインフィルター編集: フィルター入力フィールド内でフィルターチップを直接編集できるようになりました。この機能強化により、これまで切り捨てられていた長いフィルター値をより効率的に変更できるようになり、値を手動でコピー＆ペーストする必要がなくなります。今回のアップデートでは、保存済みフィルター機能と一貫性のあるインライン編集方式を採用しています。
- 外部トラフィックのクイックフィルター: 新しいクイックフィルターを使用すると、外部からの Ingress と Egress トラフィックをアクティブに監視できます。この機能強化によりネットワーク管理が効率化され、外部ネットワーク通信に関連する問題を迅速に特定して対処できるようになります。
- 直感的なリソースアイコン:OpenShift Container Platform コンソールでは、Kubernetes の種類、グループ、フィルターにそれぞれ専用のアイコンが使用されるようになりました。これらのアイコンは、より直感的で視覚的に一貫性のある操作性を提供し、ネットワークトポロジーのナビゲーションを容易にし、適用されたフィルターを一目で識別できるようにします。
- DNS 解決分析
今回のリリースには、eBPF ベースの DNS トラッキング機能が含まれており、ネットワークフローレコードにドメイン名を追加することで、より詳細な情報を提供できるようになります。
この機能は、管理者がネットワークルーティングの障害と、
NXDOMAINエラーなどのサービス検出の問題を即座に区別できるようにすることで、平均識別時間 (MTTI) を短縮するために実装されました。- Gateway API との統合
今回のリリースでは、
GatewayClassリソースが作成された際に、Network Observability Operator とゲートウェイ API 間の自動統合が導入されました。この機能は、FlowCollectorリソースを手動で設定することなく、クラスターの Ingress と送信トラフィックに対する高レベルのトラフィック属性を提供します。重要Gateway API との統合は、OpenShift Container Platform 4.19 以降で利用可能です。
OpenShift Container Platform Web コンソールの [監視] → [ネットワークトラフィック ] ビューで、ネットワークフローと Gateway API リソースの自動マッピングを確認できます。所有者 列にはゲートウェイ名が表示され、関連するゲートウェイのリソースページへの直接リンクが提供されます。
- 概要ビューとトポロジービューにおけるデータ回復力の向上
今回のリリースでは、一部のバックグラウンドクエリーが失敗した場合でも、機能データは 概要ビュー と トポロジー ビューに表示されたままになります。この機能強化により、部分的なサービス中断時でも、トポロジービューのスコープおよびグループのドロップダウンメニューにアクセスできるようになります。
さらに、概要 ページにはトラブルシューティングに役立つアクティブなエラーメッセージが表示されるようになり、監視ワークフローを中断することなくシステムの状態をより明確に把握できるようになりました。
- 未知のネットワークフローの分類の改善
今回のリリースでは、未知のソースからのネットワークフローが、外部、未知のサービス、未知のノード、未知の Pod の 4 つの明確なグループに分類されます。
この機能強化では、サブネットラベルを使用して未知の IP サブネットを区別することで、より明確なネットワークトポロジーを提供します。この可視性の向上により、潜在的なセキュリティー脅威を特定しやすくなり、クラスター内の未知の要素をより的確に分析することが可能になります。
- 新規ネットワークオブザーバビリティーインストールのパフォーマンスが向上しました。
Network Observability Operator のデフォルト設定におけるパフォーマンスが、新規インストール時において向上しました。
cacheActiveTimeoutのデフォルト値が 5 秒から 15 秒に増加し、cacheMaxFlows の値が 100,000 から 120,000 に増加して、より高いフロー量に対応できるようになりました。重要これらの新しいデフォルト値は新規インストールにのみ適用され、既存のインストールは現在の設定を維持します。
これらの変更により、CPU 負荷が最大 40% 削減されます。
- LokiStack のステータス監視とレポート機能が改善されました。
今回のリリースでは、Network Observability Operator が
LokiStackリソースの状態を監視し、エラーや設定上の問題を報告するようになりました。Network Observability Operator は、保留中または失敗した Pod や特定の警告状態など、LokiStack の状態を検証します。この機能強化により、
FlowCollector のステータスに、より実用的な情報が表示されるようになり、ネットワークオブザーバビリティーにおけるLokiStackコンポーネントのトラブルシューティングをより効果的に行うことができるようになります。- フィルターメニューにおける Loki インデックス付きフィールドの視覚的表示
今回のリリースでは、一部のバックグラウンドクエリーが失敗した場合でも、機能データは 概要ビュー と トポロジー ビューに表示されたままになります。この機能強化により、部分的なサービス中断時でも、トポロジービューのスコープおよびグループのドロップダウンメニューにアクセスできるようになります。
この機能強化により、どのフィールドがインデックス化されているかを示すことで、クエリーのパフォーマンスが向上し、データ取得が高速化されます。データのフィルタリング時にインデックス付きフィールドを使用すると、コンソール内でネットワークフローを閲覧および分析するのに必要な時間を短縮できます。
1.5. Network Observability Operator1.11 の既知の問題
以下の既知の問題は、Network Observability Operator 1.11 リリースに影響します。
低ボリュームしきい値のためサンプリングレートが増加しても、健康ルールはトリガーされませんサンプリングレートの上昇によりボリュームが
lowVolumeThresholdフィルターを下回った場合、ネットワークオブザーバビリティーアラートがトリガーされない可能性があります。その結果、評価または表示されるアラートの数が減少する。この問題を回避するには、
lowVolumeThreshold の値をサンプリングレートに合わせて調整し、アラートの評価が一貫して行われるようにしてください。- Loki が無効になっている場合、DNS メトリクスは利用できません。
Loki がインストールされていない環境で
DNSTracking機能を有効にすると、DNS グラフに必要なメトリクスが利用できなくなります。そのため、ダッシュボードで DNS の遅延時間や応答コードを表示することはできません。この問題を回避するには、
DNSTrackingオプションを無効にするか、FlowCollectorリソースでspec.loki.enableを true に設定して Loki を有効にする必要があります。
1.6. Network Observability Operator1.11 の不具合を修正しました
Network Observability Operator1.11 リリースには、パフォーマンスとユーザーエクスペリエンスを向上させるためのいくつかの修正が含まれています。
- グラフに日付が欠落している
今回のアップデート以前は、依存関係における互換性のない変更が原因で、グラフのツールチップの日付が意図したとおりに表示されていませんでした。その結果、ユーザーは OpenShift Container PlatformWeb コンソールプラグインの 概要 タブのグラフで日付情報が欠落するという問題に直面し、データコンテキストに影響が出ました。
今回のリリースにより、チャートのツールチップに表示される日付が復元されました。
- ダイレクトモードに関する警告メッセージがアップスケーリング後に更新されない
今回のアップデート以前は、スケーリング後にクラスター情報が更新されなかったため、大規模クラスターでは変更内容が反映されず、警告メッセージが表示され続けるという問題が発生していました。
今回のリリースでは、クラスター情報が変更された際に自動的に更新されるようになり、
ダイレクトモードの大規模クラスターに関する警告メッセージがクラスターサイズの変更に合わせて更新されるため、ユーザーの視認性が向上します。- 未濃縮 OVN IP
このアップデート以前は、OVN-Kubernetes によって宣言された一部の IP アドレスがエンリッチされておらず、
100.64.0.xのようなエンリッチされていない IP アドレスがマシンネットワークに表示されないという問題が発生していました。その結果、エンリッチメントされていない IP アドレスは、ユーザーにとって誤ったネットワーク可視性を引き起こした。今回のリリースにより、OVN-Kubernetes で不足していた IP アドレスが補完されました。その結果、OVN-Kubernetes によって宣言された IP アドレスは正しく拡張され、
マシンネットワークに表示されるため、マシンネットワークにおけるネットワークトラフィックソースの可視性が向上します。- オペレーター API 検出の信頼性が向上しました
今回のアップデート以前は、Network Observability Operator の起動時に発生する競合状態により、API 検出がサイレントに失敗してしまう可能性がありました。その結果、オペレーターが OpenShift Container Platform クラスターを認識できず、必須の
ClusterRoleBindingリソースが欠落し、コンポーネントが正しく機能しなくなる可能性があります。今回のリリースでは、Network Observability Operator が継続的に API の可用性をチェックし、検出に失敗した場合はリコンシリエーションがブロックされます。その結果、オペレーターは環境を正しく識別し、必要なすべてのロールが作成されていることを確認します。
- IPFIX エクスポートに不足していた翻訳フィールドを追加しました
今回のアップデート以前は、IPFIX エクスポート処理中に、一部のネットワークフローフィールドの翻訳が欠落していました。その結果、エクスポートされた IPFIX データは不完全であったり、外部のデータ収集装置で解釈するのが困難であったりした。
今回のリリースでは、
flowlogs-pipelineIPFIX エクスポーターに不足していた翻訳フィールド (xlat) が追加されました。IPFIX エクスポートでは、ネットワークオブザーバビリティーの一貫性を保つための翻訳済みフィールド一式が提供されるようになりました。- FlowMetric フォーム作成リンクとデフォルト設定を修正しました。
今回のアップデート以前は、
FlowMetric のカスタムリソースを作成するためのリンクをクリックすると、意図したフォームビューではなく、誤って YAML エディターに誘導されていました。さらに、エディターには誤ったデフォルト値があらかじめ入力されていた。今回のリリースにより、リンク先は期待されるデフォルト設定が設定された
FlowMetricリソース作成フォームに正しく誘導されるようになりました。その結果、ユーザーはユーザーインターフェイスを通じてFlowMetricリソースを簡単に作成できるようになりました。- トポロジービューの仮想マシンリソースタイプアイコン
このアップデート以前は、仮想マシン (VM) の所有者タイプが トポロジー ビューで誤って汎用的な疑問符 (?) アイコンを表示していました。
今回のリリースにより、ユーザーインターフェイスに仮想マシンリソース専用のアイコンが追加されました。その結果、ユーザーはネットワークトポロジー内の仮想マシントラフィックをより容易に識別区別できるようになります。
- DNS 最適化、DNS アラートの更新
このアップデート以前は、ネットワークオブザーバビリティーで曖昧な URL が使用されていたため、多くの DNSNXDOMAIN エラーが返されていました。
今回のリリースにより、これらの URL の曖昧さが解消され、DNS の利用効率が向上しました。
第2章 Network Observability Operator リリースノートのアーカイブ
2.1. Network Observability Operator リリースノートのアーカイブ
これらのリリースノートは、OpenShift Container Platform の Network Observability Operator の開発履歴を記録したものです。これらはあくまで参考用に提供されています。
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
2.1.1. Network Observability Operator 1.10.1 のアドバイザリー
Network Observability Operator 1.10.1 リリースのアドバイザリーを確認できます。
2.1.2. Network Observability Operator 1.10.1 の CVE
Network Observability Operator 1.10.1 リリースの CVE を確認できます。
2.1.3. Network Observability Operator 1.10.1 で修正された問題
Network Observability Operator 1.10.1 リリースには、修正された問題がいくつか含まれています。これらの修正により、パフォーマンスとユーザーエクスペリエンスが向上します。
- 15 ノードを超えるクラスターでの Direct モードに対して警告が生成されます
この更新前は、大規模なクラスターでは
Directデプロイメントモデルを使用しないという推奨事項は、ドキュメントにのみ記載されていました。このリリースでは、Network Observability Operator は、15 ノードを超えるクラスターで Direct デプロイメントモードが使用されると警告を生成するようになりました。
- OpenShiftSDN でネットワークポリシーのデプロイメントが無効化されました
この更新前は、OpenShift SDN がクラスターネットワークプラグインだった場合、
FlowCollectorネットワークポリシーを有効にすると、ネットワークオブザーバビリティー Pod 間の通信が切断されていました。この問題は、サポート対象のデフォルトネットワークプラグインである OVN-Kubernetes では発生しません。このリリースでは、Network Observability Operator は OpenShift SDN が検出されてもネットワークポリシーをデプロイしようとせず、代わりに警告が表示されます。さらに、ネットワークポリシーを有効にするためのデフォルト値が変更され、OVN-Kubernetes がクラスターネットワークプラグインとして検出された場合にのみ、デフォルトで有効になるようになりました。
- サブネットラベル文字の検証が追加されました
この更新前は、サブネットラベルの "name" 設定で許可される文字は制限されておらず、ユーザーはスペースや特殊文字を含むテキストを入力できました。そのため、ユーザーがフィルターを適用しようとすると Web コンソールプラグインでエラーが生成され、サブネットラベルのフィルターアイコンをクリックしても頻繁に失敗していました。
このリリースでは、設定されたサブネットラベル名は、
FlowCollectorカスタムリソースで設定されると即座に検証されます。この検証により、名前に英数字、:、_、-のみ含まれることが確認されます。その結果、Web コンソールプラグインからのサブネットラベルのフィルタリングが期待どおりに機能するようになりました。- Network Observability CLI は実行ごとに一意の一時ディレクトリーを使用します
この更新前は、Network Observability CLI は現在の作業ディレクトリーで単一の一時 (
tmp) ディレクトリーを作成または再利用していました。これにより、個別の実行間で競合やデータ破損が発生する可能性がありました。このリリースでは、Network Observability CLI は実行ごとに一意の一時ディレクトリーを作成するようになり、潜在的な競合が防止され、ファイル管理の健全性が向上しました。
2.1.4. Network Observability Operator 1.10 アドバイザリー
Network Observability Operator 1.10 に関するアドバイザリーをご確認ください。
2.1.5. Network Observability Operator 1.10 の新機能と機能拡張
Network Observability Operator 1.10 リリースでは、セキュリティーが強化され、パフォーマンスが向上し、ネットワークフローの管理を改善するための新しい CLI UI ツールが導入されています。
2.1.5.1. ネットワークポリシーの更新
Network Observability Operator は、Pod トラフィックを制御するために、Ingress と Egress の両方のネットワークポリシーの設定をサポートするようになりました。この機能拡張によりセキュリティーが向上します。
デフォルトで、spec.NetworkPolicy.enable 仕様が true に設定されるようになりました。そのため、Loki または Kafka を使用する場合は、Loki Operator と Kafka インスタンスを専用の namespace にデプロイすることを推奨します。これにより、ネットワークポリシーを正しく設定し、すべてのコンポーネント間の通信を許可することが可能になります。
2.1.5.2. Network Observability Operator CLI UI の更新
このリリースでは、Network Observability Operator CLI (oc netobserv) ユーザーインターフェイス (UI) に次の新機能と更新が追加されました。
テーブルビューの機能拡張
- カスタマイズ可能な列: Manage Columns をクリックして、表示する列を選択し、ニーズに合わせてテーブルをカスタマイズできます。
- スマートフィルタリング: ライブフィルターに自動提案機能が組み込まれ、適切なキーと値を選択しやすくなりました。
-
パケットプレビュー: パケットをキャプチャーするときに、行をクリックして
pcapの内容を直接調べることができます。
ターミナルベースの折れ線グラフの機能拡張
- メトリクスの視覚化: リアルタイムグラフが CLI で直接レンダリングされます。
- パネルの選択: 事前定義済みのビューから選択するか、Manage Panels ポップアップメニューを使用してビューをカスタマイズし、特定のメトリクスのグラフを選択的に表示できます。
2.1.5.3. Network Observability コンソールの強化
Network Observability コンソールプラグインに、FlowCollector カスタムリソース (CR) を設定するための新しいビューが追加されています。このビューから、次のタスクを完了できます。
-
FlowCollectorCR を設定します。 - リソースフットプリントを計算します。
- 設定の警告やメトリクスのカーディナリティーが高いなどの問題に対する可視性を高めます。
2.1.5.4. パフォーマンスの向上
Network Observability Operator 1.10 では、特に大規模なクラスターで顕著に表れる Operator のパフォーマンスとメモリーフットプリントが改善されました。
2.1.6. Network Observability Operator 1.10 のテクノロジープレビュー機能
2.1.6.1. Network Observability Operator カスタムアラート (テクノロジープレビュー)
このリリースでは、新しいアラート機能とカスタムアラート設定が導入されています。これらの機能はテクノロジープレビュー機能であり、明示的に有効にする必要があります。
新しいアラートを表示するには、OpenShift Container Platform Web コンソールで、Observe → Alerting → Alerting rules をクリックします。
2.1.6.2. Network Observability Operator Network Health ダッシュボード (テクノロジープレビュー)
Network Observability Operator でテクノロジープレビューアーラート機能を有効にすると、OpenShift Container Platform Web コンソールで 監視を クリックすることで、新しい ネットワークヘルス ダッシュボードを表示できます。
Network Health ダッシュボードは、トリガーされたアラートの概要を提供し、重大な問題、警告、および軽微な問題に分類します。また、保留中のアラートも表示します。
2.1.7. Network Observability Operator 1.10 で削除された機能
Network Observability Operator 1.10 リリースの使用に影響する可能性のある削除された機能をご確認ください。
2.1.7.1. FlowCollector API バージョン v1beta1 の削除
FlowCollector カスタムリソース (CR) API バージョン v1beta1 が削除され、サポートされなくなりました。v1beta2 バージョンを使用してください。
2.1.8. Network Observability Operator 1.10 の既知の問題
Network Observability Operator 1.10 リリースの使用に影響する可能性のある、次の既知の問題と推奨される回避策 (存在する場合) をご確認ください。
2.1.8.1. OpenShift Container Platform 4.14 以前で 1.10 へのアップグレードが失敗する
OpenShift Container Platform 4.14 以前で Network Observability Operator 1.10 にアップグレードすると、ソフトウェアカタログの FlowCollector カスタムリソース定義 (CRD) 検証エラーが原因で失敗する可能性があります。
この問題を回避するには、次の操作を行う必要があります。
OpenShift Container Platform Web コンソールのソフトウェアカタログから、両方のバージョンの Network Observability Operator をアンインストールします。
-
FlowCollectorCRD は、フロー収集プロセスに中断が発生しないように、インストールしたままにしておきます。
-
次のコマンドを実行して、
FlowCollectorCRD の現在の名前を確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].name}'想定される出力:
v1beta1次のコマンドを実行して、
FlowCollectorCRD の現在の提供ステータスを確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'想定される出力:
true次のコマンドを実行して、
v1beta1バージョンのservedフラグをfalseに設定します。$ oc patch crd flowcollectors.flows.netobserv.io --type='json' -p "[{'op': 'replace', 'path': '/spec/versions/0/served', 'value': false}]"次のコマンドを実行して、
servedフラグがfalseに設定されていることを確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'想定される出力:
false- Network Observability Operator 1.10 をインストールします。
2.1.8.2. eBPF エージェントと OpenShift Container Platform の旧バージョンとの互換性
Network Observability コマンドラインインターフェイス (CLI) のパケットキャプチャー機能で使用される eBPF エージェントは、OpenShift Container Platform バージョン 4.16 以前と互換性がありません。
この制限により、eBPF ベースの Packet Capture Agent (PCA) が古いクラスター上で正しく機能しなくなります。
この問題を回避するには、互換性のある古い eBPF エージェントコンテナーイメージを使用するように PCA を手動で設定する必要があります。詳細は、Red Hat ナレッジベースソリューション eBPF agent compatibility with older Openshift versions in Network Observability CLI 1.10+ を参照してください。
2.1.8.3. NetworkPolicy が有効な場合、OpenShiftSDN 環境で eBPF エージェントがフローを送信できない
OpenShiftSDN CNI プラグインを使用する OpenShift Container Platform 4.14 クラスターで Network Observability Operator 1.10 を実行すると、eBPF エージェントが flowlogs-pipeline コンポーネントにフローレコードを送信できません。これは、NetworkPolicy が有効な状態 (spec.networkPolicy.enable: true) で FlowCollector カスタムリソースが作成された場合に発生します。
その結果、フローデータが flowlogs-pipeline コンポーネントによって処理されず、Network Traffic ダッシュボードまたは設定されたストレージ (Loki) に表示されません。eBPF エージェント Pod のログには、コレクターへの接続を試みたときに i/o timeout エラーが表示されます。
time="2025-10-17T13:53:44Z" level=error msg="couldn't send flow records to collector" collector="10.0.68.187:2055" component=exporter/GRPCProto error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.0.68.187:2055: i/o timeout\""
この問題を回避するには、spec.networkPolicy.enable を false に設定して、Network Observability Operator 1.10 の FlowCollector リソースで NetworkPolicy を無効にします。
これにより、eBPF エージェントが、自動的にデプロイされたネットワークポリシーからの干渉を受けずに、flowlogs-pipeline コンポーネントと通信できるようになります。
2.1.9. Network Observability Operator 1.10 で修正された問題
Network Observability Operator 1.10 リリースには、修正された問題がいくつか含まれています。これらの修正により、パフォーマンスとユーザーエクスペリエンスが向上します。
2.1.9.1. MetricName および Remap フィールドの検証
この更新前は、ユーザーが無効なメトリクス名を使用して FlowMetric カスタムリソース (CR) を作成することができました。FlowMetric CR は正常に作成されましたが、その元となるメトリクスはユーザーに何のエラーフィードバックを提供せず、サイレントに失敗していました。
このリリースでは、FlowMetric、metricName、および remap フィールドが作成前に検証されるようになりました。そのため、ユーザーが無効な名前を入力した場合、すぐに通知されます。
2.1.9.2. html-to-image エクスポートのパフォーマンスの向上
この更新前は、基盤となるライブラリーのパフォーマンスの問題により、html-to-image エクスポート機能に時間がかかり、その結果ブラウザーがフリーズしていました。
このリリースでは、html-to-image ライブラリーのパフォーマンスが向上し、エクスポートの待機時間が短縮され、イメージ生成中にブラウザーがフリーズすることがなくなりました。
2.1.9.3. eBPF privileged モードの警告の改善
この更新前は、privileged モードを必要とする eBPF 機能をユーザーが選択しても、privileged モードが設定されていないこと、または有効にする必要があることがユーザーに明確に通知されずに、機能が失敗することがよくありました。
このリリースでは、設定に矛盾がある場合、検証フックによってすぐにユーザーに警告が表示されます。これにより、ユーザーの理解が向上し、誤った設定を防ぐことができます。
2.1.9.4. OpenTelemetry エクスポーターへのサブネットラベルの追加
この更新前は、OpenTelemetry メトリクスエクスポーターに、ネットワークフローラベル SrcSubnetLabel と DstSubnetLabel が欠落していたため、空のラベルが表示されていました。
このリリースでは、これらのラベルがエクスポーターによって正しく提供されるようになりました。また、明確さと OpenTelemetry 標準との整合性を向上させるために、source.subnet.label と destination.subnet.label に名前が変更されました。
2.1.9.5. Network Observability コンポーネントのデフォルト toleration の削減
この更新前は、すべての Network Observability コンポーネントにデフォルトの toleration が設定されており、NoSchedule の taint が付与されているノードも含め、すべてのノードでコンポーネントをスケジュールすることが許可されていました。これにより、クラスターのアップグレードがブロックされることがありました。
このリリースでは、Direct モードで設定されている場合、eBPF エージェントと Flowlogs-Pipeline に対してのみ、デフォルトの toleration が維持されるようになりました。Kafka モードで設定されている場合、OpenShift Container Platform Web コンソールプラグインおよび Flowlogs-Pipeline から toleration が削除されるようになりました。
さらに、toleration は FlowCollector カスタムリソース (CR) で随時設定できますが、以前は toleration を空のリストに置き換えることは不可能でした。現在は、toleration を空のリストに置き換えることが可能です。
2.1.10. Network Observability Operator 1.9.3 アドバイザリー
Network Observability Operator 1.9.3 では、次のアドバイザリーを利用できます。
2.1.11. Network Observability Operator 1.9.2 アドバイザリー
Network Observability Operator 1.9.2 では、次のアドバイザリーを利用できます。
2.1.12. Network Observability 1.9.2 のバグ修正
-
この更新前は、OpenShift Container Platform バージョン 4.15 以前では
TC_ATTACH_MODE設定はサポートされていませんでした。これにより、コマンドラインインターフェイス (CLI) エラーが発生し、パケットとフローの観測が妨げられました。このリリースでは、Traffic Control eXtension (TCX) のフックアタッチメントモードが、これらの古いバージョン向けに調整されました。これにより、tcxフックのエラーが解消され、フローとパケットの観測が可能になります。
2.1.13. Network Observability Operator 1.9.1 のアドバイザリー
Network Observability Operator 1.9.1 リリースのアドバイザリーを確認できます。
Network Observability Operator 1.9.1 では、次のアドバイザリーを利用できます。
2.1.14. Network Observability Operator 1.9.1 で修正された問題
Network Observability Operator 1.9.1 リリースで修正された問題を確認できます。
-
この更新前は、アタッチモードの設定が間違っていたため、OpenShift Container Platform 4.15 でネットワークフローが観測されていませんでした。そのため、特に特定のカタログで、ユーザーがネットワークフローを正しく監視できていませんでした。このリリースでは、OpenShift Container Platform バージョン 4.16.0 より前のバージョンのデフォルトアタッチモードが
tcに設定されているため、OpenShift Container Platform 4.15 でフローが観測されるようになりました。(NETOBSERV-2333) - この更新前は、IPFIX コレクターが再起動すると、IPFIX エクスポーターの設定時に接続が失われ、コレクターへのネットワークフローの送信が停止することがありました。このリリースでは、接続が復元され、ネットワークフローが引き続きコレクターに送信されます。(NETOBSERV-2315)
- この更新前は、IPFIX エクスポーターを設定すると、ポート情報のないフロー (ICMP トラフィックなど) が無視され、ログにエラーが記録されていました。TCP フラグと ICMP データも IPFIX エクスポートから欠落していました。このリリースでは、これらの詳細が含まれるようになりました。欠落しているフィールド (ポートなど) によってエラーが発生しなくなり、エクスポートされたデータに含まれるようになりました。(NETOBSERV-2307)
- この更新前は、OpenShift Container Platform 4.18 でユーザー定義ネットワーク (UDN) マッピング機能の設定上の問題と警告が表示されていました。これは、OpenShift のバージョンがコード内で誤って設定されていたことが原因でした。これはユーザーエクスペリエンスに影響を与えていました。このリリースでは、UDN マッピングが OpenShift Container Platform 4.18 をサポートするようになり、警告が表示されなくなったため、ユーザーエクスペリエンスがスムーズになりました。(NETOBSERV-2305)
-
この更新前は、Network Traffic ページの拡張機能に、OpenShift Container Platform Console 4.19 との互換性の問題がありました。その結果、展開時に空のメニュースペースが表示され、ユーザーインターフェイスに一貫性がありませんでした。このリリースでは、
NetflowTraffic部分とtheme hookの互換性の問題が解決されました。Network Traffic ビューのサイドメニューが適切に管理されるようになり、ユーザーインターフェイスの操作性が向上しました。(NETOBSERV-2304)
2.1.15. Network Observability Operator 1.9.0 のアドバイザリー
Network Observability Operator 1.9.0 リリースのアドバイザリーを確認できます。
2.1.16. Network Observability Operator 1.9.0 の新機能と機能拡張
Network Observability Operator 1.9.0 リリースの新機能と機能拡張を確認できます。
2.1.16.1. ユーザー定義ネットワークと Network Observability の連携
このリリースでは、Network Observability で ユーザー定義ネットワーク (UDN) 機能が一般提供になりました。Network Observability で UDNMapping 機能が有効になっている場合、Traffic フローテーブルに UDN labels 列が表示されます。Source Network Name と Destination Network Name の情報に基づいてログをフィルタリングできます。
2.1.16.2. フローログ取り込み時のフィルタリング
このリリースでは、生成されるネットワークフローの数と Network Observability コンポーネントのリソース使用量を削減するためのフィルターを作成できます。設定できるフィルターは次のとおりです。
- eBPF エージェントフィルター
- flowlogs-pipeline フィルター
2.1.16.3. IPsec のサポート
この更新により、OpenShift Container Platform で IPsec が有効な場合、Network Observability に次の機能拡張が導入されます。
- IPsec Status という新しい列が Network Observability の Traffic フロービューに表示され、フローが正常に IPsec で暗号化されたかどうか、または暗号化/復号化中にエラーが発生したかどうかが表示されます。
- 暗号化されたトラフィックの割合を示す新しいダッシュボードが生成されます。
2.1.16.4. Network Observability CLI
パケット、フロー、メトリクスのキャプチャーで、次のフィルタリングオプションが利用できるようになりました。
-
--samplingオプションを使用して、サンプリングされるパケットの比率を設定します。 -
--queryオプションを使用して、カスタムクエリーを使用してフローをフィルタリングします。 -
--interfacesオプションを使用して、監視するインターフェイスを指定します。 -
--exclude_interfacesオプションを使用して、除外するインターフェイスを指定します。 -
--include_listオプションを使用して、生成するメトリクス名を指定します。
詳細は以下を参照してください。
2.1.17. Network Observability Operator リリースノート 1.9.0 の主な技術上の変更点
Network Observability Operator 1.6.0 リリースの主な技術上の変更点を確認できます。
-
Network Observability 1.9 では、
NetworkEvents機能が、OpenShift Container Platform 4.19 の新しい Linux カーネルで動作するように更新されました。この更新により、古いカーネルとの互換性が失われます。そのため、NetworkEvents機能は OpenShift Container Platform 4.19 でのみ使用できます。Network Observability 1.8 および OpenShift Container Platform 4.18 でこの機能を使用している場合は、Network Observability のアップグレードを回避するか、Network Observability 1.9 にアップグレードし、OpenShift Container Platform を 4.19 にアップグレードすることを検討してください。 -
netobserv-readerクラスターロールの名前がnetobserv-loki-readerに変更されました。 - eBPF エージェントの CPU パフォーマンスが向上しました。
2.1.18. Network Observability Operator 1.9.0 のテクノロジープレビュー機能
Network Observability Operator 1.9.0 リリースのテクノロジープレビュー機能を確認できます。
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。
2.1.18.1. eBPF Manager Operator と Network Observability の連携
eBPF Manager Operator は、すべての eBPF プログラムを管理することで、攻撃対象領域を削減し、コンプライアンス、セキュリティー、競合防止を実現します。Network Observability は、eBPF Manager Operator を使用してフックをロードできます。これにより、特権モードや、CAP_BPF や CAP_PERFMON などの追加の Linux ケイパビリティーを eBPF エージェントに提供する必要がなくなります。eBPF Manager Operator と Network Observability の連携は、64 ビット AMD アーキテクチャーでのみサポートされています。
2.1.19. Network Observability Operator 1.9.0 の CVE
Network Observability Operator 1.9.0 リリースの CVE を確認できます。
2.1.20. Network Observability Operator 1.9.0 で修正された問題
Network Observability Operator 1.9.0 リリースで修正された問題を確認できます。
-
以前は、コンソールプラグインから送信元または送信先 IP でフィルタリングするときに、
10.128.0.0/24などの Classless Inter-Domain Routing (CIDR) 表記を使用すると機能せず、除外されるはずの結果が返されていました。この更新により、CIDR 表記を使用できるようになり、結果が期待どおりにフィルタリングされるようになりました。(NETOBSERV-2276) -
以前は、ネットワークフローが使用中のネットワークインターフェイスを誤って識別することがあり、特に
eth0とens5が混同されるリスクがありました。この問題は、eBPF エージェントがPrivilegedとして設定されている場合にのみ発生していました。この更新により、問題が部分的に修正され、ほぼすべてのネットワークインターフェイスが正しく識別されるようになりました。詳細は、以下の既知の問題を参照してください。(NETOBSERV-2257) - 以前は、Operator が動作を適応させるために利用可能な Kubernetes API をチェックするときに、古い API がある場合、Operator の正常な起動を妨げるエラーが発生していました。この更新により、Operator は関連のない API のエラーを無視し、関連する API のエラーをログに記録して、正常に実行を続行するようになりました。(NETOBSERV-2240)
- 以前は、コンソールプラグインの Traffic フロービューで、フローを Bytes または Packets で並べ替えることができませんでした。この更新により、ユーザーがフローを Bytes と Packets で並べ替えられるようになりました。(NETOBSERV-2239)
-
以前は、IPFIX エクスポーターを使用して
FlowCollectorリソースを設定すると、IPFIX フロー内の MAC アドレスが最初の 2 バイトに切り捨てられていました。この更新により、MAC アドレスが IPFIX フロー内で完全に表現されるようになりました。(NETOBSERV-2208) - 以前は、Operator 検証 Webhook から送信される警告の一部に、実行する必要がある内容が明確に示されていないものがありました。この更新により、このようなメッセージの一部が見直され、より実用的なものに修正されました。(NETOBSERV-2178)
-
以前は、入力エラーなどが発生した場合、
FlowCollectorリソースからLokiStackを参照するときに問題が発生したのかどうかが明確にわかりませんでした。この更新により、そのような場合に、参照されたLokiStackが見つからないことがFlowCollectorステータスに明確に示されるようになりました。(NETOBSERV-2174) - 以前は、コンソールプラグインの Traffic flows ビューで、テキストがオーバーフローすると、テキストの省略記号により、表示されるテキストの大部分が隠れてしまうことがありました。この更新により、可能な限り多くのテキストが表示されるようになりました。(NETOBSERV-2119)
- 以前は、Network Observability 1.8.1 以前のコンソールプラグインが OpenShift Container Platform 4.19 Web コンソールで動作しなかったため、Network Traffic ページにアクセスできませんでした。この更新により、コンソールプラグインに互換性が追加され、Network Observability 1.9.0 で Network Traffic ページにアクセスできるようになりました。(NETOBSERV-2046)
-
以前は、会話トラッキング (
FlowCollectorリソースのlogTypes: ConversationsまたはlogTypes: All) を使用すると、ダッシュボードに表示される Traffic レートのメトリクスに不具合が発生し、トラフィックの増加が制御不能であると誤って表示されていました。現在は、より正確なトラフィックレートがメトリクスに表示されます。ただし、ConversationsおよびEndedConversationsモードでは、長時間にわたる接続は対象外であるため、これらのメトリクスは依然として完全には正確でないことに注意してください。この情報はドキュメントに追加されました。このような不正確さを避けるために、デフォルトモードのlogTypes: Flowsが推奨されます。(NETOBSERV-1955)
2.1.21. Network Observability Operator 1.9.0 の既知の問題
Network Observability Operator 1.9.0 リリースの既知の問題を確認できます。
- ユーザー定義ネットワーク (UDN) 機能はサポートされていますが、OpenShift Container Platform 4.18 で使用すると、設定の問題と警告が表示されます。この警告は無視できます。(NETOBSERV-2305)
-
まれに、eBPF エージェントが複数のネットワーク namespace がある環境で
privilegedモードで実行されている場合、フローと関連するインターフェイスを適切に相関させることができないことがあります。この問題の大部分は今回のリリースで特定され解決されました。しかし、特にens5インターフェイスに関しては、いくつかの不整合が残っています。(NETOBSERV-2287)
2.1.22. Network Observability Operator 1.8.1 のアドバイザリー
Network Observability Operator 1.8.1 リリースのアドバイザリーを確認できます。
2.1.23. Network Observability Operator 1.8.1 の CVE
Network Observability Operator 1.8.1 リリースの CVE を確認できます。
2.1.24. Network Observability Operator 1.8.1 で修正された問題
Network Observability Operator 1.8.1 リリースで修正された問題を確認できます。
- この修正により、OpenShift Container Platform の今後のバージョンでは、Observe メニューが 1 回だけ表示されるようになります。(NETOBSERV-2139)
2.1.25. Network Observability Operator 1.8.0 のアドバイザリー
Network Observability Operator 1.8.0 リリースのアドバイザリーを確認できます。
2.1.26. Network Observability Operator 1.8.0 の新機能と機能拡張
Network Observability Operator 1.8.0 リリースの新機能と機能拡張を確認できます。
2.1.26.1. パケット変換
変換されたエンドポイント情報を使用してネットワークフローをエンリッチできるようになりました。サービスだけでなく特定のバックエンド Pod も表示されるため、どの Pod がリクエストを処理したか確認できます。
詳細は以下を参照してください。
2.1.26.2. OVN-Kubernetes ネットワークイベントの追跡
OVN-Kubernetes ネットワークイベントの追跡は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Network Observability のネットワークイベントトラッキングを使用して、ネットワークポリシー、管理ネットワークポリシー、Egress ファイアウォールなどの OVN-Kubernetes イベントに関する情報を取得できるようになりました。
詳細は以下を参照してください。
2.1.26.3. 1.8 における eBPF パフォーマンスの改善
- Network Observability では、per-CPU マップの代わりにハッシュマップが使用されるようになりました。つまり、ネットワークフローデータがカーネル空間で追跡され、新しいパケットもそこに集約されます。ネットワークフローの重複排除がカーネル内で実行できるようになったため、カーネルとユーザー空間の間のデータ転送サイズによってパフォーマンスが向上します。これらの eBPF パフォーマンスの向上により、eBPF エージェントで CPU リソースが 40% から 57% 削減される可能性があります。
2.1.26.4. Network Observability CLI
このリリースでは、Network Observability CLI に次の新しい機能、オプション、フィルターが追加されました。
-
oc netobserv metricsコマンドを実行して、フィルターを有効にしてメトリクスをキャプチャーします。 -
フローおよびパケットキャプチャーで
--backgroundオプションを使用して CLI をバックグラウンドで実行し、oc netobserv followを実行してバックグラウンド実行の進行状況を確認し、oc netobserv copyを実行して生成されたログをダウンロードします。 -
--get-subnetsオプションを使用して、マシン、Pod、およびサービスのサブネットでフローとメトリクスのキャプチャーを強化します。 以下は、パケット、フロー、メトリクスのキャプチャーで利用できる新しいフィルタリングオプションです。
- IP、ポート、プロトコル、アクション、TCP フラグなどに基づく eBPF フィルター
-
--node-selectorを使用するカスタムノード -
--dropsのみを使用するドロップ -
--regexesを使用する任意のフィールド
詳細は以下を参照してください。
2.1.27. Network Observability Operator リリースノート 1.8.0 の修正された問題
Network Observability Operator 1.8.0 リリースで修正された問題を確認できます。
- 以前は、Network Observability Operator には、メトリクスサーバーの RBAC を管理するための "kube-rbac-proxy" コンテナーが付属していました。この外部コンポーネントは非推奨であるため、削除する必要がありました。これは、サイドカープロキシーを必要としない、Kubernetes コントローラーランタイムを介した TLS および RBAC の直接管理に置き換えられました。(NETOBSERV-1999)
- 以前の OpenShift Container Platform コンソールプラグインでは、複数の値と一致しないキーでフィルタリングするとフィルタリングされませんでした。この修正により、フィルタリングされた値が一切含まれないフローという期待どおりの結果が返されます。(NETOBSERV-1990)
- 以前は、Loki が無効になっている OpenShift Container Platform コンソールプラグインでは、互換性のないフィルターと集計のセットを選択することで "Can’t build query" エラーが発生することが多くなっていました。現在は、ユーザーにフィルターの非互換性を認識させつつ、互換性のないフィルターを自動的に無効にすることで、このエラーを回避しています。(NETOBSERV-1977)
- 以前は、コンソールプラグインからフローの詳細を表示すると、ICMP 情報が常にサイドパネルに表示され、ICMP 以外のフローの場合は "undefined" の値が表示されていました。この修正により、ICMP 以外のフローでは ICMP 情報が表示されなくなります。(NETOBSERV-1969)
- 以前は、Traffic flows ビューの "Export data" リンクが意図したとおりに機能せず、空の CSV レポートが生成されていました。現在は、エクスポート機能が復元され、空ではない CSV データが生成されます。(NETOBSERV-1958)
-
以前は、会話ログは Loki が有効な場合にのみ役立つにもかかわらず、
loki.enableをfalseに設定して、processor.logTypesConversations、EndedConversations、またはAllを使用してFlowCollectorを設定することが可能でした。その結果、リソースを無駄に使用していました。現在、この設定は無効であり、検証 Webhook によって拒否されます。(NETOBSERV-1957) -
FlowCollectorで、processor.logTypesをAllに設定すると、他のオプションよりも CPU、メモリー、ネットワーク帯域幅などのリソースがはるかに多く消費されます。この点は、以前は文書化されていませんでした。これは現在文書化されており、検証 Webhook から警告がトリガーされます。(NETOBSERV-1956) - 以前は、負荷が高い場合に、eBPF エージェントによって生成された一部のフローが誤って破棄され、トラフィック帯域幅が予測を下回っていました。現在、生成されたフローは破棄されません。(NETOBSERV-1954)
-
以前は、
FlowCollector設定でネットワークポリシーを有効にすると、Operator Webhook へのトラフィックがブロックされ、FlowMetricsAPI 検証が機能しなくなっていました。現在は、Webhook へのトラフィックは許可されます。(NETOBSERV-1934) -
以前は、デフォルトのネットワークポリシーをデプロイすると、
additionalNamespacesフィールドにデフォルトでopenshift-consoleとopenshift-monitoringの namespace が設定され、ルールが重複していました。現在は、デフォルトで追加の namespace が設定されなくなったため、ルールの重複を防止できます。(NETOBSERV-1933) - 以前は、OpenShift Container Platform コンソールプラグインから TCP フラグでフィルタリングすると、目的のフラグのみを持つフローが一致していました。現在は、少なくとも目的のフラグを持つフローがフィルタリングされたフローに表示されるようになります。(NETOBSERV-1890)
- eBPF エージェントが特権モードで実行され、Pod が継続的に追加または削除されると、ファイル記述子 (FD) リークが発生します。この修正により、ネットワーク namespace の削除時に FD が適切に閉じられるようになります。(NETOBSERV-2063)
-
以前は、CLI エージェント
DaemonSetはマスターノードにデプロイされませんでした。現在は、taint が設定された場合にすべてのノードでスケジュールするための toleration がエージェントDaemonSetに追加されています。CLI エージェントDaemonSetPod はすべてのノードで実行されます。(NETOBSERV-2030) - 以前は、Prometheus ストレージのみを使用する場合、Source Resource および Source Destination フィルターのオートコンプリートは機能しませんでした。現在、この問題は修正され、提案が期待どおりに表示されるようになりました。(NETOBSERV-1885)
- 以前は、複数の IP を使用するリソースは Topology ビューで個別に表示されていました。現在は、リソースはビュー内で単一のトポロジーノードとして表示されます。(NETOBSERV-1818)
- 以前は、マウスポインターを列の上に置くと、コンソールで Network traffic テーブルビューの内容が更新されていました。現在は表示が固定され、ポインターを置いても行の高さは一定のままです。(NETOBSERV-2049)
2.1.28. Network Observability Operator リリースノート 1.8.0 の既知の問題
Network Observability Operator 1.8.0 リリースの既知の問題を確認できます。
- クラスター内に重複するサブネットを使用するトラフィックがある場合、eBPF エージェントが重複した IP からのフローを混同するリスクがわずかにあります。これは、異なる接続がまったく同じ送信元 IP と宛先 IP を持ち、ポートとプロトコルが 5 秒の時間枠内にあり、同じノードで発生している場合に発生する可能性があります。セカンダリーネットワークまたは UDN を設定しない限り、これは不可能です。その場合でも、通常は送信元ポートが差別化要因となるため、通常のトラフィックで発生する可能性は非常に低くなります。(NETOBSERV-2115)
-
OpenShift Container Platform Web コンソールのフォームビューから、
FlowCollectorリソースのspec.exportersセクションで設定するエクスポーターのタイプを選択した後、そのタイプの詳細な設定がフォームに表示されません。回避策として、YAML を直接設定します。(NETOBSERV-1981)
2.1.29. Network Observability Operator 1.7.0 アドバイザリー
Network Observability Operator 1.7.0 リリースのアドバイザリーを確認できます。
2.1.30. Network Observability Operator 1.7.0 の新機能と機能拡張
Network Observability Operator 1.7.0 リリースの次の新機能と機能拡張を確認できます。
2.1.30.1. OpenTelemetry のサポート
エンリッチされたネットワークフローを、Red Hat build of OpenTelemetry などの互換性のある OpenTelemetry エンドポイントにエクスポートできるようになりました。
詳細は以下を参照してください。
2.1.30.2. Network Observability Developer パースペクティブ
Developer パースペクティブで Network Observability を使用できるようになりました。
詳細は以下を参照してください。
2.1.30.3. TCP フラグフィルタリング
tcpFlags フィルターを使用して、eBPF プログラムによって処理されるパケットの量を制限できるようになりました。
詳細は以下を参照してください。
2.1.30.4. OpenShift Virtualization の Network Observability
Open Virtual Network (OVN)-Kubernetes などを介してセカンダリーネットワークに接続された仮想マシンから送信される eBPF エンリッチ化ネットワークフローを検出することで、OpenShift Virtualization 環境のネットワークパターンを観測できます。
詳細は以下を参照してください。
2.1.30.5. FlowCollector カスタムリソース (CR) でのネットワークポリシーのデプロイ
このリリースでは、FlowCollector カスタムリソース (CR) を設定して、ネットワーク可観測性のためのネットワークポリシーをデプロイできます。以前は、ネットワークポリシーが必要な場合は、手動で作成する必要がありました。ネットワークポリシーを手動で作成するオプションは引き続き利用可能です。
詳細は以下を参照してください。
2.1.30.6. FIPS コンプライアンス
FIPS モードで実行されている OpenShift Container Platform クラスターに Network Observability Operator をインストールして使用できます。
重要クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
2.1.30.7. eBPF エージェントの機能拡張
eBPF エージェントで次の機能拡張を利用できます。
-
DNS サービスが
53以外のポートにマッピングされている場合は、spec.agent.ebpf.advanced.env.DNS_TRACKING_PORTを使用して、この DNS 追跡ポートを指定できます。 - トランスポートプロトコル (TCP、UDP、または SCTP) のフィルタリングルールに 2 つのポートを使用できるようになりました。
- プロトコルフィールドを空のままにしておくことで、ワイルドカードプロトコルを使用してトランスポートポートをフィルタリングできるようになりました。
詳細は以下を参照してください。
2.1.30.8. Network Observability CLI
Network Observability CLI (oc netobserv) が一般提供になりました。1.6 テクノロジープレビューリリース以降、次の機能強化が行われました。
- フローキャプチャーと同様に、パケットキャプチャー用の eBPF エンリッチメントフィルターが追加されました。
-
フローキャプチャーとパケットキャプチャーの両方でフィルター
tcp_flagsを使用できるようになりました。 - 最大バイト数または最大時間に達したときに、自動ティアダウンオプションを利用できます。
詳細は以下を参照してください。
2.1.31. Network Observability Operator 1.7.0 で修正された問題
Network Observability Operator 1.7.0 リリースで修正された次の問題を確認できます。
-
以前は、RHEL 9.2 リアルタイムカーネルを使用すると、一部の Webhook が機能しませんでした。現在は、この RHEL 9.2 リアルタイムカーネルが使用されているかどうかを確認するための修正が導入されています。このカーネルが使用されている場合、
s390xアーキテクチャーの使用時にパケットドロップやラウンドトリップ時間などの機能が実行されないという内容の警告が表示されます。この修正は OpenShift 4.16 以降で適用されます。(NETOBSERV-1808) - 以前は、Overview タブの Manage panels ダイアログで、total、bar、donut、または line でフィルタリングしても、結果が表示されませんでした。現在は、利用可能なパネルが正しくフィルタリングされます。(NETOBSERV-1540)
-
以前は、高ストレス下で eBPF エージェントが多数の小さなフローを生成する状態になり、フローがほとんど集約されないことがありました。この修正により、集約プロセスが高いストレス下でも維持され、作成されるフローが少なくなりました。この修正により、eBPF エージェントだけでなく、
flowlogs-pipelineおよび Loki でもリソース消費が改善されます。(NETOBSERV-1564) -
以前は、
namespace_flows_totalメトリクスではなく、workload_flows_totalメトリクスが有効になっていると、健全性ダッシュボードにBy namespaceフローチャートが表示されませんでした。この修正により、workload_flows_totalが有効な場合に健全性ダッシュボードにフローチャートが表示されるようになりました。(NETOBSERV-1746) -
以前は、
FlowMetricsAPI を使用してカスタムメトリクスを生成し、後で新しいラベルを追加するなどしてそのラベルを変更すると、メトリクスの入力が停止し、flowlogs-pipelineログにエラーが表示されていました。この修正により、ラベルを変更しても、flowlogs-pipelineログにエラーが表示されなくなりました。(NETOBSERV-1748) -
以前は、デフォルトの Loki の
WriteBatchSize設定に不一致がありました。FlowCollectorCRD のデフォルトでは 100 KB に設定されていましたが、OLM のサンプルまたはデフォルト設定では 10 MB に設定されていました。現在は、両方とも 10 MB になりました。これにより、全般的にパフォーマンスが向上し、リソースフットプリントが削減されました。(NETOBSERV-1766) - 以前は、プロトコルを指定しなかった場合、ポート上の eBPF フローフィルターが無視されていました。この修正により、ポートやプロトコルごとに eBPF フローフィルターを個別に設定できるようになりました。(NETOBSERV-1779)
- 以前は、Pod からサービスへのトラフィックが トポロジービュー に表示されませんでした。サービスから Pod への戻りトラフィックのみが表示されていました。この修正により、そのトラフィックも正しく表示されるようになりました。(NETOBSERV-1788)
- 以前は、Network Observability にアクセスできるクラスター管理者以外のユーザーが、namespace など、自動補完をトリガーする項目をフィルタリングしようとすると、コンソールプラグインにエラーが表示されていました。この修正により、エラーが表示されなくなり、自動補完によって期待どおりの結果が返されるようになりました。(NETOBSERV-1798)
- セカンダリーインターフェイスのサポートが追加されたときに、インターフェイスの通知を確認するために、ネットワークごとの namespace を netlink に登録する作業を複数回繰り返す必要がありました。同時に、TC とは異なり、TCX フックではインターフェイスがダウンしたときにハンドラーを明示的に削除する必要があったため、失敗したハンドラーによってファイル記述子のリークが発生しました。さらに、ネットワーク namespace が削除されるときに、netlink goroutine ソケットを終了する Go クローズチャネルイベントが存在していなかったため、Go スレッドがリークしていました。現在は、Pod を作成または削除するときに、ファイル記述子や Go スレッドがリークしなくなりました。(NETOBSERV-1805)
- 以前は、フローの JSON で該当するデータが利用可能であっても、Traffic flows テーブルの ICMP のタイプと値に、'n/a' と表示されていました。この修正により、ICMP 列にフローテーブル内の該当する値が期待どおりに表示されるようになりました。(NETOBSERV-1806)
- 以前は、コンソールプラグインで、未設定の DNS レイテンシーなどの未設定のフィールドをフィルタリングできないことがありました。この修正により、未設定のフィールドでのフィルタリングが可能になりました。(NETOBSERV-1816)
- 以前は、OpenShift Web コンソールプラグインでフィルターをクリアして、別のページに移動してからフィルターがあったページに戻ると、フィルターが再表示される場合がありました。この修正により、クリアした後にフィルターが予期せず再表示されることがなくなりました。(NETOBSERV-1733)
2.1.32. Network Observability Operator 1.7.0 の既知の問題
Network Observability Operator 1.7.0 リリースの次の既知の問題を確認できます。
- Network Observability で must-gather ツールを使用する場合、クラスターで FIPS が有効になっているとログが収集されません。(NETOBSERV-1830)
FlowCollectorでspec.networkPolicyが有効になっている場合、netobservnamespace にネットワークポリシーがインストールされるため、FlowMetricsAPI を使用できません。ネットワークポリシーにより、検証 Webhook への呼び出しがブロックされます。回避策として、次のネットワークポリシーを使用してください。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-from-hostnetwork namespace: netobserv spec: podSelector: matchLabels: app: netobserv-operator ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/host-network: '' policyTypes: - Ingress
2.1.33. Network Observability Operator リリースノート 1.6.2 のアドバイザリー
Network Observability Operator 1.6.2 リリースのアドバイザリーを確認できます。
2.1.34. Network Observability Operator リリースノート 1.6.2 の CVE
Network Observability Operator 1.6.2 リリースの CVE を確認できます。
2.1.35. Network Observability Operator リリースノート 1.6.2 の修正された問題
Network Observability Operator 1.6.2 リリースで修正された問題を確認できます。
- セカンダリーインターフェイスのサポートが追加されたときに、インターフェイスの通知を確認するために、ネットワークごとの namespace を netlink に登録する作業を複数回繰り返す必要がありました。同時に、TC とは異なり、TCX フックではインターフェイスがダウンしたときにハンドラーを明示的に削除する必要があったため、失敗したハンドラーによってファイル記述子のリークが発生しました。これで、Pod の作成および削除時にファイル記述子がリークしなくなりました。(NETOBSERV-1805)
2.1.36. Network Observability Operator リリースノート 1.6.2 の既知の問題
Network Observability Operator 1.6.2 リリースの既知の問題を確認できます。
- コンソールプラグインとの互換性の問題があり、OpenShift Container Platform クラスターの将来のバージョンに Network Observability をインストールできない可能性がありました。1.6.2 にアップグレードすると、互換性の問題が解決され、Network Observability を期待どおりにインストールできるようになります。(NETOBSERV-1737)
2.1.37. Network Observability Operator リリースノート 1.6.1 のアドバイザリー
Network Observability Operator 1.6.1 リリースのアドバイザリーを確認できます。
2.1.38. Network Observability Operator リリースノート 1.6.1 の CVE
Network Observability Operator 1.6.1 リリースの CVE を確認できます。
2.1.39. Network Observability Operator リリースノート 1.6.1 の修正された問題
Network Observability Operator 1.6.1 リリースで修正された問題を確認できます。
- 以前は、原因や TCP 状態などのパケットドロップに関する情報は、Loki データストアでのみ入手でき、Prometheus では入手できませんでした。そのため、OpenShift Web コンソールプラグインの 概要 のドロップ統計は、Loki でのみ利用可能でした。この修正により、パケットドロップに関する情報もメトリクスに追加されるため、Loki が無効になっているときにドロップ統計を表示できるようになります。(NETOBSERV-1649)
-
eBPF エージェントの
PacketDrop機能が有効になっていて、サンプリングが1より大きい値に設定されていると、報告されたドロップされたバイトとドロップされたパケットではサンプリング設定が無視されます。これは、ドロップを見逃さないように意図的に行われたものですが、副作用として、ドロップなしの報告率と比較したドロップの報告率が偏ってしまいました。たとえば、1:1000などの非常に高いサンプリングレートでは、コンソールプラグインから見ると、ほぼすべてのトラフィックがドロップされているように見える可能性があります。この修正により、ドロップされたバイトとパケットでサンプリング設定が尊重されるようになりました。(NETOBSERV-1676) - 以前は、最初にインターフェイスが作成されてから eBPF エージェントがデプロイされると、SR-IOV セカンダリーインターフェイスが検出されませんでした。これは、最初にエージェントがデプロイされ、その後 SR-IOV インターフェイスが作成された場合にのみ検出されました。この修正により、デプロイメントの順序に関係なく SR-IOV セカンダリーインターフェイスが検出されるようになりました。(NETOBSERV-1697)
- 以前は、Loki が無効になっていると、関連機能が有効になっていない場合でも、OpenShift Web コンソールの Topology ビューで、ネットワークトポロジーダイアグラムの横にあるスライダーに Cluster と Zone の集約オプションが表示されていました。この修正により、スライダーには有効な機能に応じたオプションのみが表示されるようになりました。(NETOBSERV-1705)
-
以前は、Loki が無効になっていて、OpenShift Web コンソールが初めて読み込まれると、
Request failed with status code 400 Loki is disabledエラーが発生していました。この修正により、エラーは発生しなくなりました。(NETOBSERV-1706) - 以前は、OpenShift Web コンソールの トポロジー ビューで、任意のグラフノードの横にある Step into アイコンをクリックすると、選択したグラフノードにフォーカスを設定するために必要なフィルターが適用されず、OpenShift Web コンソールに Topology ビューの広いビューが表示されていました。この修正により、フィルターが正しく設定され、トポロジー が効果的に絞り込まれます。この変更の一環として、ノード 上の Step into アイコンをクリックすると、Namespaces スコープではなく Resource スコープに移動するようになりました。(NETOBSERV-1720)
- 以前は、Loki が無効になっていると、Scope が Owner に設定されている OpenShift Web コンソールの Topology ビューで、任意のグラフノードの横にある Step into アイコンをクリックすると、Scope が Resource に移動しましたが、これは Loki なしでは利用できないため、エラーメッセージが表示されていました。この修正により、Loki が無効になっていると、Owner スコープで Step into アイコンが非表示になるため、このシナリオは発生しなくなります。(NETOBSERV-1721)
- 以前は、Loki が無効になっている場合に、グループを設定すると OpenShift Web コンソールの Topology ビューにエラーが表示されましたが、その後スコープが変更されたため、グループが無効になりました。この修正により、無効なグループが削除され、エラーが防止されます。(NETOBSERV-1722)
-
YAML ビュー ではなく、OpenShift Web コンソールの Form view から
FlowCollectorリソースを作成すると、agent.ebpf.metrics.enableおよびprocessor.subnetLabels.openShiftAutoDetectの設定が Web コンソールによって誤って管理されていました。これらの設定は、Form view ではなく、YAML view でのみ無効にできます。混乱を避けるため、これらの設定は Form view から削除されました。これらは引き続き YAML view でアクセスできます。(NETOBSERV-1731) - 以前は、eBPF エージェントは、SIGTERM 信号によるクラッシュなど、予期しないクラッシュの前にインストールされたトラフィック制御フローをクリーンアップできませんでした。これにより、古いものが削除されなかったため、同じ名前のトラフィック制御フローフィルターが複数作成されました。この修正により、エージェントの起動時に、新しいトラフィック制御フローがインストールされる前に、以前にインストールされたトラフィック制御フローがすべてクリーンアップされるようになります。(NETOBSERV-1732)
- 以前は、カスタムサブネットラベルを設定し、OpenShift サブネットの自動検出を有効にしたままにすると、OpenShift サブネットがカスタムサブネットよりも優先され、クラスターサブネット内のカスタムラベルの定義が妨げられていました。この修正により、カスタム定義されたサブネットが優先され、クラスター内のサブネットにカスタムラベルを定義できるようになります。(NETOBSERV-1734)
2.1.40. Network Observability Operator リリースノート 1.6.0 のアドバイザリー
Network Observability Operator 1.6.0 リリースのアドバイザリーを確認できます。
2.1.41. Network Observability Operator 1.6.0 の新機能と機能拡張
Network Observability Operator 1.6.0 の次の新機能と機能拡張を確認できます。
2.1.41.1. Loki を使用しない場合の Network Observability Operator の使用の強化
Network Observability Operator を使用すると、Prometheus メトリクスを使用でき、ストレージのために Loki に依存する度合いが低下します。
詳細は以下を参照してください。
2.1.41.2. カスタムメトリクス API
FlowMetrics API を使用して、フローログデータからカスタムメトリクスを作成できます。フローログデータを Prometheus ラベルと組み合わせて使用することで、ダッシュボード上のクラスター情報をカスタマイズできます。識別する必要があるフローおよびメトリクスのサブネットに、カスタムラベルを追加できます。この機能拡張により、新しいラベル SrcSubnetLabel と DstSubnetLabel を使用して、フローログとメトリクスの両方に存在する外部トラフィックをより簡単に識別することもできます。外部トラフィックがある場合、これらのフィールドが空になるため、外部トラフィックを識別できます。
詳細は以下を参照してください。
2.1.41.3. eBPF のパフォーマンスの強化
次の更新により、CPU とメモリーの面で eBPF エージェントのパフォーマンスが向上しました。
- eBPF エージェントが、TC の代わりに TCX Webhook を使用するようになりました。
NetObserv/Health ダッシュボードに、eBPF メトリクスを表示する新しいセクションがあります。
- eBPF エージェントがフローをドロップしたときに、新しい eBPF メトリクスに基づいてアラートが通知されます。
- 重複したフローが削除されたため、Loki のストレージ需要が大幅に減少しました。ネットワークインターフェイス別の重複した複数のフローが、関連する一連のネットワークインターフェイスを含む重複排除された 1 つのフローになりました。
重複したフローの更新により、Network Traffic テーブルの Interface および Interface Direction フィールドの名前が Interfaces および Interface Directions に変更されました。そのため、これらのフィールドを使用するブックマーク済みの クイックフィルター のクエリーを、interfaces および ifdirections に更新する必要があります。
詳細は以下を参照してください。
2.1.41.4. eBPF 収集のルールベースのフィルタリング
ルールベースのフィルタリングを使用して、作成されるフローの量を削減できます。このオプションを有効にすると、eBPF エージェント統計の Netobserv/Health ダッシュボードに、Filtered flows rate ビューが表示されます。
詳細は以下を参照してください。
2.1.42. Network Observability Operator 1.6.0 で修正された問題
Network Observability Operator 1.6.0 で修正された次の問題を確認できます。
-
以前は、
FlowMetricsAPI 作成用の Operator Lifecycle Manager (OLM) フォームに、OpenShift Container Platform ドキュメントへの無効なリンクが表示されていました。このリンクの参照先が有効なページに更新されました。(NETOBSERV-1607) - 以前は、Operator Hub の Network Observability Operator の説明に、ドキュメントへの無効なリンクが表示されていました。この修正により、このリンクは復元されます。(NETOBSERV-1544)
-
以前は、Loki が無効になっていて Loki
ModeがLokiStackに設定されていても、または Loki の手動 TLS 設定が設定されていても、Network Observability Operator が Loki CA 証明書の読み取りを試行していました。この修正により、Loki が無効になっている場合、Loki 設定に設定があっても Loki 証明書が読み取られなくなりました。(NETOBSERV-1647) -
以前は、Network Observability Operator の
ocmust-gatherプラグインがamd64アーキテクチャーでしか動作せず、他のすべてのアーキテクチャーでは失敗していました。これは、プラグインがocバイナリーにamd64を使用していたためです。現在、Network Observability Operatorocのmust-gatherプラグインは、あらゆるアーキテクチャープラットフォームでログを収集します。 -
以前は、
not equal toを使用して IP アドレスをフィルタリングすると、Network Observability Operator がリクエストエラーを返していました。現在は、IP アドレスと範囲がequalの場合でもnot equal toの場合でも、IP フィルタリングが機能します。(NETOBSERV-1630) -
以前は、ユーザーが管理者でなかった場合、エラーメッセージが Web コンソールの Network Traffic ビューで選択したタブと一致しませんでした。現在は、
user not adminエラーがどのタブにも表示されるようになり、表示が改善されました。(NETOBSERV-1621)
2.1.43. Network Observability Operator 1.6.0 の既知の問題
Network Observability Operator 1.6.0 の次の既知の問題を確認できます。
-
eBPF エージェントの
PacketDrop機能が有効になっていて、サンプリングが1より大きい値に設定されている場合、ドロップされたバイト数とドロップされたパケット数の報告で、サンプリング設定が無視されます。これはドロップを見逃さないように意図的に行われますが、副作用として、ドロップが報告された割合と非ドロップが報告された割合が偏ってしまいます。たとえば、1:1000などの非常に高いサンプリングレートでは、コンソールプラグインから見ると、ほぼすべてのトラフィックがドロップされているように見える可能性があります。(NETOBSERV-1676) - Overview タブの Manage panels ウィンドウで、total、bar、donut、または line でフィルタリングしても、結果が表示されません。(NETOBSERV-1540)
- SR-IOV セカンダリーインターフェイスを作成してから eBPF エージェントをデプロイした場合、インターフェイスは検出されません。エージェントをデプロイしてから SR-IOV インターフェイスを作成した場合にのみ検出されます。(NETOBSERV-1697)
- Loki が無効になっている場合、OpenShift Web コンソールの Topology ビューで、関連機能が有効になっていない場合でも、ネットワークトポロジー図の横にあるスライダーに Cluster および Zone 集計オプションが常に表示されます。これらのスライダーオプションを無視する以外に、具体的な回避策はありません。(NETOBSERV-1705)
-
Loki が無効になっているときに、OpenShift Web コンソールが初めて読み込まれると、
Request failed with status code 400 Loki is disabledというエラーが表示される場合があります。回避策としては、Topology タブと Overview タブをクリックするなど、Network Traffic ページのコンテンツを何度か切り替える方法があります。エラーが表示されなくなるはずです。(NETOBSERV-1706)
2.1.44. Network Observability Operator 1.5.0 アドバイザリー
Network Observability Operator 1.5 リリースの次のアドバイザリーを参照できます。
2.1.45. Network Observability Operator 1.5.0 の新機能と機能拡張
Network Observability Operator 1.5 リリースの次の新機能と機能拡張を確認できます。
2.1.45.1. DNS 追跡の機能拡張
1.5 では、UDP に加えて TCP プロトコルもサポートされるようになりました。また、新しいダッシュボードが、Network Traffic ページの Overview ビューに追加されました。
詳細は以下を参照してください。
2.1.45.2. ラウンドトリップタイム (RTT)
fentry/tcp_rcv_established Extended Berkeley Packet Filter (eBPF) フックポイントから取得した TCP ハンドシェイクのラウンドトリップタイム (RTT) を使用して、平滑化されたラウンドトリップタイム (SRTT) を読み取り、ネットワークフローを分析できます。Web コンソールの Overview、Network Traffic、および Topology ページで、ネットワークトラフィックを監視し、RTT メトリクス、フィルタリング、およびエッジラベルを使用してトラブルシューティングを行うことができます。
詳細は以下を参照してください。
2.1.45.3. メトリクス、ダッシュボード、アラートの機能拡張
Observe → Dashboards → NetObserv の Network Observability メトリクスダッシュボードに、Prometheus アラートの作成に使用できる新しいメトリクスタイプがあります。利用可能なメトリクスを includeList 仕様で定義できるようになりました。以前のリリースでは、これらのメトリクスは ignoreTags 仕様で定義されていました。
これらのメトリクスの完全なリストについては、以下を参照してください。
2.1.45.4. Loki を使用していない場合の Network Observability の向上
Loki を使用していない場合でも、DNS、パケットドロップ、および RTT メトリクスを使用して Netobserv ダッシュボードの Prometheus アラートを作成できます。旧バージョンの Network Observability 1.4 では、これらのメトリクスは、Network Traffic、Overview、および Topology ビューでのクエリーと分析にのみ使用できました。これらのビューを使用するには、Loki が必要でした。
詳細は以下を参照してください。
2.1.45.5. アベイラビリティーゾーン
クラスターのアベイラビリティーゾーンに関する情報を収集するように FlowCollector リソースを設定できます。この設定では、ノードに適用される topology.kubernetes.io/zone ラベル値を使用してネットワークフローデータをエンリッチします。
詳細は以下を参照してください。
2.1.45.6. 主な機能拡張
Network Observability Operator の 1.5 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
2.1.45.7. パフォーマンスの強化
Kafka 使用時の eBPF のパフォーマンスを向上させるために、
spec.agent.ebpf.kafkaBatchSizeのデフォルトが10MBから1MBに変更されました。重要既存のインストールからアップグレードする場合、この新しい値は自動的に設定されません。アップグレード後に eBPF Agent のメモリー消費のパフォーマンスリグレッションが確認された場合は、
kafkaBatchSizeを減らして別の値にすることを検討してください。
2.1.45.8. Web コンソールの機能拡張:
- DNS と RTT の Overview ビューに新しいパネル (Min、Max、P90、P99) が追加されました。
新しいパネル表示オプションが追加されました。
- 1 つのパネルに焦点を当て、他のパネルの表示を小さくする。
- グラフの種類を切り替える。
- Top と Overall を表示する。
- Custom time range ウィンドウに収集遅延の警告が表示されます。
- Manage panels および Manage columns ポップアップウィンドウの内容の視認性が向上しました。
- Egress QoS の Differentiated Services Code Point (DSCP) フィールドを使用して、Web コンソールの Network Traffic ページの QoS DSCP をフィルタリングできます。
2.1.45.9. 設定の機能拡張
-
spec.loki.mode仕様をLokiStackモードにすると、URL、TLS、クラスターロール、クラスターロールバインディング、およびauthToken値を自動的に設定され、インストールが簡素化されます。Manualモードを使用すると、これらの設定をより詳細に制御できます。 -
API バージョンが
flows.netobserv.io/v1beta1からflows.netobserv.io/v1beta2に変更されます。
2.1.46. Network Observability Operator 1.5.0 で修正された問題
Network Observability Operator 1.5 リリースで修正された次の問題を確認できます。
-
以前は、コンソールプラグインの自動登録が無効になっている場合、Web コンソールインターフェイスでコンソールプラグインを手動で登録することができませんでした。
FlowCollectorリソースのspec.console.register値がfalseに設定されている場合、Operator がプラグインの登録をオーバーライドして消去します。この修正により、spec.console.register値をfalseに設定しても、コンソールプラグインの登録または登録削除に影響しなくなりました。その結果、プラグインを手動で安全に登録できるようになりました。(NETOBSERV-1134) -
以前は、デフォルトのメトリクス設定を使用すると、NetObserv/Health ダッシュボードに Flows Overhead という名前の空のグラフが表示されていました。このメトリクスを使用するには、
ignoreTagsリストから "namespaces-flows" と "namespaces" を削除する必要がありました。この修正により、デフォルトのメトリクス設定を使用する場合にこのメトリクスが表示されるようになります。(NETOBSERV-1351) - 以前は、eBPF Agent を実行しているノードが、特定のクラスター設定で解決されませんでした。これにより連鎖的な影響が生じ、最終的にトラフィックメトリクスの一部を提供できなくなりました。この修正により、eBPF Agent のノード IP が、Pod のステータスから推測されて、Operator によって安全に提供されるようになりました。これにより、欠落していたメトリクスが復元されました。(NETOBSERV-1430)
- 以前は、Loki Operator の Loki エラー 'Input size too long' に、問題をトラブルシューティングするための追加情報が含まれていませんでした。この修正により、Web コンソールのエラーの隣にヘルプが直接表示され、詳細なガイダンスへの直接リンクが表示されるようになりました。(NETOBSERV-1464)
-
以前は、コンソールプラグインの読み取りタイムアウトが 30 秒に強制的に指定されていました。
FlowCollectorv1beta2API の更新により、この値を、Loki Operator のqueryTimeout制限に基づいて更新するようにspec.loki.readTimeout仕様を設定できるようになりました。(NETOBSERV-1443) -
以前は、Operator バンドルが、CSV アノテーションによってサポートされている機能の一部 (
features.operators.openshift.io/…など) を期待どおりに表示しませんでした。この修正により、これらのアノテーションが期待どおりに CSV に設定されるようになりました。(NETOBSERV-1305) -
以前は、調整中に
FlowCollectorステータスがDeploymentInProgress状態とReady状態の間で変動することがありました。この修正により、基礎となるコンポーネントがすべて完全に準備完了した場合にのみ、ステータスがReadyになります。(NETOBSERV-1293)
2.1.47. Network Observability Operator 1.5.0 の既知の問題
Network Observability Operator 1.5 リリースの次の既知の問題を確認できます。
-
Web コンソールにアクセスしようとすると、OCP 4.14.10 のキャッシュの問題により、Observe ビューにアクセスできなくなります。Web コンソールに
Failed to get a valid plugin manifest from /api/plugins/monitoring-plugin/というエラーメッセージが表示されます。推奨される回避策は、クラスターを最新のマイナーバージョンに更新することです。この回避策が機能しない場合は、こちらの Red Hat ナレッジベースの記事 (NETOBSERV-1493) で説明されている回避策を適用する必要があります。 -
Network Observability Operator の 1.3.0 リリース以降、Operator をインストールすると、警告カーネル taint が表示されます。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.48. Network Observability Operator 1.4.2 のアドバイザリー
Network Observability Operator 1.4.2 では、次のアドバイザリーを利用できます。
2.1.49. Network Observability Operator1.4.2 の CVE
Network Observability Operator 1.4.2 リリースでは、次の CVE を確認できます。
2.1.50. Network Observability Operator 1.4.1 のアドバイザリー
Network Observability Operator 1.4.1 の次のアドバイザリーを確認できます。
2.1.51. Network Observability Operator リリース 1.4.1 の CVE
Network Observability Operator 1.4.1 リリースでは、次の CVE を確認できます。
2.1.52. Network Observability Operator リリースノート 1.4.1 の修正された問題
Network Observability Operator 1.4.1 リリースで修正された次の問題を確認できます。
- 1.4 には、ネットワークフローデータを Kafka に送信するときに既知の問題がありました。Kafka メッセージキーが無視されたため、接続の追跡でエラーが発生していました。現在、キーはパーティショニングに使用されるため、同じ接続からの各フローが同じプロセッサーに送信されます。(NETOBSERV-926)
-
1.4 で、同じノード上で実行されている Pod 間のフローを考慮するために、
Inner方向のフローが導入されました。Inner方向のフローは、フローから派生して生成される Prometheus メトリクスでは考慮されなかったため、バイトレートとパケットレートが過小評価されていました。現在は派生メトリクスにInner方向のフローが含まれ、正しいバイトレートとパケットレートが提供されるようになりました。(NETOBSERV-1344)
2.1.53. ネットワーク可観測性リリースノート 1.4.0 のアドバイザリー
Network Observability Operator 1.4.0 リリースの次のアドバイザリーを確認できます。
2.1.54. ネットワーク可観測性リリースノート 1.4.0 の新機能と機能拡張
Network Observability Operator 1.4.0 リリースでは、次の新機能と機能拡張を確認できます。
2.1.54.1. 主な機能拡張
Network Observability Operator の 1.4 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
2.1.54.2. Web コンソールの機能拡張:
- Query Options に、重複したフローを表示するかどうかを選択するための Duplicate flows チェックボックスが追加されました。
-
一方向、
往復、および スワップ フィルターを使用して、送信元および宛先のトラフィックをフィルタリングできるようになりました。
Observe → Dashboards → NetObserv、および NetObserv / Health の Network Observability メトリクスダッシュボードは次のように変更されます。
- NetObserv ダッシュボードには、ノード、namespace、およびワークロードごとに、上位のバイト、送信パケット、受信パケットが表示されます。フローグラフはこのダッシュボードから削除されました。
- NetObserv/Health ダッシュボードには、フローのオーバーヘッド以外にも、ノード、namespace、ワークロードごとの最大フローレートが表示されます。
- インフラストラクチャーとアプリケーションのメトリクスは、namespace とワークロードの分割ビューで表示されます。
詳細は以下を参照してください。
2.1.54.3. 設定の機能拡張
- 証明書設定など、設定された ConfigMap または Secret 参照に対して異なる namespace を指定できるオプションが追加されました。
-
spec.processor.clusterNameパラメーターが追加されたため、クラスターの名前がフローデータに表示されるようになりました。これは、マルチクラスターコンテキストで役立ちます。OpenShift Container Platform を使用する場合は、自動的に決定されるように空のままにします。
詳細は以下を参照してください。
2.1.54.4. Loki を使用しない Network Observability
Network Observability Operator は、Loki なしでも機能し、使用できるようになりました。Loki がインストールされていない場合は、フローを KAFKA または IPFIX 形式にエクスポートし、Network Observability メトリクスダッシュボードに入力することのみ可能です。
詳細は以下を参照してください。
2.1.54.5. DNS 追跡
1.4 では、Network Observability Operator は eBPF トレースポイントフックを使用して DNS 追跡を有効にします。Web コンソールの Network Traffic ページと Overview ページで、ネットワークの監視、セキュリティー分析の実施、DNS 問題のトラブルシューティングを行なえます。
詳細は以下を参照してください。
2.1.54.6. SR-IOV のサポート
Single Root I/O Virtualization (SR-IOV) デバイスを使用して、クラスターからトラフィックを収集できるようになりました。
詳細は以下を参照してください。
2.1.54.7. IPFIX エクスポーターのサポート
eBPF エンリッチ化ネットワークフローを IPFIX コレクターにエクスポートできるようになりました。
詳細は以下を参照してください。
2.1.54.8. パケットドロップ
Network Observability Operator の 1.4 リリースでは、eBPF トレースポイントフックを使用してパケットドロップの追跡を有効にできます。パケットドロップの原因を検出して分析し、ネットワークパフォーマンスを最適化するための決定を行えるようになりました。OpenShift Container Platform 4.14 以降では、ホストのドロップと OVS のドロップの両方が検出されます。OpenShift Container Platform 4.13 では、ホストのドロップのみが検出されます。
詳細は以下を参照してください。
2.1.54.9. s390x アーキテクチャーのサポート
Network Observability Operator が、s390x アーキテクチャー上で実行できるようになりました。以前は、amd64、ppc64le、または arm64 で実行されていました。
2.1.55. ネットワーク可観測性リリースノート 1.4.0 で削除された機能
Network Observability Operator 1.4.0 リリースでは、次の削除された機能を確認できます。
2.1.55.1. チャネルの削除
最新の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは削除されました。
2.1.56. ネットワーク可観測性リリースノート 1.4.0 の修正された問題
Network Observability Operator 1.4.0 リリースで修正された次の問題を確認できます。
- これまで、Network Observability によってエクスポートされた Prometheus メトリクスは、重複する可能性のあるネットワークフローから計算されていました。その結果、関連するダッシュボード (Observe → Dashboards) でレートが 2 倍になる可能性がありました。ただし、Network Traffic ビューのダッシュボードは影響を受けていませんでした。現在は、メトリクスの計算前にネットワークフローがフィルタリングされて重複が排除されるため、ダッシュボードに正しいトラフィックレートが表示されます。(NETOBSERV-1131)
-
以前は、Network Observability Operator エージェントは、Multus または SR-IOV (デフォルト以外のネットワーク namespace) で設定されている場合、ネットワークインターフェイス上のトラフィックをキャプチャーできませんでした。現在は、利用可能なすべてのネットワーク namespace が認識され、フローのキャプチャーに使用されるため、SR-IOV のトラフィックをキャプチャーできます。トラフィックを収集する場合は、
FlowCollectorおよびSRIOVnetworkカスタムリソースで必要な設定があります。(NETOBSERV-1283)
-
以前は、Operators → Installed Operators に表示される Network Observability Operator の詳細の
FlowCollectorStatus フィールドで、デプロイメントの状態に関する誤った情報が報告されることがありました。ステータスフィールドには、改善されたメッセージと適切な状態が表示されるようになりました。イベントの履歴は、イベントの日付順に保存されます。(NETOBSERV-1224) -
以前は、ネットワークトラフィックの負荷が急増すると、特定の eBPF Pod が OOM によって強制終了され、
CrashLoopBackOff状態になりました。現在は、eBPFagent のメモリーフットプリントが改善されたため、Pod が OOM によって強制終了されてCrashLoopBackOff状態に遷移することはなくなりました。(NETOBSERV-975) -
以前は、
processor.metrics.tlsがPROVIDEDに設定されている場合、insecureSkipVerifyオプションの値が強制的にtrueに設定されていました。現在は、insecureSkipVerifyをtrueまたはfalseに設定し、必要に応じて CA 証明書を提供できるようになりました。(NETOBSERV-1087)
2.1.57. ネットワーク可観測性リリースノート 1.4.0 の既知の問題
Network Observability Operator 1.4.0 リリースでは、次の既知の問題を確認できます。
-
Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に
flowlogs-pipelinePod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980) -
現在、
spec.agent.ebpf.featuresに DNSTracking が含まれている場合、DNS パケットが大きいと、eBPFagent が最初のソケットバッファー (SKB) セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPFagent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1304) -
現在、
spec.agent.ebpf.featuresに DNSTracking が含まれている場合、DNS over TCP パケットを扱うときに、eBPFagent が最初の SKB セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPFagent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1245) -
現在、
KAFKAデプロイメントモデルを使用する場合、会話の追跡が設定されていると会話イベントが Kafka コンシューマー間で重複する可能性があり、その結果、会話の追跡に一貫性がなくなり、ボリュームデータが不正確になる可能性があります。そのため、deploymentModelがKAFKAに設定されている場合は、会話の追跡を設定することは推奨されません。(NETOBSERV-926) -
現在、
processor.metrics.server.tls.typeがPROVIDED証明書を使用するように設定されている場合、Operator の状態が不安定になり、パフォーマンスとリソース消費に影響を与える可能性があります。この問題が解決されるまではPROVIDED証明書を使用せず、代わりに自動生成された証明書を使用し、processor.metrics.server.tls.typeをAUTOに設定することが推奨されます。(NETOBSERV-1293 -
Network Observability Operator の 1.3.0 リリース以降、Operator をインストールすると、警告カーネル taint が表示されます。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.58. Network Observability Operator 1.3.0 のアドバイザリー
Network Observability Operator 1.3.0 リリースでは、次のアドバイザリーを確認できます。
2.1.59. Network Observability Operator 1.3.0 の新機能と機能拡張
Network Observability Operator 1.3.0 リリースでは、次の新機能と機能拡張を確認できます。
2.1.59.1. Network Observability におけるマルチテナンシー
- システム管理者は、Loki に保存されているフローへの個々のユーザーアクセスまたはグループアクセスを許可および制限できます。詳細は、「Network Observability におけるマルチテナンシー」を参照してください。
2.1.59.2. フローベースのメトリクスダッシュボード
- このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、「Network Observability メトリクスのダッシュボード」を参照してください。
2.1.59.3. must-gather ツールを使用したトラブルシューティング
- Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、「Network Observability の must-gather」を参照してください。
2.1.59.4. 複数のアーキテクチャーに対するサポートを開始
-
Network Observability Operator は、
amd64、ppc64le、またはarm64アーキテクチャー上で実行できるようになりました。以前は、amd64上でのみ動作しました。
2.1.60. Network Observability Operator 1.3.0 の非推奨機能
Network Observability Operator 1.3.0 リリースでは、次の非推奨機能を確認できます。
2.1.60.1. チャネルの非推奨化
今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。
2.1.60.2. 非推奨の設定パラメーターの設定
Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken HOST 設定が非推奨になりました。Loki Operator を使用する場合、FORWARD 設定のみを使用する必要があります。
2.1.61. Network Observability Operator 1.3.0 で修正された問題
Network Observability Operator 1.3.0 リリースで修正された次の問題を確認できます。
-
以前は、Operator が CLI からインストールされた場合、Cluster Monitoring Operator がメトリクスを読み取るために必要な
RoleとRoleBindingが期待どおりにインストールされませんでした。この問題は、Operator が Web コンソールからインストールされた場合には発生しませんでした。現在は、どちらの方法で Operator をインストールしても、必要なRoleとRoleBindingがインストールされます。(NETOBSERV-1003) -
バージョン 1.2 以降、Network Observability Operator は、フローの収集で問題が発生した場合にアラートを生成できます。以前は、バグのため、アラートを無効にするための関連設定である
spec.processor.metrics.disableAlertsが期待どおりに動作せず、効果がない場合がありました。現在、この設定は修正され、アラートを無効にできるようになりました。(NETOBSERV-976) -
以前は、Network Observability の
spec.loki.authTokenがDISABLEDに設定されている場合、kubeadminクラスター管理者のみがネットワークフローを表示できました。他のタイプのクラスター管理者は認可エラーを受け取りました。これで、クラスター管理者は誰でもネットワークフローを表示できるようになりました。(NETOBSERV-972) -
以前は、バグが原因でユーザーは
spec.consolePlugin.portNaming.enableをfalseに設定できませんでした。現在は、これをfalseに設定すると、ポートからサービスへの名前変換を無効にできます。(NETOBSERV-971) - 以前は、設定が間違っていたため、コンソールプラグインが公開するメトリクスは、Cluster Monitoring Operator (Prometheus) によって収集されませんでした。現在は設定が修正され、コンソールプラグインメトリクスが正しく収集され、OpenShift Container Platform Web コンソールからアクセスできるようになりました。(NETOBSERV-765)
-
以前は、
FlowCollectorでprocessor.metrics.tlsがAUTOに設定されている場合、flowlogs-pipeline servicemonitorは適切な TLS スキームを許可せず、メトリクスは Web コンソールに表示されませんでした。この問題は AUTO モードで修正されました。(NETOBSERV-1070) -
以前は、Kafka や Loki に使用されるような証明書設定では、namespace フィールドを指定できず、Network Observability がデプロイされているのと同じ namespace に証明書が存在する必要がありました。さらに、TLS/mTLS で Kafka を使用する場合、ユーザーは
eBPFagent Pod がデプロイされている特権付き namespace に証明書を手動でコピーし、証明書のローテーションを行う場合などに手動で証明書の更新を管理する必要がありました。現在は、FlowCollectorリソースに証明書の namespace フィールドを追加することで、Network Observability のセットアップが簡素化されています。その結果、ユーザーは Network Observability namespace に証明書を手動でコピーすることなく、Loki または Kafka を別の namespace にインストールできるようになりました。元の証明書は監視されているため、必要に応じてコピーが自動的に更新されます。(NETOBSERV-773) - 以前は、SCTP、ICMPv4、および ICMPv6 プロトコルは Network Observability エージェントのカバレッジに含まれていなかったため、ネットワークフローのカバレッジもあまり包括的ではありませんでした。これらのプロトコルを使用することで、フローカバレッジが向上することが確認されています。(NETOBSERV-934)
2.1.62. Network Observability Operator 1.3.0 の既知の問題
Network Observability Operator 1.3.0 リリースの問題をトラブルシューティングするために、次の問題とその回避策 (存在する場合) を確認できます。
-
FlowCollectorでprocessor.metrics.tlsがPROVIDEDに設定されている場合、flowlogs-pipelineservicemonitorは TLS スキームに適用されません。(NETOBSERV-1087) -
Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に
flowlogs-pipelinePod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980) -
Operator のインストール時に、警告のカーネル taint が表示される場合があります。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.63. ネットワーク可観測性リリースノート 1.2.0 における次回更新に向けての準備
今後のリリースと更新を引き続き受け取るには、Network Observability Operator の更新チャネルを非推奨の v1.0.x から stable チャネルに切り替えます。
インストールされた Operator のサブスクリプションは、Operator の更新を追跡および受信する更新チャネルを指定します。Network Observability Operator の 1.2 リリースまでは、利用可能なチャネルは v1.0.x だけでした。Network Observability Operator の 1.2 リリースでは、更新の追跡および受信用に stable 更新チャネルが導入されました。今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。
2.1.64. Network Observability Operator 1.2.0 のアドバイザリー
Network Observability Operator 1.2.0 リリースの次のアドバイザリーを参照できます。
2.1.65. Network Observability Operator 1.2.0 の新機能と機能拡張
Network Observability Operator 1.2.0 リリースの次の新機能と機能拡張を確認できます。
2.1.65.1. Traffic Flows ビューのヒストグラム
経時的なフローのヒストグラムを表示することを選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、「ヒストグラムの使用」を参照してください。
2.1.65.2. 会話の追跡
ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、「会話の使用」を参照してください。
2.1.65.3. Network Observability のヘルスアラート
Network Observability Operator は、書き込み段階でのエラーが原因で flowlogs-pipeline がフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、「健全性ダッシュボード」を参照してください。
2.1.66. Network Observability Operator1.2.0 のバグ修正
Network Observability Operator 1.2.0 リリースで修正された次の問題を確認できます。
-
これまでは、FlowCollector 仕様の
namespaceの値を変更すると、以前の namespace で実行されているeBPFagent Pod が適切に削除されませんでした。今は、以前の namespace で実行されている Pod も適切に削除されるようになりました。(NETOBSERV-774) -
これまでは、FlowCollector 仕様 (Loki セクションなど) の
caCert.name値を変更しても、FlowLogs-Pipeline Pod および Console プラグイン Pod が再起動されないため、設定の変更が認識されませんでした。今は、Pod が再起動されるため、設定の変更が適用されるようになりました。(NETOBSERV-772) - これまでは、異なるノードで実行されている Pod 間のネットワークフローは、異なるネットワークインターフェイスでキャプチャーされるため、重複が正しく認識されないことがありました。その結果、コンソールプラグインに表示されるメトリクスが過大に見積もられていました。現在は、フローが重複として正しく識別され、コンソールプラグインで正確なメトリクスが表示されます。(NETOBSERV-755)
- コンソールプラグインの "レポーター" オプションは、送信元ノードまたは宛先ノードのいずれかの観測点に基づいてフローをフィルタリングするために使用されます。以前は、このオプションはノードの観測点に関係なくフローを混合していました。これは、ネットワークフローがノードレベルで Ingress または Egress として誤って報告されることが原因でした。これで、ネットワークフロー方向のレポートが正しくなりました。"レポーター" オプションは、期待どおり、ソース観測点または宛先観測点をフィルターします。(NETOBSERV-696)
- 以前は、フローを gRPC+protobuf リクエストとしてプロセッサーに直接送信するように設定されたエージェントの場合、送信されたペイロードが大きすぎる可能性があり、プロセッサーの GRPC サーバーによって拒否されました。これは、非常に高負荷のシナリオで、エージェントの一部の設定でのみ発生しました。エージェントは、次のようなエラーメッセージをログに記録しました: grpc: max より大きいメッセージを受信しました。その結果、それらのフローに関する情報が損失しました。現在、gRPC ペイロードは、サイズがしきい値を超えると、いくつかのメッセージに分割されます。その結果、サーバーは接続を維持します。(NETOBSERV-617)
2.1.67. Network Observability Operator1.2.0 の既知の問題
Network Observability Operator 1.2.0 リリースの問題をトラブルシューティングするために、次の問題とその回避策 (存在する場合) を確認してください。
-
Loki Operator 5.6 を使用する Network Observability Operator の 1.2.0 リリースでは、Loki 証明書の移行が定期的に
flowlogs-pipelinePod に影響を及ぼし、その結果、Loki に書き込まれるフローではなくフローがドロップされます。この問題はしばらくすると自動的に修正されますが、依然として Loki 証明書の移行中に一時的なフローデータの損失が発生します。(NETOBSERV-980)
2.1.68. Network Observability Operator 1.2.0 の主な技術上の変更点
新しい技術変更により、Network Observability Operator 1.2.0 リリースでは、openshift-netobserv-operator namespace にインストールする必要があります。以前にカスタム namespace を使用していたユーザーは、古いインスタンスを削除して Operator を再インストールする必要があります。
以前は、カスタム namespace を使用して Network Observability Operator をインストールできました。このリリースでは、ClusterServiceVersion を変更する conversion webhook が導入されています。この変更により、使用可能なすべての namespace がリストされなくなりました。さらに、Operator メトリクス収集を有効にするには、openshift-operators namespace など、他の Operator と共有される namespace は使用できません。
ここで、Operator を openshift-netobserv-operator namespace にインストールする必要があります。
以前にカスタム namespace を使用して Network Observability Operator をインストールした場合、新しい Operator バージョンに自動的にアップグレードすることはできません。以前にカスタム namespace を使用して Operator をインストールした場合は、インストールされた Operator のインスタンスを削除し、openshift-netobserv-operator namespace に Operator を再インストールする必要があります。一般的に使用される netobserv namespace などのカスタム namespace は、FlowCollector、Loki、Kafka、およびその他のプラグインでも引き続き使用できることに注意することが重要です。
2.1.69. Network Observability Operator1.1.0 の機能拡張
Network Observability Operator 1.1.0 の次のアドバイザリーを参照できます。
Network Observability Operator は安定版になり、リリースチャネルが v1.1.0 にアップグレードされました。
2.1.70. Network Observability Operator 1.10 で修正された問題
Network Observability Operator 1.1.0 リリースで修正された次の問題を確認できます。
-
以前は、Loki の
authToken設定がFORWARDモードに設定されていない限り、認証が強制されず、権限のないユーザーがフローを取得できました。現在は、Loki のauthTokenモードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)
第3章 Network Observability について
Network Observability Operator を使用し、eBPF テクノロジーを利用してネットワークトラフィックを観測することで、Prometheus メトリクスと Loki ログを通じてトラブルシューティング用の詳細情報を入手できます。
OpenShift Container Platform コンソールでこの保存された情報を表示および分析して、さらに詳細な分析やトラブルシューティングを行うことができます。
3.1. Network Observability Operator
Network Observability Operator は、クラスタースコープの FlowCollector API カスタムリソースを提供します。このリソースは、Loki または Prometheus でネットワークフローを収集、補完、保存する eBPF エージェントとサービスのパイプラインを管理します。
FlowCollector インスタンスは、監視パイプラインを形成する Pod とサービスをデプロイします。
eBPF エージェントは daemonset オブジェクトとしてデプロイされ、ネットワークフローを作成します。このパイプラインは、ネットワークフローを収集し、Kubernetes メタデータでエンリッチしてから、Loki への保存や Prometheus メトリクスの生成を行います。
3.2. Network Observability Operator のオプションの依存関係
Network Observability Operator を、オプションの依存関係と統合します。これには、フローストレージ用の Loki Operator、回復力のある大規模データ処理とスケーラビリティー用の AMQ Streams (Kafka) などが含まれます。
サポートされているオプションの依存関係には、フローストレージ用の Loki Operator や、Kafka を使用した大規模データ処理用の AMQ Streams などがあります。
- Loki Operator
- 収集されたすべてのフローを最大限の詳細度で保存するために、Loki をバックエンドとして使用できます。Loki をインストールするには、Red Hat がサポートする Loki Operator を使用することを推奨します。Loki を使用せずに Network Observability を使用するように選択することもできますが、いくつかの要素を考慮する必要があります。詳細は、「Loki を使用しない Network Observability」を参照してください。
- AMQ Streams Operator
Kafka は、大規模なデプロイメント向けに OpenShift Container Platform クラスターにスケーラビリティー、復元力、高可用性を提供します。
注記Kafka を使用する場合は、Red Hat がサポートする AMQ Streams Operator を使用することを推奨します。
3.3. OpenShift Container Platform コンソールの統合
Network Observability Operator は OpenShift Container Platform コンソールと統合され、概要、トポロジービュー、トラフィックフローテーブルを提供します。
Observe → Dashboards の Network Observability メトリクスダッシュボードは、管理者アクセス権を持つユーザーのみが利用できます。
開発者アクセスと namespace へのアクセスが制限されている管理者に対してマルチテナンシーを有効にするには、ロールを定義して権限を指定する必要があります。詳細は、「Network Observability でのマルチテナンシーの有効化」を参照してください。
3.3.1. Network Observability メトリクスのダッシュボード
OpenShift Container Platform コンソールのネットワークオブザーバビリティーメトリクスダッシュボードを確認します。このダッシュボードでは、全体的なトラフィックフローの集約、フィルタリングオプション、Operator の健全性を監視するための専用ダッシュボードが提供されます。
OpenShift Container Platform コンソールの Overview タブでは、クラスター上のネットワークトラフィックフローの全体的な集計メトリクスを表示できます。クラスター、ノード、namespace、所有者、Pod、サービスごとに情報を表示するように選択できます。フィルターと表示オプションにより、メトリクスをさらに絞り込むことができます。詳細は、「Overview ビューからのネットワークトラフィックの観測」を参照してください。
Observe → Dashboards の Netobserv ダッシュボードには、OpenShift Container Platform クラスター内のネットワークフローの簡易的な概要が表示されます。Netobserv/Health ダッシュボードは、Operator の健全性に関するメトリクスを提供します。詳細は、「Network Observability メトリクス」および「健全性情報の表示」を参照してください。
3.3.2. Network Observability トポロジービュー
OpenShift Container Platform コンソールのネットワークオブザーバビリティートポロジービューには、コンポーネント間のトラフィックフローがグラフィカル表示され、さまざまなフィルターや表示オプションを使用して絞り込むことができます。
OpenShift Container Platform コンソールには、OpenShift Container Platform コンポーネント間のトラフィックをネットワークグラフとして表示する Topology タブがあります。フィルターと表示オプションを使用して、グラフを絞り込むことができます。クラスター、ゾーン、udn、ノード、namespace、所有者、Pod、サービスの情報にアクセスできます。
3.3.3. トラフィックフローテーブル
OpenShift Container Platform Web コンソールの Traffic flow テーブルでは、生のネットワークフローが詳細に表示され、詳細な分析のための強力なフィルタリングオプションと設定可能な列が提供されます。
OpenShift Container Platform Web コンソールの Traffic flows タブには、ネットワークフローのデータとトラフィック量が表示されます。
3.4. Network Observability CLI
Network Observability CLI (oc netobserv) は、Network Observability Operator を完全にインストールしなくても、フローとパケットデータをストリーミングして、ネットワークの問題を迅速かつリアルタイムで把握できる軽量ツールです。
Network Observability CLI は、eBPF エージェントを利用して収集したデータを一時的なコレクター Pod にストリーミングするフローおよびパケット可視化ツールです。キャプチャー中に永続的なストレージは必要ありません。実行後、出力がローカルマシンに転送されます。そのため、Network Observability Operator をインストールしなくても、パケットとフローデータをすばやくライブで把握できます。
第4章 Network Observability Operator のインストール
Network Observability Operator を使用する前に、Loki Operator をインストールすることを推奨します。Loki なしでも Network Observability を使用できますが、メトリクスまたは外部エクスポーターのみが必要な場合には、特別な考慮事項が適用されます。
Loki Operator は、マルチテナンシーと認証を実装するゲートウェイを Loki と統合して、データフローストレージを実現します。LokiStack リソースは、スケーラブルで高可用性のマルチテナントログ集約システムである Loki と、OpenShift Container Platform 認証を備えた Web プロキシーを管理します。LokiStack プロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用し、Loki ログストアでのデータの保存とインデックス作成を容易にします。
4.1. Loki を使用しない Network Observability
ネットワークオブザーバビリティーで利用できる機能を、Loki Operator をインストールした場合とインストールしない場合で比較します。
フローを Kafka コンシューマーまたは IPFIX コレクターのみにエクスポートする場合、またはダッシュボードメトリクスのみ必要な場合は、Loki をインストールしたり、Loki 用のストレージを提供したりする必要はありません。次の表は、Loki を使用した場合と使用しない場合の利用可能な機能を比較しています。
| Loki を使用する場合 | Loki を使用しない場合 | |
|---|---|---|
| エクスポーター | X | X |
| マルチテナンシー | X | X |
| 完全なフィルタリングと集計機能[1] | X | |
| 部分的なフィルタリングと集計機能[2] | X | X |
| フローベースのメトリクスとダッシュボード | X | X |
| Traffic flows ビューの概要[3] | X | X |
| Traffic flows ビューテーブル | X | |
| トポロジービュー | X | X |
| OpenShift Container Platform コンソールの Network Traffic タブの統合 | X | X |
- Pod ごとなど。
- ワークロードまたは namespace ごとなど。
- パケットドロップの統計情報は Loki でのみ利用可能です。
4.2. Loki Operator のインストール
ソフトウェアカタログからサポート対象の Loki Operator バージョンをインストールして、セキュアな LokiStack インスタンスを有効にします。これにより、ネットワークオブザーバビリティーのための自動クラスター内認証と認可が提供されます。
ネットワークオブザーバビリティーでサポートされている Loki Operator のバージョンは、Loki Operator バージョン 6.0 以降 です。これらのバージョンでは、openshift-network テナント設定モードを使用して LokiStack インスタンスを作成する機能が提供されており、ネットワークオブザーバビリティーに対する完全に自動化されたクラスター内認証および認可がサポートされています。
前提条件
- 管理者権限がある。
- OpenShift Container Platform Web コンソールにアクセスできる。
- サポートされているオブジェクトストアにアクセスできる。例: AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation。
手順
- OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
- 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
- Installation Mode で、All namespaces on the cluster を選択します。
検証
- Loki Operator がインストールされていることを確認します。Ecosystem → Installed Operators ページにアクセスして、Loki Operator を探します。
- Loki Operator がすべてのプロジェクトで Succeeded の Status でリストされていることを確認します。
Loki をアンインストールするには、Loki のインストールに使用した方法に対応するアンインストールプロセスを参照してください。削除する必要がある ClusterRoles と ClusterRoleBindings、オブジェクトストアに保存されたデータ、および永続ボリュームが残っている可能性があります。
4.2.1. Loki ストレージのシークレットの作成
Amazon Web Services (AWS) などのクラウドストレージ認証情報を使用してシークレットを作成し、Loki Operator がログの永続化に必要なオブジェクトストアにアクセスできるようにします。
Loki Operator は、AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation など、いくつかのログストレージオプションをサポートしています。次の例は、AWS S3 ストレージのシークレットを作成する方法を示しています。この例で作成されたシークレット loki-s3 は、「LokiStack カスタムリソースの作成」で参照されています。このシークレットは、Web コンソールまたは CLI で作成できます。
手順
- Web コンソールを使用して、Project → All Projects ドロップダウンに移動し、Create Project を選択します。
-
プロジェクトに
netobservという名前を付けて、Create をクリックします。 右上隅にあるインポートアイコン + に移動します。YAML ファイルをエディターにペーストします。
以下は、S3 ストレージのシークレット YAML ファイルの例です。
apiVersion: v1 kind: Secret metadata: name: loki-s3 namespace: netobserv-loki stringData: access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK access_key_secret: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo= bucketnames: s3-bucket-name endpoint: https://s3.eu-central-1.amazonaws.com region: eu-central-1ここでは、以下のようになります。
metadata.namespace-
Loki S3 シークレットのネームスペースを指定します。この例では
netobserv-lokiを使用していますが、コンポーネントごとに異なる名前空間を使用することも可能です。 stringData.access_key_id- S3 バケットのアクセスキー ID を指定します。
stringData.access_key_secret- S3 バケットの秘密アクセスキーを指定します。
stringData.bucketnames- S3 バケットの名前を指定します。
stringData.endpoint- S3 サービスのエンドポイント URL を指定します。
stringData.region- バケットが配置されている AWS リージョンを指定します。
検証
- シークレットを作成すると、Web コンソールの Workloads → Secrets にリストされたシークレットが表示されます。
4.2.2. LokiStack カスタムリソースの作成
Web コンソールまたは OpenShift CLI (oc) を使用して LokiStack カスタムリソースをデプロイし、Loki オブジェクトストレージの正しい namespace、デプロイメントサイズ、シークレット名が設定されていることを確認します。
LokiStack カスタムリソース (CR) をデプロイして、namespace または新しいプロジェクトを作成できます。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンから All projects を表示します。
- Loki Operator を探します。詳細の Provided APIs で、LokiStack を選択します。
- Create LokiStack をクリックします。
Form View または YAML view で次のフィールドが指定されていることを確認します。
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: loki namespace: netobserv-loki spec: size: 1x.small storage: schemas: - version: v13 effectiveDate: '2022-06-01' secret: name: loki-s3 type: s3 storageClassName: gp3 tenants: mode: openshift-networkここでは、以下のようになります。
metadata.namespace-
LokiStackリソースの名前空間を指定します。この例ではnetobserv-lokiを使用していますが、コンポーネントごとに異なる名前空間を使用することも可能です。 仕様サイズデプロイメントサイズを指定します。Loki Operator 5.8 以降のバージョンでは、Loki のプロダクションインスタンスでサポートされているサイズオプションは、
1x.extra-small、1x.small、または1x.mediumです。重要デプロイメントサイズの
1xの数は変更できません。spec.storageClassNameクラスター上で
ReadWriteOnceアクセスモードで使用可能なストレージクラス名を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスを確認するには、oc get storageclassesコマンドを使用してください。重要ログ記録に使用する
LokiStackカスタムリソースを再利用してはなりません。
- Create をクリックします。
4.2.3. cluster-admin ユーザーロールの新規グループの作成
cluster-admin ユーザーとして複数の namespace のアプリケーションログをクエリーすると、クラスター内のすべての namespace の文字数の合計が 5120 を超え、Parse error: input size too long (XXXX > 5120) エラーが発生します。LokiStack のログへのアクセスをより適切に制御するには、cluster-admin ユーザーを cluster-admin グループのメンバーにします。cluster-admin グループが存在しない場合は、作成して必要なユーザーを追加します。
次の手順を使用して、cluster-admin 権限のあるユーザー用に、新しいグループを作成します。
手順
以下のコマンドを入力して新規グループを作成します。
$ oc adm groups new cluster-admin以下のコマンドを実行して、必要なユーザーを
cluster-adminグループに追加します。$ oc adm groups add-users cluster-admin <username>以下のコマンドを実行して
cluster-adminユーザーロールをグループに追加します。$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
4.2.4. カスタム管理者グループのアクセス権
必ずしも管理者でなくてもクラスター全体のログを確認する必要がある場合、またはここで使用したいグループがすでに定義されている場合は、adminGroup フィールドを使用してカスタムグループを指定できます。LokiStack カスタムリソース (CR) の adminGroups フィールドで指定されたグループのメンバーであるユーザーには、管理者と同じログの読み取りアクセス権があります。
管理者ユーザーは、クラスター全体のすべてのネットワークログにアクセスできます。
LokiStack CR の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: loki
namespace: netobserv
spec:
tenants:
mode: openshift-network
openshift:
adminGroups:
- cluster-admin
- custom-admin-group 4.2.5. Loki デプロイメントのサイズ
Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。
デプロイメントサイズの 1x の数は変更できません。
| 1x.demo | 1x.extra-small | 1x.small | 1x.medium | |
|---|---|---|---|---|
| Data transfer | デモ使用のみ | 100 GB/日 | 500 GB/日 | 2 TB/日 |
| 1 秒あたりのクエリー数 (QPS) | デモ使用のみ | 200 ミリ秒で 1 - 25 QPS | 200 ミリ秒で 25 - 50 QPS | 200 ミリ秒で 25 - 75 QPS |
| レプリケーション係数 | なし | 2 | 2 | 2 |
| 合計 CPU 要求 | なし | 仮想 CPU 14 個 | 仮想 CPU 34 個 | 仮想 CPU 54 個 |
| 合計メモリー要求 | なし | 31 Gi | 67 Gi | 139 Gi |
| 合計ディスク要求 | 40Gi | 430 Gi | 430 Gi | 590 Gi |
4.2.6. LokiStack の取り込み制限とヘルスアラート
LokiStack インスタンスには、デフォルトの取り込みおよびクエリー制限が含まれています。管理者は、パフォーマンスを管理し、システムアラートやエラーを防ぐためにこれらの制限をオーバーライドできます。
コンソールプラグインまたは flowlogs-pipeline ログに Loki エラーが表示される場合は、取り込みとクエリーの制限を更新することを推奨します。
設定された制限の例を次に示します。
spec:
limits:
global:
ingestion:
ingestionBurstSize: 40
ingestionRate: 20
maxGlobalStreamsPerTenant: 25000
queries:
maxChunksPerQuery: 2000000
maxEntriesLimitPerQuery: 10000
maxQuerySeries: 3000これらの設定の詳細は、LokiStack API リファレンス を参照してください。
4.3. Network Observability Operator のインストール
Network Observability Operator をインストールし、セットアップウィザードを使用して FlowCollector カスタムリソース定義 (CRD) を作成し、初期設定を完了します。
FlowCollector を作成するときに、Web コンソールで仕様を設定できます。
Operator の実際のメモリー消費量は、クラスターのサイズとデプロイされたリソースの数によって異なります。それに応じて、メモリー消費量を調整する必要がある場合があります。詳細は、「Flow Collector 設定に関する重要な考慮事項」セクションの「Network Observability コントローラーマネージャー Pod のメモリーが不足する」を参照してください。
前提条件
- Loki を使用する場合は、Loki Operator バージョン 5.7 以降 をインストールしている。
-
cluster-admin権限を持っている必要があります。 -
サポートされているアーキテクチャーである
amd64、ppc64le、arm64、s390xのいずれか。 - Red Hat Enterprise Linux (RHEL) 9 でサポートされる任意の CPU。
- メインネットワークプラグインとして OVN-Kubernetes を使用して設定する必要があり、オプションで Multus および SR-IOV を使用したセカンダリーインターフェイスを使用する必要があります。
さらに、このインストール例では、すべてのコンポーネントで使用される netobserv namespace を使用します。必要に応じて、別の namespace を使用できます。
手順
- OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
- ソフトウェアカタログで使用可能な Operator のリストから Network Observability Operator を選択し、Install をクリックします。
-
Enable Operator recommended cluster monitoring on this Namespaceチェックボックスを選択します。 - Operators → Installed Operators に移動します。Network Observability の Provided APIs で、Flow Collector リンクを選択します。
- Network Observability FlowCollector setup ウィザードに従います。
- Create をクリックします。
検証
これが成功したことを確認するには、Observe に移動すると、オプションに Network Traffic が表示されます。
OpenShift Container Platform クラスター内に アプリケーショントラフィック がない場合は、デフォルトのフィルターが "No results" と表示され、視覚的なフローが発生しないことがあります。フィルター選択の横にある Clear all filters を選択して、フローを表示します。
4.4. Network Observability でのマルチテナンシーの有効化
クラスターロールと namespace ロールを設定して、プロジェクト管理者と開発者に Loki および Prometheus のフローとメトリクスへのきめ細かな制限付きアクセスを許可することで、ネットワークオブザーバビリティーにおけるマルチテナンシーを有効にします。
アクセスはプロジェクト管理者に対して有効になります。一部の namespace だけにアクセスが制限されているプロジェクト管理者は、それらの namespace のフローにのみアクセスできます。
開発者の場合、Loki と Prometheus の両方でマルチテナンシー機能を利用できますが、必要なアクセス権が異なります。
前提条件
- Loki を使用している場合は、少なくとも Loki Operator バージョン 5.7 がインストールされている。
- プロジェクト管理者としてログインしている。
手順
テナントごとのアクセスの場合、Developer パースペクティブを使用するために、
netobserv-loki-readerクラスターロールとnetobserv-metrics-readernamespace ロールを付与する必要があります。このレベルのアクセスを提供するために、次のコマンドを実行します。$ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>$ oc adm policy add-role-to-user netobserv-metrics-reader <user_group_or_name> -n <namespace>クラスター全体のアクセスの場合、クラスター管理者以外のユーザーに、
netobserv-loki-reader、cluster-monitoring-view、およびnetobserv-metrics-readerクラスターロールを付与する必要があります。この場合、Administrator パースペクティブまたは Developer パースペクティブのいずれかを使用できます。このレベルのアクセスを提供するために、次のコマンドを実行します。$ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>$ oc adm policy add-cluster-role-to-user cluster-monitoring-view <user_group_or_name>$ oc adm policy add-cluster-role-to-user netobserv-metrics-reader <user_group_or_name>
4.6. Kafka のインストール (オプション)
Kafka Operator は、大規模な環境でサポートされています。Kafka は、回復性とスケーラビリティーの高い方法でネットワークフローデータを転送するために、高スループットかつ低遅延のデータフィードを提供します。
Loki Operator および Network Observability Operator がインストールされたのと同じように、Kafka Operator を Operator Hub から Red Hat AMQ Streams としてインストールできます。Kafka をストレージオプションとして設定する場合は、「Kafka を使用した FlowCollector リソースの設定」を参照してください。
Kafka をアンインストールするには、インストールに使用した方法に対応するアンインストールプロセスを参照してください。
4.7. Network Observability Operator のアンインストール
OpenShift Container Platform Web コンソールの Operator Hub の Ecosystem → Installed Operator 領域で作業し、Network Observability Operator をアンインストールします。
手順
FlowCollectorカスタムリソースを削除します。- Provided APIs 列の Network Observability Operator の横にある Flow Collector をクリックします。
-
クラスター のオプションメニュー
をクリックし、[フローコレクターの削除] を選択します。
Network Observability Operator をアンインストールします。
- Ecosystem → Installed Operators 領域に戻ります。
-
Network Observability Operator の横にあるオプションメニュー
をクリックし、[オペレーターのアンインストール] を 選択します。
-
Home → Projects を選択し、
openshift-netobserv-operatorを選択します。 - Actions に移動し、Delete Project を選択します。
FlowCollectorカスタムリソース定義 (CRD) を削除します。- Administration → CustomResourceDefinitions に移動します。
-
FlowCollector を探して、オプションメニュー
をクリックします。
Delete CustomResourceDefinition を選択します。
重要Loki Operator と Kafka は、インストールされていた場合、残っているため、個別に削除する必要があります。さらに、オブジェクトストアに保存された残りのデータ、および削除する必要がある永続ボリュームがある場合があります。
第5章 OpenShift Container Platform の Network Observability Operator
OpenShift Container Platform の Network Observability Operator は、モニタリングパイプラインをデプロイします。このパイプラインは、eBPF agent によって生成されたネットワークトラフィックフローを収集および拡充します。
5.1. 状況の表示
oc get コマンドを使用して FlowCollector リソースのステータスと、eBPF agent、flowlogs-pipeline、およびコンソールプラグイン Pod のステータスを確認し、Network Observability Operator の動作ステータスを表示します。
Network Observability Operator は Flow Collector API を提供します。Flow Collector リソースが作成されると、Pod とサービスをデプロイしてネットワークフローを作成して Loki ログストアに保存し、ダッシュボード、メトリクス、およびフローを OpenShift Container Platform Web コンソールに表示します。
手順
次のコマンドを実行して、
FlowCollectorの状態を表示します。$ oc get flowcollector/cluster出力例
NAME AGENT SAMPLING (EBPF) DEPLOYMENT MODEL STATUS cluster EBPF 50 DIRECT Ready次のコマンドを実行して、
netobservnamespace で実行している Pod のステータスを確認します。$ oc get pods -n netobserv出力例
NAME READY STATUS RESTARTS AGE flowlogs-pipeline-56hbp 1/1 Running 0 147m flowlogs-pipeline-9plvv 1/1 Running 0 147m flowlogs-pipeline-h5gkb 1/1 Running 0 147m flowlogs-pipeline-hh6kf 1/1 Running 0 147m flowlogs-pipeline-w7vv5 1/1 Running 0 147m netobserv-plugin-cdd7dc6c-j8ggp 1/1 Running 0 147mflowlogs-pipelinePod はフローを収集し、収集したフローをエンリッチさせてから、フローを Loki ストレージに送信します。netobserv-pluginPod は、OpenShift Container Platform コンソール用の視覚化プラグインを作成します。次のコマンドを入力して、namespace
netobserv-privilegedで実行している Pod のステータスを確認します。$ oc get pods -n netobserv-privileged出力例
NAME READY STATUS RESTARTS AGE netobserv-ebpf-agent-4lpp6 1/1 Running 0 151m netobserv-ebpf-agent-6gbrk 1/1 Running 0 151m netobserv-ebpf-agent-klpl9 1/1 Running 0 151m netobserv-ebpf-agent-vrcnf 1/1 Running 0 151m netobserv-ebpf-agent-xf5jh 1/1 Running 0 151mnetobserv-ebpf-agentPod は、ノードのネットワークインターフェイスを監視してフローを取得し、それをflowlogs-pipelinePod に送信します。Loki Operator を使用している場合は、次のコマンドを入力して、
netobservnamespace にあるLokiStackカスタムリソースのcomponentPod のステータスを確認します。$ oc get pods -n netobserv出力例
NAME READY STATUS RESTARTS AGE lokistack-compactor-0 1/1 Running 0 18h lokistack-distributor-654f87c5bc-qhkhv 1/1 Running 0 18h lokistack-distributor-654f87c5bc-skxgm 1/1 Running 0 18h lokistack-gateway-796dc6ff7-c54gz 2/2 Running 0 18h lokistack-index-gateway-0 1/1 Running 0 18h lokistack-index-gateway-1 1/1 Running 0 18h lokistack-ingester-0 1/1 Running 0 18h lokistack-ingester-1 1/1 Running 0 18h lokistack-ingester-2 1/1 Running 0 18h lokistack-querier-66747dc666-6vh5x 1/1 Running 0 18h lokistack-querier-66747dc666-cjr45 1/1 Running 0 18h lokistack-querier-66747dc666-xh8rq 1/1 Running 0 18h lokistack-query-frontend-85c6db4fbd-b2xfb 1/1 Running 0 18h lokistack-query-frontend-85c6db4fbd-jm94f 1/1 Running 0 18h
5.2. Network Observablity Operator のアーキテクチャー
Network Observability Operator のアーキテクチャーを確認します。特に、フローを収集して補完し、データをストレージ用として Loki に、またはメトリクス用として Prometheus に送信する eBPF agent を、FlowCollector リソースがどのように管理するか詳しく説明します。
Network Observability Operator は、FlowCollector API を提供します。これは、インストール時にインスタンス化され、eBPF agent、flowlogs-pipeline、netobserv-plugin コンポーネントを調整するように設定されています。FlowCollector は、クラスターごとに 1 つだけサポートされます。
eBPF agent は、各クラスター上で実行され、ネットワークフローを収集するためのいくつかの権限を持っています。flowlogs-pipeline はネットワークフローデータを受信し、データに Kubernetes 識別子を追加します。Loki を使用することを選択した場合、flowlogs-pipeline はフローログデータを Loki に送信し、保存およびインデックス作成を行います。netobserv-plugin は、動的 OpenShift Container Platform Web コンソールプラグインであり、Loki にクエリーを実行してネットワークフローデータを取得します。クラスター管理者は、Web コンソールでデータを表示できます。
Loki を使用しない場合は、Prometheus を使用してメトリクスを生成できます。これらのメトリクスと関連するダッシュボードには、Web コンソールからアクセスできます。詳細は、"Loki を使用しない Network Observability" を参照してください。
Network Observability Operator には、3 つの導入モデルオプションがあります。
Network Observability Operator は、Loki やその他のデータストアを管理しません。Loki Operator を使用して、Loki を別途インストールする必要があります。Kafka を使用する場合は、Kafka Operator を使用して別途インストールする必要があります。
- サービスデプロイメントモデル
-
FlowCollectorリソースのspec.deploymentModelフィールドがServiceに設定されている場合、エージェントはノードごとにデーモンセットとしてデプロイされます。flowlogs-pipeline は、サービスを含む標準的なデプロイメントです。spec.processor.consumerReplicasフィールドを使用することで、flowlogs-pipelineコンポーネントをスケーリングできます。 - 直接デプロイメントモデル
-
spec.deploymentModelフィールドがDirectに設定されている場合、エージェントとflowlogs-pipeline は両方ともノードごとにデーモンセットとしてデプロイされます。このモデルは、技術評価や小規模クラスターに適しています。しかし、大規模なクラスターでは、flowlogs-pipelineの各インスタンスが同じクラスター情報をキャッシュするため、メモリー効率が低下します。 - Kafka のデプロイメントモデル (オプション)
Kafka オプションを使用する場合、
eBPF エージェントはネットワークフローデータを Kafka に送信します。spec.processor.consumerReplicasフィールドを使用することで、flowlogs-pipelineコンポーネントをスケーリングできます。flowlogs-pipelineコンポーネントは、次の図に示すように、Kafka トピックからデータを読み取り、その後 Loki にデータを送信します。
5.3. Network Observability Operator のステータスと設定の表示
oc describe flowcollector/cluster コマンドを使用して、Network Observability Operator の現在のステータス、設定の詳細、生成されたリソースを検査します。
手順
次のコマンドを実行して、Network Observability Operator のステータスと設定を表示します。
$ oc describe flowcollector/cluster
第6章 Network Observability Operator の設定
Network Observability Operator を設定するには、クラスター全体の FlowCollector API リソース (クラスター) を更新して、コンポーネント設定とフロー収集設定を管理します。
FlowCollector はインストール中に明示的に作成されます。このリソースはクラスター全体で動作するため、単一の FlowCollector のみが許可され、cluster という名前を付ける必要があります。詳細は、FlowCollector API リファレンス を参照してください。
6.1. FlowCollector リソースの表示
統合されたセットアップや詳細フォームを介して、または YAML を直接編集して Network Observability Operator を設定することで、OpenShift Container Platform Web コンソールで FlowCollector リソースを表示および変更します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
-
cluster を選択し、YAML タブを選択します。そこで、
FlowCollectorリソースを変更して Network Observability Operator を設定できます。
6.1.1. FlowCollector リソースの例
eBPF サンプリング、会話の追跡、Loki の統合、コンソールクイックフィルターの設定を示す、FlowCollector カスタムリソースの包括的なアノテーション付きの例を確認します。
6.1.1.1. FlowCollector リソースのサンプル
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
networkPolicy:
enable: true
agent:
type: eBPF
ebpf:
sampling: 50
privileged: false
features: []
processor:
addZone: false
subnetLabels:
openShiftAutoDetect: true
customLabels: []
consumerReplicas: 3
loki:
enable: true
mode: LokiStack
lokiStack:
name: loki
namespace: netobserv-loki
consolePlugin:
enable: true
exporters: []ここでは、以下のようになります。
仕様エージェントタイプ-
eBPF は OpenShift Container Platform でサポートされている唯一のオプションであるため、
eBPF を使用する必要があります。 仕様エージェント ebpf サンプリング-
サンプリング間隔を指定します。デフォルトでは、eBPF のサンプリングは
50に設定されているため、パケットがサンプリングされる確率は 50 分の 1 です。サンプリング間隔の値が小さいほど、より多くの計算、メモリー、およびストレージリソースが必要になります。値が0または1の場合は、すべてのパケットがサンプリングされることを意味します。デフォルト値から始めて、実験結果を基に調整し、クラスターに最適な設定を決定することを推奨します。 仕様エージェント ebpf 特権- eBPF エージェント Pod を特権モードで実行するかどうかを指定します。デフォルト以外のネットワークの監視やパケット損失の追跡など、いくつかの機能を利用するには、特権ユーザーとして実行する必要があります。セキュリティー上の理由から、最小特権の原則に従い、これらの機能の一部が必要な場合にのみ有効にするべきです。特権モードを必要とする機能を、明示的に true に設定せずに有効にした場合、警告が表示されます。
spec.processor.addZone- ネットワークフローにクラウドアベイラビリティーゾーンを挿入するために使用されます。
仕様プロセッサーサブネットラベル- CIDR マッチングに基づいて、ネットワークフローに挿入するカスタムラベルのリストを指定します。
仕様.プロセッサー.コンシューマーレプリカ- プロセッサー Pod (flowlogs-pipeline) のレプリカ数を指定します。クラスターサイズに基づいた推奨事項については、リソース管理とパフォーマンスに関する考慮事項のセクションを参照してください。
仕様.loki.モード-
Loki への接続設定方法を、インストールモードに応じて指定します。Loki Operator のインストールで説明されているインストールパスを使用する場合は、モードを
LokiStackに設定する必要があり、spec.loki.lokiStackはインストールされたLokiStackリソース名と名前空間を参照する必要があります。 spec.loki.lokistack.namespace-
LokiStackリソースの名前空間を指定します。この値は、LokiStackカスタムリソースで定義されているmetadata.namespaceと一致する必要があります。この例ではnetobserv-lokiを使用していますが、コンポーネントごとに異なる名前空間を使用することも可能です。
6.2. Kafka を使用した FlowCollector リソースの設定
Kafka を高スループットかつ低遅延のデータフィードのために使用するように、FlowCollector リソースを設定します。
実行中の Kafka インスタンスを用意し、そのインスタンス内に OpenShift Container Platform ネットワークオブザーバビリティー専用の Kafka トピックを作成する必要があります。詳細は、AMQ Streams を使用した Kafka ドキュメント を参照してください。
前提条件
- Kafka のインストールが完了しました。Red Hat は、AMQ Streams Operator を使用して Kafka をサポートしています。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- クラスターを選択し、YAML タブをクリックします。
OpenShift Container Platform Network Observability Operator の
FlowCollectorリソースを、以下のサンプル YAML に示すように Kafka を使用するように変更します。FlowCollectorリソースの Kafka 設定のサンプルapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: deploymentModel: Kafka kafka: address: "kafka-cluster-kafka-bootstrap.netobserv" topic: network-flows tls: enable: falseここでは、以下のようになります。
spec.deploymentModel-
デプロイメントモデルを指定します。Kafka デプロイメントモデルを有効にするには、
ServiceではなくKafkaに設定してください。 spec.kafka.address-
Kafka ブートストラップサーバーのアドレスを指定します。ポート 9093 で TLS を使用するため、
kafka-cluster-kafka-bootstrap.netobserv:9093など、必要に応じてポートを指定できます。 仕様.kafka.top- Kafka で作成されるトピックの名前を指定します。Kafka で作成されたトピック名と一致する必要があります。
spec.kafka.tls-
通信暗号化を指定します。この設定を使用すると、Kafka との間のすべての通信を TLS または mTLS で暗号化できます。有効にする場合、Kafka CA 証明書は
、flowlogs-pipelineプロセッサーコンポーネントをデプロイする名前空間 (デフォルト:netobserv) と、eBPF エージェントをデプロイする名前空間 (デフォルト:netobserv-privileged) の両方で、ConfigMap または Secret として利用可能である必要があります。spec.kafka.tls.caCertを使用して証明書を参照します。mTLS を使用する場合は、クライアントシークレットもこれらの名前空間で利用できるようにしてください。シークレットは、Red Hat AMQ Streams User Operator を使用して生成できます。spec.kafka.tls.userCertを使用してシークレットを参照します。
6.3. エンリッチされたネットワークフローデータのエクスポート
FlowCollector リソースを設定して、補完されたネットワークフローデータを Kafka、IPFIX、または OpenTelemetry エンドポイントに同時にエクスポートし、Splunk や Prometheus などのツールによる外部使用を可能にします。
Kafka または IPFIX の場合、Splunk、Elasticsearch、Fluentd など、Kafka または IPFIX の入力をサポートするプロセッサーまたはストレージで、エンリッチされたネットワークフローデータを利用できます。
OpenTelemetry の場合、ネットワークフローデータとメトリクスを、Red Hat build of OpenTelemetry、Prometheus など、互換性のある OpenTelemetry エンドポイントにエクスポートできます。
設定後、ネットワークフローデータは利用可能な出力先に送信できます。詳細は、「ネットワークフロー形式のリファレンス」を参照してください。
前提条件
-
Network Observability の
flowlogs-pipelinePod から、Kafka、IPFIX、または OpenTelemetry コレクターエンドポイントを利用できる。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorを編集して、spec.exportersを次のように設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: exporters: - type: Kafka kafka: address: "kafka-cluster-kafka-bootstrap.netobserv" topic: netobserv-flows-export tls: enable: false - type: IPFIX ipfix: targetHost: "ipfix-collector.ipfix.svc.cluster.local" targetPort: 4739 transport: tcp - type: OpenTelemetry openTelemetry: targetHost: my-otelcol-collector-headless.otlp.svc targetPort: 4317 type: grpc logs: enable: true metrics: enable: true prefix: netobserv pushTimeInterval: 20s expiryTime: 2m # fieldsMapping: # input: SrcAddr # output: source.addressここでは、以下のようになります。
仕様のエクスポートタイプ-
エクスポートの種類を指定します。フローは、
IPFIX、OpenTelemetry、およびKafkaに個別に、または同時にエクスポートできます。 仕様エクスポート機能.kafka.topic- Network Observability Operator がすべてのフローをエクスポートする Kafka トピックを指定します。
spec.exporters.kafka.tls.enable-
Kafka との間の通信を SSL/TLS または mTLS のどちらで暗号化するかを指定します。有効にする場合、Kafka CA 証明書は、
flowlogs-pipelineプロセッサーコンポーネントがデプロイされている名前空間 (デフォルト:netobserv) にConfigMapまたはSecretとして存在する必要があります。spec.exporters.tls.caCertを使用して証明書を参照します。mTLS の場合、クライアントシークレットもこれらの名前空間で利用可能であり、spec.exporters.tls.userCertで参照される必要があります。 spec.exporters.ipfix.transport-
トランスポートプロトコルを指定します。デフォルト値は
tcpですが、udpを指定することもできます。 spec.exporters.openTelemetry.type-
OpenTelemetry 接続プロトコルを指定します。使用可能なオプションは
httpとgrpcです。 spec.exporters.openTelemetry.logs- ログをエクスポートするための OpenTelemetry の設定を指定します。エクスポートされるログは、Loki 用に作成されるログと同一です。
spec.exporters.openTelemetry.metrics-
Prometheus 用に作成されるメトリクスと同一のメトリクスをエクスポートするための OpenTelemetry 設定を指定します。これらは、
FlowCollectorリソースのspec.processor.metrics.includeListパラメーター、またはFlowMetricsリソースを介して定義されます。 spec.exporters.openTelemetry.metrics.pushTimeInterval- OpenTelemetry コレクターにメトリクスを送信する時間間隔を指定します。
spec.exporters.openTelemetry.fieldsMapping-
OpenTelemetry 形式の出力をカスタマイズするためのオプションのマッピングを指定します。ネットワークオブザーバビリティーフローのフォーマットは、自動的に OpenTelemetry 準拠のフォーマットに名前が変更されますが、このパラメーターを使用するとカスタムオーバーライドが可能です。たとえば、YAML のサンプルでは、
SrcAddrはネットワークオブザーバビリティー入力フィールドであり、OpenTelemetry の出力ではsource.addressに名前が変更されます。「ネットワークフローの形式リファレンス」で、Network Observability の形式と OpenTelemetry の形式の両方を確認できます。
6.4. FlowCollector リソースの更新
Web コンソールを使用する代わりに、flowcollector カスタムリソースで oc patch コマンドを使用して、eBPF サンプリングなどの特定の仕様を迅速に更新します。
手順
次のコマンドを実行して、
flowcollectorCR にパッチを適用し、spec.agent.ebpf.sampling値を更新します。$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"
6.5. ネットワークフロー取り込み時のフィルタリング
生成されるネットワークフローの数を減らすためにフィルターを作成します。ネットワークフローをフィルタリングすると、Network Observability コンポーネントのリソース使用量を削減できます。
次の 2 種類のフィルターを設定できます。
- eBPF エージェントフィルター
- flowlogs-pipeline フィルター
6.5.1. eBPF エージェントフィルター
eBPF エージェントフィルターはパフォーマンスを最大化します。このフィルターは、ネットワークフロー収集プロセスの最も早い段階で有効になるためです。
Network Observability Operator を使用して eBPF エージェントフィルターを設定するには、「複数のルールを使用した eBPF フローデータのフィルタリング」を参照してください。
6.5.2. flowlogs-pipeline フィルター
flowlogs-pipeline フィルターでは、トラフィックの選択をより細かく制御できます。このフィルターは、ネットワークフロー収集プロセスの遅い段階で有効になるためです。これは主にデータの保存を改善するために使用されます。
flowlogs-pipeline フィルターは、次の例に示すように、単純なクエリー言語を使用してネットワークフローをフィルタリングします。
(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"クエリー言語では次の構文を使用します。
| カテゴリー | 演算子 |
|---|---|
| 論理ブール演算子 (大文字と小文字の区別なし) |
|
| 比較演算子 |
|
| 単項演算子 |
|
flowlogs-pipeline フィルターは、FlowCollector リソースの spec.processor.filters セクションで設定できます。以下に例を示します。
flowlogs-pipeline フィルターの YAML の例
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
agent:
processor:
filters:
- query: |
(SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
outputTarget: Loki
sampling: 10ここでは、以下のようになります。
spec.processor.filters.outputTarget-
一致するフローの出力先を指定します。出力先は、
Loki、Prometheus、または外部システムなどです。このパラメーターを省略すると、システムは設定されたすべての出力にフローを送信します。 仕様プロセッサーフィルターサンプリング-
保存またはエクスポートされる一致するフローの数を制限するために、オプションのサンプリング間隔を指定します。たとえば、値が
10ということは、フローが維持される確率が 10 分の 1 であることを意味します。
6.6. クイックフィルターの設定
使用可能なソース、宛先、ユニバーサルフィルターキーのリストを使用して、FlowCollector リソース内のクイックフィルターを変更します。
値を二重引用符で囲むと、完全一致が可能になります。それ以外の場合、テキスト値には部分一致が使用されます。キーの最後にあるバング (!) 文字は、否定を意味します。YAML の変更に関する詳細なコンテキストは、サンプルの FlowCollector リソースを参照してください。
フィルターマッチングタイプ "all of" または "any of" は、ユーザーがクエリーオプションから変更できる UI 設定です。これは、このリソース設定の一部ではありません。
使用可能なすべてのフィルターキーのリストを次に示します。
| Universal* | ソース | 送信先 | 説明 |
|---|---|---|---|
| namespace |
|
| 特定の namespace に関連するトラフィックをフィルタリングします。 |
| name |
|
| 特定の Pod、サービス、またはノード (ホストネットワークトラフィックの場合) など、特定のリーフリソース名に関連するトラフィックをフィルター処理します。 |
| kind |
|
| 特定のリソースの種類に関連するトラフィックをフィルタリングします。リソースの種類には、リーフリソース (Pod、Service、または Node)、または所有者リソース (Deployment および StatefulSet) が含まれます。 |
| owner_name |
|
| 特定のリソース所有者に関連するトラフィックをフィルタリングします。つまり、ワークロードまたは Pod のセットです。たとえば、Deployment 名、StatefulSet 名などです。 |
| resource |
|
|
一意に識別する正規名で示される特定のリソースに関連するトラフィックをフィルタリングします。正規の表記法は、namespace の種類の場合は |
| address |
|
| IP アドレスに関連するトラフィックをフィルタリングします。IPv4 と IPv6 がサポートされています。CIDR 範囲もサポートされています。 |
| mac |
|
| MAC アドレスに関連するトラフィックをフィルタリングします。 |
| port |
|
| 特定のポートに関連するトラフィックをフィルタリングします。 |
| host_address |
|
| Pod が実行しているホスト IP アドレスに関連するトラフィックをフィルタリングします。 |
| protocol | 該当なし | 該当なし | TCP や UDP などのプロトコルに関連するトラフィックをフィルタリングします。 |
-
ソースまたは宛先のいずれかのユニバーサルキーフィルター。たとえば、フィルタリング
name: 'my-pod'は、使用される一致タイプ (Match all または Match any) に関係なく、my-podからのすべてのトラフィックとmy-podへのすべてのトラフィックを意味します。
6.7. リソース管理およびパフォーマンスに関する考慮事項
パフォーマンス基準を管理し、ネットワークオブザーバビリティーのためのリソース消費を最適化するために必要な、eBPF サンプリング、機能の有効化、リソース制限などの重要な設定を確認します。
Network Observability に必要なリソースの量は、クラスターのサイズと、クラスターが可観測データを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を設定すると、最適なセットアップと可観測性のニーズを満たす可能性があります。
次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。
- eBPF サンプリング
-
サンプリング仕様
spec.agent.ebpf.samplingを設定して、リソースを管理できます。デフォルトでは、eBPF サンプリングは50に設定されているため、フローがサンプリングされる確率は 50 分の 1 になります。サンプリング間隔の値が小さいほど、より多くの計算、メモリー、およびストレージリソースが必要になります。値が0または1の場合、すべてのフローがサンプリングされます。デフォルト値から始めて、実験結果を基に調整し、クラスターに最適な設定を決定することを推奨します。 - eBPF の機能
- 有効にされた機能が増えるほど、CPU とメモリーへの影響が大きくなります。該当する機能の完全なリストは、"ネットワークトラフィックのモニタリング" を参照してください。
- Loki を使用しない場合
- Loki ではなく Prometheus を代わりに使用することで、Network Observability に必要なリソースの量を削減できます。たとえば、Network Observability を Loki なしで設定すると、サンプリング間隔の値に応じて、メモリー使用量が合計で 20 - 65% 削減され、CPU 使用率が 10 - 30% 低下します。詳細は、「Loki を使用しない Network Observability」を参照してください。
- インターフェイスの制限または除外
-
spec.agent.ebpf.interfacesおよびspec.agent.ebpf.excludeInterfacesの値を設定して、観測されるトラフィック全体を削減します。デフォルトでは、エージェントは、excludeInterfacesおよびlo(ローカルインターフェイス) にリストされているインターフェイスを除く、システム内のすべてのインターフェイスを取得します。インターフェイス名は、使用される Container Network Interface (CNI) によって異なる場合があることに注意してください。 - パフォーマンスのファインチューニング
Network Observability をしばらく実行した後、次の設定を使用してパフォーマンスを微調整できます。
-
リソース要件と制限:
spec.agent.ebpf.resourcesおよびspec.processor.resources仕様を使用して、クラスターで予想される負荷とメモリー使用量に合わせてリソース要件と制限を調整します。多くの中規模のクラスターには、デフォルトの制限の 800MB で十分な場合があります。 -
キャッシュの最大フロータイムアウト: eBPF エージェントの
spec.agent.ebpf.cacheMaxFlowsおよびspec.agent.ebpf.cacheActiveTimeout仕様を使用して、エージェントによってフローが報告される頻度を制御します。値が大きいほど、エージェントで生成されるトラフィックが少なくなり、これは CPU 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。
-
リソース要件と制限:
6.7.1. リソースの留意事項
Network Observability Operator の設定は、クラスターのワークロード規模に基づいて調整できます。以下の基本例を参考に、環境に適したリソース制限と設定を決定してください。
表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
これらの推奨事項の策定に使用されたテストベッドは以下のとおりです。
-
エクストラスモール:10 ノードクラスター、ワーカーあたり 4 つの vCPU と 16GiB のメモリー、
LokiStackサイズ1x.extra-small、AWS M6i インスタンスでテスト済み。 -
小規模: 25 ノードのクラスター、ワーカーあたり 16 個の vCPU と 64GiB のメモリー、
LokiStackサイズ1x.small、AWS M6i インスタンスでテスト済み。 -
大規模: 250 ノードのクラスター、ワーカーあたり 16 個の vCPU と 64GiB のメモリー、
LokiStackサイズ1x.medium、AWS M6i インスタンスでテスト済み。ワーカーノードとコントローラーノードに加えて、3 つのインフラストラクチャーノード (サイズM6i.12xlarge) と 1 つのワークロードノード (サイズM6i.8xlarge) がテストされました。
| 基準 | 極小規模 (10 ノード) | 小規模 (25 ノード) | 大規模 (250 ノード) |
|---|---|---|---|
|
Operator のメモリー制限: |
|
|
|
|
eBPF エージェントのサンプリング間隔: |
|
|
|
|
eBPF エージェントのメモリー制限: |
|
|
|
|
eBPF エージェントキャッシュサイズ: |
|
|
|
|
プロセッサーメモリー制限: |
|
|
|
|
プロセッサーレプリカ: |
|
|
|
|
デプロイメントモデル: |
|
|
|
| Kafka パーティション: Kafka のインストール | 該当なし |
|
|
| Kafka ブローカー:Kafka のインストール | 該当なし |
|
|
6.7.2. メモリーと CPU の合計平均使用量
異なる eBPF サンプリング値を使用した 2 つの異なるトラフィックシナリオ (Test 1 と Test 2) における、ネットワークオブザーバビリティーコンポーネントの CPU およびメモリーの合計平均使用量を詳しく示した表について説明します。
次の表は、2 つの異なるテスト (Test 1、Test 2) について、サンプリング値が 1 および 50 であるクラスターの合計リソース使用量の平均を示しています。テストは次の点で異なります。
-
Test 1は、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数に加え、大量の Ingress トラフィックを考慮しており、eBPF エージェントに負荷をかけた、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表しています。たとえば、Test 1は、76 個の namespace、5153 個の Pod、および 2305 個のサービスで構成され、ネットワークトラフィックの規模は ~350 MB/秒です。 -
Test 2は、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数に加え、大量の Ingress トラフィックを考慮しており、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表しています。たとえば、Test 2は、553 個の namespace、6998 個の Pod、および 2508 個のサービスで構成され、ネットワークトラフィックの規模は ~950 MB/秒です。
さまざまなテストでさまざまなタイプのクラスターユースケースが例示されているため、この表の数値は並べて比較しても直線的に増加しません。代わりに、これらは個人のクラスター使用状況を評価するためのベンチマークとして使用することを目的としています。表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
Prometheus にエクスポートされたメトリクスは、リソースの使用状況に影響を与える可能性があります。メトリクスのカーディナリティー値は、リソースがどの程度影響を受けるかを判断するのに役立ちます。詳細は、関連情報セクションの「ネットワークフローの形式」を参照してください。
| サンプリング値 | 使用されるリソース | テスト 1 (25 ノード) | テスト 2 (250 ノード) |
|---|---|---|---|
| Sampling = 50 | NetObserv の CPU 合計使用量 | 1.35 | 5.39 |
| NetObserv RSS (メモリー) の合計使用量 | 16 GB | 63 GB | |
| Sampling = 1 | NetObserv の CPU 合計使用量 | 1.82 | 11.99 |
| NetObserv RSS (メモリー) の合計使用量 | 22 GB | 87 GB |
概要: この表は、すべての機能が有効になっているエージェント、FLP、Kafka、Loki を含む Network Observability の平均合計リソース使用量を示しています。有効な機能の詳細は、「ネットワークトラフィックの観測」で説明されている機能を参照してください。このテストで有効になっているすべての機能が記載されています。
第7章 テナントごとのネットワークオブザーバビリティーモデル
FlowCollectorSlice リソースを使用すると、グローバルクラスターのガバナンスを維持しながら、ネットワークトラフィック分析の管理をプロジェクト管理者に委任できます。
7.1. テナントごとの階層的ガバナンスとテナントの自治
クラスター管理者はグローバルなガバナンスを維持しつつ、プロジェクト管理者がそれぞれのネームスペース内でネットワークトラフィックの可視性を管理できるようにすることができます。
Network Observability Operator は、階層型設定モデルを使用してマルチテナンシーをサポートします。このアーキテクチャーは、大規模なデプロイメントや Hosted Control Plane 環境において、個々のチームがクラスター管理者の介入なしにセルフサービスによる可視性を必要とする場合に有効です。
階層モデルは以下の設定要素から成ります。
- グローバルガバナンス
-
クラスター管理者は、グローバルな
FlowCollectorリソースを管理します。このリソースは、オブザーバビリティーインフラストラクチャーを定義し、テナントごとの設定が許可されているかどうかを判断します。 - テナントの自治
-
プロジェクト管理者は、
FlowCollectorSliceリソースを管理します。この名前空間スコープのカスタムリソース (CR) を使用すると、チームはワークロードに対して特定のオブザーバビリティー設定を定義できます。
7.2. フローの詳細な収集のための FlowCollectorSlice リソース
FlowCollectorSlice は、きめ細かなマルチテナントネットワークフロー収集を可能にするカスタムリソース定義 (CRD) です。名前空間やサブネットに基づいて論理スライスを定義することで、トラフィックを選択的に収集し、クラスター全体ではなく特定のワークロードに対してカスタムサンプリングを適用できます。
これは、既存の FlowCollector カスタムリソースを補完するもので、すべてのトラフィックに一律に適用される単一のグローバル設定ではなく、きめ細かく、選択的で、マルチテナントに対応したフロー収集を可能にします。
スライスベースの収集が有効になっている場合、少なくとも 1 つの FlowCollectorSlice に一致するトラフィックのみが収集されるため、管理者は監視対象のネットワークフローを正確に制御できます。
7.2.1. FlowCollectorSlice の利点
デフォルトでは、ネットワークフロー収集はクラスター内のすべてのトラフィックに一律に適用されます。これはデータ量の過剰と柔軟性の低下につながる可能性がある。
FlowCollectorSlice を 使用することで、以下の利点が得られます。
- 特定のネームスペースまたはワークロードに対して、選択的なフロー収集を可能にします。
- マルチテナントおよび環境ベースのオブザーバビリティーをサポートします。
- 不要なトラフィックをフィルタリングすることで、ストレージと処理のコストを削減します。
- オプトイン方式の設定により、下位互換性を維持します。
7.2.2. FlowCollector と FlowCollectorSlice の関係
FlowCollector リソースはクラスター全体のフロー収集動作を定義する一方、FlowCollectorSlice リソースはスライスベースのフィルタリングが有効になっている場合に、どのトラフィックが収集対象となるかを定義します。
FlowCollector.spec.slicesConfig フィールドは、スライス定義の適用方法を制御します。
7.2.3. コレクションモード
スライスの動作は、FlowCollector.spec.slicesConfig.collectionMode フィールドによって制御されます。フィールドを以下のいずれかの収集モードに設定してください。
- オールウェイズコレクト
- すべてのクラスターネームスペースからネットワークフローを収集します。
-
FlowCollectorSliceリソースで定義されたサブネットおよびサンプリング設定を適用します。 -
FlowCollectorSliceリソース内の名前空間選択ロジックを無視します。 - 後方互換性のために、デフォルトのコレクション動作を維持します。
- 許可リスト
-
少なくとも 1 つの
FlowCollectorSliceリソースに一致するトラフィックのみを収集します。 - オプションの名前空間許可リストには、コレクション内の選択された名前空間が含まれます。
-
少なくとも 1 つの
7.2.4. FlowCollectorSlice の状態
各 FlowCollectorSlice リソースは、以下の情報を報告する ステータス サブリソースを公開します。
- 検証結果。
- リコンシリエーション状態。
- スライスが正常に適用されたかどうか。
このステータスにより、管理者はスライス定義がアクティブであり、期待どおりに機能していることを確認できます。
7.3. Network Observability OperatorFlowCollectorSlice を有効にする
FlowCollector リソースで FlowCollectorSlice 機能を有効にすると、クラスター管理者はフロー収集とデータエンリッチメントの管理を特定の名前空間に委任できるようになります。
プロジェクト管理者が自身の設定を管理できるようになる前に、クラスター管理者は FlowCollector カスタムリソースを有効にして、FlowCollectorSlice カスタムリソースを監視するように設定する必要があります。
前提条件
- Network Observability Operator がインストールされています。
-
クラスター内に
FlowCollectorカスタムリソースが存在します。 -
cluster-admin特権がある。
手順
以下のコマンドを実行して、
FlowCollectorカスタムリソースを編集します。$ oc edit flowcollector clusterspec.processor.slicesConfigフィールドを設定して、スライスの使用が許可される名前空間を定義します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: slicesConfig: enable: true collectionMode: AllowList namespacesAllowList: - /openshift-.*|netobserv.*/ここでは、以下のようになります。
spec.processor.sliceConfig.enable-
FlowCollectorSlice機能が有効になっているかどうかを指定します。そうでない場合、FlowCollectorSliceという種類のリソースはすべて無視されます。 spec.processor.sliceConfig.collectionMode-
FlowCollectorSliceカスタムリソースがフロー収集プロセスにどのように影響するかを指定します。AlwaysCollectに設定すると、FlowCollectorSliceの有無に関わらず、すべてのフローが収集されます。AllowListに設定すると、FlowCollectorSliceリソースが存在する名前空間、またはグローバルnamespacesAllowListで設定された名前空間に関連するフローのみが収集されます。 spec.processor.sliceConfig.namespacesAllowListFlowCollectorSliceが存在するかどうかにかかわらず、常にフローが収集される名前空間のリストを指定します。注記namespacesAllowListフィールドは、複数の名前空間をキャプチャーするための/openshift-.*/のような正規表現、または特定の名前空間に一致させるためのnetobservのような厳密な等価性をサポートしています。
- 変更を保存し、エディターを終了します。
検証
-
Web コンソールの ネットワークトラフィック ページに、
netobserv名前空間とopenshift-で始まる名前空間からのネットワークフローのみが表示されることを確認してください。
7.3.1. Network Observability OperatorFlowCollectorSlice を無効にする
Network Observability Operator でスライスベースのフィルタリングを無効にすると、既存の FlowCollectorSlice リソースを保持したまま、グローバルなフロー収集を再開できます。
手順
以下のコマンドを実行して、
FlowCollectorリソースを編集します。$ oc edit flowcollector clusterspec.processor.slicesConfig.collectionModeフィールドをAlwaysCollectに設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: slicesConfig: enable: true collectionMode: AlwaysCollect ...変更を保存します。
すべてのトラフィックに対するフロー収集が再開され、既存の
FlowCollectorSliceリソースは将来の使用のために引き続き利用可能です。
7.4. プロジェクト管理者として FlowCollectorSlice を設定する
プロジェクト管理者は、分散型ネットワークトラフィック分析用のカスタムリソースである FlowCollectorSlice を 設定することで、自身のネームスペース内でフロー収集とデータエンリッチメントを管理できます。
前提条件
- Network Observability Operator がインストールされています。
-
あなたは、その名前空間に対する
プロジェクト管理者権限を持っています。
手順
flowCollectorSlice.yamlという名前の YAML ファイルを作成します。apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollectorSlice metadata: name: flowcollectorslice-sample namespace: my-app spec: sampling: 1 subnetLabels: - name: EXT:Database cidrs: - 192.168.50.0/24以下のコマンドを実行して設定を適用します。
$ oc apply -f flowCollectorSlice.yaml
検証
- OpenShift Container Platform コンソールで、[監視] → [ネットワークトラフィック] に移動します。
-
EXT:Databaseラベルを使用して、192.168.50.0/24 サブネットへのフローが監視されていることを確認してください。
7.5. FlowCollectorSlice [flows.netobserv.io/v1alpha1]
- 説明
- FlowCollectorSlice は、名前空間テナントごとに FlowCollector の設定の一部を分散化できるようにする API です。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。 |
|
|
| 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。 |
|
|
| FlowCollectorSliceSpec は FlowCollectorSlice の望ましい状態を定義します |
7.5.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
7.5.2. .spec
- 説明
- FlowCollectorSliceSpec は FlowCollectorSlice の望ましい状態を定義します
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
FlowCollectorSlice で設定されたサブネットラベルは、関連する名前空間のフローに限定されないことに注意してください。この設定を使用すると、クラスター全体の任意のフローにラベルを付けることができます。ただし、ルールが競合する場合は、クラスタースコープの FlowCollector で定義されたサブネットラベルが優先されます。 |
7.5.3. .spec.subnetLabels
- 説明
subnetLabels を使用すると、サブネットと IP アドレスのラベル付けをカスタマイズして、クラスター外部のワークロードや Web サービスを識別することができます。デフォルトのクイックフィルターや提供されているメトリクス例を使用するには、外部サブネットにはEXT:という接頭辞を付けるか、ラベルを付けないかのどちらかにする必要があります。
FlowCollectorSlice で設定されたサブネットラベルは、関連する名前空間のフローに限定されないことに注意してください。この設定を使用すると、クラスター全体の任意のフローにラベルを付けることができます。ただし、ルールが競合する場合は、クラスタースコープの FlowCollector で定義されたサブネットラベルが優先されます。
- 型
-
array
7.5.4. .spec.subnetLabels[]
- 説明
- SubnetLabel を使用すると、クラスター外部のワークロードや Web サービスの識別などのために、サブネットと IP にラベルを付けることができます。
- 型
-
object - 必須
-
cidrs -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
マッチしたフローにフラグを設定するために使用するラベル名。デフォルトのクイックフィルターや提供されているメトリクス例を使用するには、外部サブネットには |
第8章 ネットワークポリシー
管理者は、netobserv namespace 用のネットワークポリシーを作成できます。このポリシーにより、Network Observability Operator への受信および送信アクセスを保護します。
8.1. FlowCollector カスタムリソースを使用したネットワークポリシーの設定
Pod のトラフィックを制御するために、Ingress および Egress ネットワークポリシーを設定できます。これにより、セキュリティーが強化され、必要なネットワークフローデータだけが収集されます。これにより、ノイズが削減され、コンプライアンスがサポートされるとともに、ネットワーク通信に対する可視性が向上します。
FlowCollector カスタムリソース (CR) を設定することで、Network Observability 用の Egress および Ingress ネットワークポリシーをデプロイできます。デフォルトでは、spec.NetworkPolicy.enable 仕様は true に設定されています。
ネットワークポリシーを持つ別の namespace に Loki、Kafka、または任意のエクスポーターをインストールした場合は、Network Observability コンポーネントがそれらと通信できることを確認する必要があります。セットアップについて、次の点を考慮してください。
-
Loki への接続 (
FlowCollectorCR のspec.lokiパラメーターで定義) -
Kafka への接続 (
FlowCollectorCR のspec.kafkaパラメーターで定義) -
任意のエクスポーターへの接続 (FlowCollector CR の
spec.exportersパラメーターで定義) -
Loki を使用していて、Loki をポリシーターゲットに含める場合は、外部オブジェクトストレージへの接続 (
LokiStack関連のシークレットで定義)
手順
- Web コンソールで、Ecosystem → Installed Operators ページに移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorCR を設定します。設定例は次のとおりです。ネットワークポリシー用の
FlowCollectorCR の例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv networkPolicy: enable: true additionalNamespaces: ["openshift-console", "openshift-monitoring"] # ...ここでは、以下のようになります。
spec.networkPolicy.enable-
ネットワークポリシー管理を有効にするかどうかを指定します。デフォルト値は
trueです。 spec.networkPolicy.additionalNamespaces-
ネットワークポリシーに含める名前空間を指定します。デフォルト値は
["openshift-console"、"openshift-monitoring"]です。
第9章 ネットワークオブザーバビリティー DNS 解決分析
DNS 解決分析が eBPF ベースのデコードを使用してサービス検出の問題を特定する方法を学び、FlowCollector リソースで DNS トラッキングを有効にして、ネットワークフローレコードにドメイン名を追加する手順に従います。
9.1. DNS 解決分析の戦略的メリット
DNS 解決分析を使用して、eBPF フローレコードにドメイン名とステータスコードを付加することで、ネットワーク伝送障害とサービス検出の問題を区別します。
標準のフローログには、ポート 53 でトラフィックが発生したことしか記録されていません。DNS 解決分析を使用すると、次のタスクを実行できます。
-
識別までの平均時間 (MTTI) の短縮: ネットワークルーティングの障害と、
NXDOMAINエラーなどの DNS 解決の障害を即座に区別します。 -
内部サービスの遅延を測定する: CoreDNS が特定の内部ルックアップ (例:
my-service.namespace.svc.cluster.local) に応答するのにかかる時間を追跡します。 - 外部依存関係の監査: サイドカーや手動パケットキャプチャーを必要とせずに、ワークロードがどの外部 API またはサードパーティードメインと通信しているかを監査します。
- セキュリティー体制の強化: 内部ワークロードによって照会される完全修飾ドメイン名 (FQDN) を監査することで、潜在的なデータ漏洩やコマンド＆コントロール (C2) 活動を検出します。
9.1.1. DNS フローエンリッチメント
この機能が有効になっている場合、eBPF エージェントはフローレコードを拡充します。このメタデータを使用すると、送信元 IP アドレスだけでなく、接続の意図 (ドメイン) に基づいてトラフィックをグループ化およびフィルタリングできます。
拡張された DNS デコードにより、eBPF エージェントはポート 53 上の UDP および TCP DNS トラフィックと、DNS リクエストのクエリー名を検査できるようになります。
9.2. ネットワークオブザーバビリティーの DNS ドメイン追跡を設定する
Network Observability Operator で DNS 追跡を有効にすると、クラスター内のネットワークフローにおける DNS クエリー名、応答コード、および遅延を監視できます。
前提条件
- Network Observability Operator がインストールされています。
-
cluster-admin特権がある。 -
あなたは
FlowCollectorカスタムリソースについてよくご存知でしょう。
手順
以下のコマンドを実行して、
FlowCollectorリソースを編集します。$ oc edit flowcollector clustereBPF エージェントを設定して、DNS 追跡機能を有効にします。
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: agent: type: eBPF ebpf: features: - DNSTrackingここでは、以下のようになります。
spec.agent.type.ebpf.features-
eBPF エージェントで有効にする機能のリストを指定します。DNS トラッキングを有効にするには、このリストに
DNSTrackingを追加してください。
- エディターを保存し、終了します。
検証
- OpenShift Container Platform の Web コンソールで、[監視] → [ネットワークトラフィック] に移動します。
- トラフィックフロー ビューで、列の管理 アイコンをクリックします。
- DNS クエリー名、DNS 応答コード、DNS レイテンシー の各列が選択されていることを確認してください。
-
ポートを
53に設定して結果を絞り込みます。 - フローテーブルの列にドメイン名と DNS メタデータが入力されていることを確認してください。
9.3. DNS フローの強化と分析に関する参考資料
ネットワークフローに追加されたメタデータを特定し、DNS データを活用してネットワークを最適化し、クラスターのパフォーマンスとストレージへの影響を理解する。
以下の表は、DNS トラッキングが有効になっている場合にネットワークフローに追加されるメタデータフィールドについて説明しています。
クエリー名が欠落したり、切り詰められたりするのは、圧縮ポインターまたはキャッシュの制限による可能性があります。
| フィールド | 説明 | 例 |
|---|---|---|
|
| 照会対象の完全修飾ドメイン名 (FQDN)。 |
|
|
| DNS サーバーから返されるステータスコード。 |
|
|
| クエリーとレスポンスを照合するために使用されるトランザクション ID。 |
|
9.3.1. ネットワーク最適化のために DNS データを活用する
取得した DNS メタデータは、以下の運用上の成果に活用してください。
- 外部依存関係の監査: ワークロードが、許可されていない外部 API や高リスクのドメインにアクセスしていないことを確認します。
-
パフォーマンスチューニング:
DNS レイテンシーを監視して、CoreDNSPod に追加のスケーリングが必要かどうか、またはアップストリームの DNS プロバイダーに遅延があるかどうかを特定します。
9.3.2. 設定ミスを特定する
NXDOMAIN 応答が頻繁に発生する場合は、通常、アプリケーションコード内のサービス検出エラー、または古い環境変数を示しています。
Kubernetes では、サービスや Pod に対する DNS 検索が原因で、NXDOMAIN エラーが頻繁に発生する可能性があります。これらの結果は必ずしも設定ミスや URL の破損を示すものではありませんが、パフォーマンスに悪影響を与える可能性があります。
my-svc.my-namespace.svc のような、一見有効なサービスまたは Pod ホスト名が返されるにもかかわらず NXDOMAIN エラーが返される場合、リゾルバーが異なるサフィックスに対して DNS を照会するように設定されている可能性があります。ドメイン名の末尾にドットを追加することで、リゾルバーに対してドメイン名が曖昧でないことを伝え、これを最適化できます。
たとえば、https://my-svc.my-namespace.svc の代わりに、https://my-svc.my-namespace.svc.cluster.local を使用します。 末尾にドットを付けます。
9.3.3. Loki のストレージに関する考慮事項
DNS トラッキングは、フローごとのラベル数とメタデータ量を増加させます。Loki ストレージのサイズが、増加したログ容量に対応できることを確認してください。
第10章 ネットワークトラフィックの観測
管理者は、OpenShift Container Platform Web コンソールでネットワークトラフィックを観測し、詳細なトラブルシューティングと分析を行うことができます。この機能は、トラフィックフローのさまざまなグラフィカル表現から洞察を得るのに役立ちます。
10.1. Overview ビューからのネットワークトラフィックの観測
ネットワークトラフィック 概要 ビューでは、集計されたフローメトリクスとアプリケーション間の通信に関する視覚的な情報を提供します。管理者はこれらのメトリクスを使用して、データ量の監視、接続性のトラブルシューティング、およびクラスター全体における異常なトラフィックパターンの検出を行うことができます。
概要 ビューには、OpenShift Container Platform クラスター内のネットワークトラフィックの集計が表示され、どのアプリケーションが通信しているか、転送されているデータ量などを確認できます。送信元、宛先、フローの種類別に詳細な分析結果を提供するとともに、上位のトラフィックフローと平均バイトレートも表示します。
管理者として、接続の問題をトラブルシューティングしたり、異常なトラフィックパターンを検出したり、アプリケーションのパフォーマンスを最適化したりできます。ネットワークの動作状況を素早く把握できるため、優先順位付けが容易になり、リソースの効率的な利用を確保できます。
10.1.1. 概要ビューの操作
OpenShift Container Platform コンソールのネットワークトラフィック 概要 ビューに移動すると、フローレート統計のグラフ表示を確認したり、利用可能なオプションを使用して表示範囲を設定したりできます。
前提条件
- 管理者権限でクラスターにアクセスできる。
手順
- Observe → Network Traffic に移動します。
- ネットワークトラフィック ページで、Overview タブをクリックします。
- メニューアイコンをクリックして、各流量データの範囲を設定してください。
10.1.2. 概要ビューの詳細オプションの設定
グラフの範囲、ラベルの切り捨て、パネル管理などの高度なオプションを設定することで、ネットワークトラフィックの 概要 ビューをカスタマイズし、流量統計やトラフィックデータの表示を最適化できます。
詳細オプションにアクセスするには、Show advanced options をクリックします。Display options ドロップダウンメニューを使用して、グラフの詳細を設定できます。利用可能なオプションは次のとおりです。
- Scope: ネットワークトラフィックが流れるコンポーネントを表示する場合に選択します。スコープは、Node、Namespace、Owner、Zones、Cluster、または Resource に設定できます。Owner はリソースの集合体です。Resource は、ホストネットワークトラフィックの場合は Pod、サービス、ノード、または不明な IP アドレスです。デフォルト値は Namespace です。
- Truncate labels: ドロップダウンリストから必要なラベルの幅を選択します。デフォルト値は M です。
10.1.2.1. パネルとディスプレイの管理
表示する必要なパネルを選択したり、並べ替えたり、特定のパネルに焦点を当てたりすることができます。パネルを追加または削除するには、Manage panels をクリックします。
デフォルトでは、次のパネルが表示されます。
- 上位 X の平均バイトレート
- 上位 X のバイトレートと合計の積み上げ値
他のパネルは Manage panels で追加できます。
- 上位 X の平均パケットレート
- 上位 X のパケットレートと合計の積み上げ値
Query options を使用すると、Top 5、Top 10、または Top 15 のレートを表示するかどうかを選択できます。
10.1.3. パケットドロップの追跡
eBPF ベースのパケットドロップ追跡機能を使用してネットワークパケットロスを監視および分析します。この機能は、ドロップ場所を特定し、ホストまたは OVS 固有のドロップ理由を検出し、概要 ビューに専用のグラフィカルパネルを提供します。
Overview ビューで、パケットロスが発生したネットワークフローレコードのグラフィック表示を設定できます。eBPF トレースポイントフックを採用すると、TCP、UDP、SCTP、ICMPv4、ICMPv6 プロトコルのパケットドロップに関する貴重な知見を得ることができ、その結果、以下のアクションにつながる可能性があります。
- 識別: パケットドロップが発生している正確な場所とネットワークパスを特定します。ドロップが発生しやすい特定のデバイス、インターフェイス、またはルートがあるか判断します。
- 根本原因分析: eBPF プログラムによって収集されたデータを調査し、パケットドロップの原因を把握します。たとえば、輻輳、バッファーの問題、特定のネットワークイベントなどの原因です。
- パフォーマンスの最適化: パケットドロップをより明確に把握し、バッファーサイズの調整、ルーティングパスの再設定、Quality of Service (QoS) 対策の実装など、ネットワークパフォーマンスを最適化するための手順を実行できます。
パケットドロップの追跡が有効になっている場合、デフォルトで Overview に次のパネルが表示されます。
- 上位 X のパケットドロップの状態と合計の積み上げ値
- 上位 X のパケットドロップの原因と合計の積み上げ値
- 上位 X の平均パケットドロップレート
- 上位 X のパケットドロップレートと合計の積み上げ値
他のパケットドロップパネルは Manage panels で追加できます。
- 上位 X の平均ドロップバイトレート
- 上位 X の平均ドロップバイトレートと合計の積み上げ値
10.1.3.1. パケットドロップの種類
ネットワークオブザーバビリティーによって検出されるパケット損失には、ホスト側での損失と OVS 側での損失の 2 種類があります。ホストドロップには SKB_DROP という接頭辞が付き、OVS ドロップには OVS_DROP という接頭辞が付きます。ドロップされたフローは、各ドロップタイプの説明へのリンクとともに、Traffic flows テーブルのサイドパネルに表示されます。ホストドロップの理由の例は次のとおりです。
-
SKB_DROP_REASON_NO_SOCKET: ソケットが検出されないため、パケットがドロップされました。 -
SKB_DROP_REASON_TCP_CSUM: TCP チェックサムエラーによりパケットがドロップされました。
OVS ドロップの理由の例は次のとおりです。
-
OVS_DROP_LAST_ACTION: 暗黙的なドロップアクション (設定されたネットワークポリシーなど) によりドロップされた OVS パケット。 -
OVS_DROP_IP_TTL: IP TTL の期限切れにより OVS パケットがドロップされました。
パケットドロップの追跡を有効化および使用する方法の詳細は、このセクションの 関連情報 を参照してください。
10.1.4. DNS 追跡
eBPF ベースの DNS トラッキングを使用して DNS アクティビティーを監視することで、クエリーパターンの把握、セキュリティー脅威の検出、概要 ビューの専用グラフィカルパネルを通じたレイテンシー問題のトラブルシューティングが可能になります。
Overview ビューで、ネットワークフローの Domain Name System (DNS) 追跡のグラフィカル表示を設定できます。拡張 Berkeley Packet Filter (eBPF) トレースポイントフックを使用する DNS 追跡は、さまざまな目的に使用できます。
- ネットワーク監視: DNS クエリーと応答に関する知見を得ることで、ネットワーク管理者は異常パターン、潜在的なボトルネック、またはパフォーマンスの問題を特定できます。
- セキュリティー分析: マルウェアによって使用されるドメイン名生成アルゴリズム (DGA) などの不審な DNS アクティビティーを検出したり、セキュリティーを侵害する可能性のある不正な DNS 解決を特定したりします。
- トラブルシューティング: DNS 解決手順を追跡し、遅延を追跡し、設定ミスを特定することにより、DNS 関連の問題をデバッグします。
デフォルトでは、DNS 追跡が有効になっている場合、Overview に、次の空でないメトリクスがドーナツグラフまたは折れ線グラフで表示されます。
- 上位 X の DNS レスポンスコード
- 上位 X の平均 DNS 遅延と合計
- 上位 X の 90 パーセンタイルの DNS 遅延
他の DNS 追跡パネルは Manage panels で追加できます。
- 下位 X の最小 DNS 遅延
- 上位 X の最大 DNS 遅延
- 上位 X の 99 パーセンタイルの DNS 遅延
この機能は、IPv4 および IPv6 の UDP および TCP プロトコルでサポートされています。
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.1.5. ラウンドトリップタイム
TCP ラウンドトリップタイム (RTT) メトリクスを使用してネットワークフローの遅延を分析します。このメトリクスは eBPF フックポイントを使用してパフォーマンスのボトルネックを特定し、概要ビューの専用パネルを通じて TCP 関連の問題をトラブルシューティングします。
TCP の平滑化されたラウンドトリップタイム (sRTT) を使用して、ネットワークフローの遅延を分析できます。fentry/tcp_rcv_established eBPF フックポイントから取得した RTT を使用して TCP ソケットから sRTT を読み取ると、次のことに役立てることができます。
- ネットワーク監視: TCP の遅延に関する知見を得ることで、ネットワーク管理者は、異常なパターン、潜在的なボトルネック、またはパフォーマンスの問題を特定できます。
- トラブルシューティング: 遅延を追跡し、設定ミスを特定することにより、TCP 関連の問題をデバッグします。
デフォルトでは、RTT が有効になっている場合、Overview に次の TCP RTT メトリクスが表示されます。
- 上位 X の 90 パーセンタイルの TCP ラウンドトリップタイムと合計
- 上位 X の平均 TCP ラウンドトリップタイムと合計
- 下位 X の最小 TCP ラウンドトリップタイムと合計
他の RTT パネルは Manage panels で追加できます。
- 上位 X の最大 TCP ラウンドトリップタイムと合計
- 上位 X の 99 パーセンタイルの TCP ラウンドトリップタイムと合計
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.1.6. eBPF フローのルールフィルター
eBPF フロールールフィルタリングを使用して、ポートと CIDR 表記に基づいてキャプチャー基準を指定することで、パケットキャプチャー量を制御し、専用のヘルスダッシュボードと Prometheus メトリクスを通じてフィルターのパフォーマンスを監視します。
ルールベースのフィルタリングを使用して、eBPF フローテーブルにキャッシュされるパケットの量を制御できます。たとえば、ポート 100 から送信されるパケットのみを取得するようにフィルターを指定できます。フィルターに一致するパケットのみがキャプチャーされ、残りはドロップされます。
複数のフィルタールールを適用できます。
10.1.6.1. Ingress および Egress トラフィックのフィルタリング
Classless Inter-Domain Routing (CIDR) 表記は、ベース IP アドレスとプレフィックス長を組み合わせることにより、IP アドレス範囲を効率的に表すものです。Ingress と Egress トラフィックの両方において、送信元 IP アドレスが、CIDR 表記で設定されたフィルタールールを照合するために最初に使用されます。一致するものがあれば、フィルタリングが続行されます。一致するものがない場合、宛先 IP を使用して、CIDR 表記で設定されたフィルタールールを照合します。
送信元 IP または宛先 IP の CIDR のいずれかを照合した後、peerIP を使用して特定のエンドポイントを特定し、パケットの宛先 IP アドレスを識別できます。定められたアクションに基づいて、フローデータが eBPF フローテーブルにキャッシュされるかされないかが決まります。
10.1.6.2. ダッシュボードとメトリクスの統合
このオプションを有効にすると、eBPF agent statistics の Netobserv/Health ダッシュボードに、Filtered flows rate ビューが表示されるようになります。さらに、Observe → Metrics で、netobserv_agent_filtered_flows_total をクエリーして、FlowFilterAcceptCounter、FlowFilterNoMatchCounter、または FlowFilterRecjectCounter の理由を含むメトリクスを観測できます。
10.1.6.3. フローフィルターの設定パラメーター
フローフィルタールールの設定に必要なパラメーターとオプションパラメーターについては、FlowCollector リソースを参照してください。これには、CIDR 範囲、フィルターアクション、プロトコル、特定のポート設定などが含まれます。
| パラメーター | 説明 |
|---|---|
|
|
eBPF フローのフィルタリング機能を有効にするには、 |
|
|
フローフィルタールールの IP アドレスと CIDR マスクを指定します。IPv4 と IPv6 の両方のアドレス形式をサポートしています。すべての IP と照合する場合、IPv4 の場合は |
|
|
フローフィルタールールに対して実行されるアクションを示します。可能な値は
|
| パラメーター | 説明 |
|---|---|
|
|
フローフィルタールールの方向を定義します。可能な値は |
|
|
フローフィルタールールのプロトコルを定義します。可能な値は、 |
|
|
フローをフィルタリングするための TCP フラグを定義します。可能な値は、 |
|
|
フローのフィルタリングに使用するポートを定義します。送信元ポートまたは宛先ポートのどちらにも使用できます。単一のポートをフィルタリングするには、単一のポートを整数値として設定します。たとえば、 |
|
|
フローのフィルタリングに使用する送信元ポートを定義します。単一のポートをフィルタリングするには、単一のポートを整数値として設定します (例: |
|
|
destPorts は、フローのフィルタリングに使用する宛先ポートを定義します。単一のポートをフィルタリングするには、単一のポートを整数値として設定します (例: |
|
| フローのフィルタリングに使用する ICMP タイプを定義します。 |
|
| フローのフィルタリングに使用する ICMP コードを定義します。 |
|
|
フローのフィルタリングに使用する IP アドレスを定義します (例: |
10.1.7. ユーザー定義ネットワーク
ユーザー定義ネットワーク (UDN) を使用して柔軟なネットワーク分割を行う方法を理解し、Network Observability Operator を活用して、トラフィックフローテーブルの専用ラベルと名前フィルターを通じてこれらのセグメントを監視する方法を学びます。
ユーザー定義ネットワーク (UDN) は、カスタムの Layer 2 および Layer 3 ネットワークセグメントを有効にすることで、Kubernetes Pod ネットワークのデフォルトの Layer 3 トポロジーが持つ柔軟性とセグメンテーション機能を強化するものです。これらのセグメントはすべてデフォルトで分離されています。これらのセグメントは、デフォルトの OVN-Kubernetes CNI プラグインを使用するコンテナー Pod および仮想マシンのプライマリーネットワークまたはセカンダリーネットワークとして機能します。
UDN を使用することで、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。
Network Observability で UDNMapping 機能が有効になっている場合、Traffic フローテーブルに UDN labels 列が表示されます。Source Network Name と Destination Network Name でフィルタリングできます。
10.1.8. OVN-Kubernetes ネットワーキングイベント
OVN-Kubernetes のネットワークイベント追跡機能を使用して、クラスター内のネットワークポリシー、管理ネットワークポリシー、および送信ファイアウォールルールを監視および監査します。
OVN-Kubernetes ネットワークイベントの追跡は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ネットワークイベントの追跡から得られる情報は、次のタスクに役立ちます。
- ネットワークモニタリング: 許可されたトラフィックとブロックされたトラフィックを監視し、ネットワークポリシーと管理ネットワークポリシーに基づきパケットが許可されているか、あるいはブロックされているかを検出します。
- ネットワークセキュリティー: 送信トラフィックを追跡し、Egress ファイアウォールルールに準拠しているか確認できます。許可されていない送信接続を検出し、Egress ルールに違反する送信トラフィックにフラグを立てます。
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.2. Traffic flows ビューからのネットワークトラフィックの観測
トラフィックフロー ビューを使用して、クラスターコンポーネント間のリアルタイムおよび過去のネットワーク通信を監視します。eBPF を介して収集された詳細なフローデータを分析することで、ネットワークトラフィックの監査、ネットワークポリシーの検証、および外部レポートや分析のためのデータのエクスポートが可能になります。
Network Observability Operator の トラフィックフロー ビューは、OpenShift Container Platform クラスター全体のネットワークアクティビティーを、詳細な表形式で表示します。このビューでは、eBPF テクノロジーを活用してフローデータを収集することで、管理者は Pod、サービス、ノード間のリアルタイムおよび過去の通信を監視できます。この可視性は、ネットワークトラフィックの監査、ネットワークポリシーの検証、およびクラスターインフラストラクチャー内の予期しない通信パターンの特定に不可欠です。
トラフィックフロー インターフェイスでは、個々の行を操作することで詳細なフロー情報を取得し、特定の接続の詳細を分析できます。このビューは、表示オプション メニューを通じて高度なカスタマイズをサポートしており、行密度を調整したり、列を管理したりできます。特定の列を選択して並べ替えることで、送信元と宛先のエンドポイント、トラフィック量など、環境にとって最も関連性の高いデータポイントを強調するようにテーブルをカスタマイズできます。
外部分析およびレポート作成を支援するため、トラフィックフロー ビューにはデータエクスポート機能が含まれています。データセット全体をエクスポートすることも、特定のフィールドを選択してネットワークアクティビティーに関するターゲットレポートを作成することもできます。この機能により、ネットワークフローデータに長期的な監査やサードパーティーの監視ツールでの使用が可能になり、OpenShift Container Platform 環境のネットワークの状態を柔軟に文書化および分析できます。
10.2.1. Traffic flows ビューの操作
トラフィックフロー 表を使用して、詳細なネットワークフロー情報を表示および分析します。
管理者は、Traffic flows テーブルに移動して、ネットワークフロー情報を確認できます。
前提条件
- あなたは管理者権限を持っています。
手順
- Observe → Network Traffic に移動します。
- Network Traffic ページで、Traffic flows タブをクリックします。
- 各行をクリックすると、対応するフロー情報が表示されます。
10.2.2. 交通量表示設定
交通流 ビューには、表示密度、データ列、およびデータのエクスポートオプションをカスタマイズするための設定が含まれています。
10.2.2.1. 表示オプション
交通フロー ビューでは、以下の要素が利用可能です。
- 詳細オプションの表示
- 現在のビューをカスタマイズおよびエクスポートするためのメニューを指定します。
- 表示オプションの ドロップダウン
- データテーブルの行サイズを指定します。デフォルト値は Normal です。
- 列の管理
- 交通量 テーブルに表示される列を選択および並べ替えるためのダイアログを指定します。
10.2.3. 交通流データのエクスポート
トラフィックフロー ビューからネットワークフローデータを CSV ファイルにエクスポートし、外部での分析やレポート作成に利用できます。
手順
- Export data をクリックします。
- ウィンドウ内で、すべてのデータをエクスポート チェックボックスを選択するとすべてのデータがエクスポートされ、チェックボックスをオフにするとエクスポートする必要なフィールドのみが選択されます。
- Export をクリックします。
10.2.4. FlowCollector カスタムリソースを使用した IPsec の設定
FlowCollector リソースで IPsec トラッキングを有効にすると、暗号化されたトラフィックを監視し、トラフィックフロービューに IPsec ステータス列を追加して、専用の暗号化ダッシュボードを生成します。
OpenShift Container Platform では、IPsec はデフォルトで無効になっています。「IPsec 暗号化の設定」の手順に従って IPsec を有効にできます。
前提条件
- OpenShift Container Platform で IPsec 暗号化を有効にした。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
IPsec の
FlowCollectorカスタムリソースを設定します。IPsec の
FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - "IPSec"
検証
IPsec が有効な場合:
- IPsec Status という新しい列が Network Observability の Traffic フロービューに表示され、フローが正常に IPsec で暗号化されたかどうか、または暗号化/復号化中にエラーが発生したかどうかが表示されます。
- 生成された暗号化トラフィックの割合を示す新しいダッシュボード。
10.2.5. 会話追跡の使用
FlowCollector カスタムリソースを設定して、Web コンソールで関連するネットワークフローをグループ化および分析するための会話追跡を有効にします。
管理者は、同じ会話の一部であるネットワークフローをグループ化できます。会話は、IP アドレス、ポート、プロトコルによって識別されるピアのグループとして定義され、その結果、一意の Conversation ID が得られます。Web コンソールで対話イベントをクエリーできます。これらのイベントは、Web コンソールでは次のように表示されます。
- Conversation start: このイベントは、接続が開始されているか、TCP フラグがインターセプトされたときに発生します。
-
Conversation tick: このイベントは、接続がアクティブである間、
FlowCollectorspec.processor.conversationHeartbeatIntervalパラメーターで定義された指定間隔ごとに発生します。 -
Conversation end: このイベントは、
FlowCollectorspec.processor.conversationEndTimeoutパラメーターに達するか、TCP フラグがインターセプトされたときに発生します。 - Flow: これは、指定された間隔内に発生するネットワークトラフィックフローです。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
spec.processor.logTypes、conversationEndTimeout、およびconversationHeartbeatIntervalパラメーターが観察のニーズに応じて設定されるように、FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。会話追跡用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: logTypes: Flows advanced: conversationEndTimeout: 10s conversationHeartbeatInterval: 30sここでは、以下のようになります。
spec.processor.logTypes-
エクスポートするイベントの種類を指定します。
フローに設定すると、フローイベントのみがエクスポートされます。すべてに設定すると、会話イベントとフローイベントの両方がエクスポートされ、ネットワークトラフィック ページに表示されます。会話イベントのみに焦点を当てるには、エクスポートする会話として 会話開始、会話ティック、会話終了 イベントを指定します。会話終了 イベントのみをエクスポートするには、EndedConversationsを指定します。ストレージ要件はAllで最も高く、EndedConversationsで最も低くなります。 仕様プロセッサー.高度な会話終了タイムアウト- タイムアウトに達したとき、または TCP フラグが傍受されたときに、会話終了 イベントがトリガーされるまでの時間を指定します。
仕様プロセッサー.高度な会話ハートビート間隔ネットワーク接続がアクティブな間、会話ティック イベントが発生する間隔を指定します。
注記logTypeオプションを更新しても、以前の選択によるフローはコンソールプラグインから消去されません。たとえば、午前 10 時までlogTypeをConversationsに設定し、その後EndedConversationsに移行すると、コンソールプラグインは、午前 10 時まではすべての会話イベントを表示し、午前 10 時以降は終了した会話のみを表示します。
-
Traffic flows タブの Network Traffic ページを更新します。Event/Type と Conversation Id という 2 つの新しい列があることに注意してください。クエリーオプションとして Flow が選択されている場合、すべての Event/Type フィールドは
Flowになります。 - Query Options を選択し、Log Type として Conversation を選択します。Event/Type は、必要なすべての会話イベントを表示するようになりました。
- 次に、特定の会話 ID でフィルタリングするか、サイドパネルから Conversation と Flow ログタイプのオプションを切り替えることができます。
10.2.6. パケットドロップの使用
Network Observability Operator でパケット損失追跡を有効にするには、FlowCollector リソースを設定して、Web コンソールでネットワークデータ損失を監視および視覚化します。
パケットロスは、ネットワークフローデータの 1 つ以上のパケットが宛先に到達できない場合に発生します。パケットのドロップは、次に示す YAML の例の仕様に合わせて FlowCollector を編集することで追跡できます。
この機能を有効にすると、CPU とメモリーの使用量が増加します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
パケットドロップ用に
FlowCollectorカスタムリソースを設定します。以下はその例です。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - PacketDrop privileged: trueここでは、以下のようになります。
spec.agent.ebpf.features-
有効にする機能を指定します。各ネットワークフローにおけるパケット損失の報告を開始するには、
PacketDrop を含めてください。 仕様エージェント ebpf 特権-
特権モードが有効になっているかどうかを指定します。パケット損失追跡を有効にするには、
trueに設定する必要があります。
検証
Network Traffic ページを更新すると、Overview、Traffic Flow、Topology ビューにパケットドロップに関する新しい情報が表示されます。
- Manage panels で、Overview に表示するパケットドロップのグラフィカル表示を新しく選択します。
Manage columns で、Traffic flows テーブルに表示するパケットドロップ情報を選択します。
-
Traffic Flows ビューでは、サイドパネルを展開してパケットドロップの詳細情報を表示することもできます。ホストドロップには
SKB_DROPという接頭辞が付き、OVS ドロップにはOVS_DROPという接頭辞が付きます。
-
Traffic Flows ビューでは、サイドパネルを展開してパケットドロップの詳細情報を表示することもできます。ホストドロップには
- Topology ビューでは、ドロップが発生した場所が赤線で表示されます。
10.2.7. DNS 追跡の使用
FlowCollector カスタムリソースを設定して、Web コンソールでネットワークパフォーマンスの監視、セキュリティー分析、DNS トラブルシューティングを行うための DNS トラッキングを有効にします。
次に示す YAML の例の仕様に合わせて FlowCollector を編集することで、DNS を追跡できます。
この機能を有効にすると、eBPF agent で CPU とメモリーの使用量の増加が観察されます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。DNS 追跡用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - DNSTracking sampling: 1-
spec.agent.ebpf.featuresパラメーターリストを設定すると、Web コンソールで各ネットワークフローの DNS 追跡を有効にできます。 -
より正確なメトリクスと DNS レイテンシー をキャプチャーするために、
sampling値を1に設定できます。sampling値が 1 より大きい場合、DNS レスポンスコード と DNS ID を含むフローを観測できますが、DNS レイテンシー を観測できる可能性は低くなります。
-
Network Traffic ページを更新すると、Overview ビューと Traffic Flow ビューで表示する新しい DNS 表示と適用可能な新しいフィルターが表示されます。
- Manage panels で新しい DNS の選択肢を選択すると、Overview にグラフィカルな表現と DNS メトリクスが表示されます。
- Manage columns で新しい選択肢を選択すると、DNS 列が Traffic Flows ビューに追加されます。
DNS Id、DNS Error、DNS Latency、DNS Response Code などの特定の DNS メトリクスでフィルタリングして、サイドパネルから詳細情報を確認します。DNS Latency 列と DNS Response Code 列がデフォルトで表示されます。
注記TCP ハンドシェイクパケットには DNS ヘッダーがありません。DNS ヘッダーのない TCP プロトコルフローの場合、トラフィックフローデータに表示される DNS Latency、ID、および Response code の値が "n/a" になります。"DNSError" が "0" の Common フィルターを使用すると、フローデータをフィルタリングして、DNS ヘッダーを持つフローのみを表示できます。
10.2.8. RTT トレーシングの使用
Web コンソールを使用して FlowCollector カスタムリソースを設定し、ラウンドトリップタイム (RTT) トレースを有効にして、クラスター全体のネットワーク遅延を監視および分析します。
次に示す YAML の例の仕様に合わせて FlowCollector を編集することで、RTT を追跡できます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
RTT トレーシング用に
FlowCollectorカスタムリソースを設定します。次に例を示します。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - FlowRTTここでは、以下のようになります。
spec.agent.ebpf.features-
有効にする eBPF 機能のリストを指定します。往復時間 (RTT) ネットワークフローのトレースを開始するには、このリストに
FlowRTT を追加してください。
検証
ネットワークトラフィック ページを更新すると、概要、トラフィックフロー、トポロジーの 各ビューに RTT 情報が表示されます。
- 概要 ビューで、パネルの管理 をクリックして、表示する RTT のグラフィカル表示を選択します。
- トラフィックフロー テーブルで、フロー RTT 列がデフォルトで表示されていることを確認してください。列を管理するには、Manage columns をクリックします。
トラフィックフロー ビューで、サイドパネルを展開して RTT メタデータを表示します。
-
フィルター検索バーに
protocol=TCPと入力して、TCP プロトコルのフローデータをフィルタリングします。 -
すべての TCP フィルタリングされたフローの FlowRTT 値が
0より大きいことを確認してください。 -
フィルター検索バーに
time_flow_rtt>=10000000と入力して、FlowRTT の値が10,000,000ナノ秒 (10 ms) より大きいものをフィルタリングします。 - フィルターを取り外してください。
-
フィルター検索バーに
- トポロジー ビューで、表示 オプションのドロップダウンメニューをクリックします。Edge ラベルの リストで、RTT を選択します。
10.2.9. eBPF Manager Operator の操作
eBPF Manager Operator をネットワークオブザーバビリティーと統合することで、eBPF プログラムを管理し、特権エージェント権限の必要性を低減します。
eBPF Manager Operator は、すべての eBPF プログラムを管理することで、攻撃対象領域を削減し、コンプライアンス、セキュリティー、競合防止を実現します。Network Observability は、eBPF Manager Operator を使用してフックをロードできます。そのため、特権モードや、CAP_BPF や CAP_PERFMON などの追加の Linux ケイパビリティーを eBPF エージェントに提供する必要がなくなります。eBPF Manager Operator と Network Observability の連携は、64 ビット AMD アーキテクチャーでのみサポートされています。
eBPF Manager Operator と Network Observability の連携は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
- Web コンソールで、Ecosystem → Operator Hub に移動します。
- eBPF Manager をインストールします。
-
bpfmannamespace の Workloads → Pod をチェックして、すべてが稼働していることを確認します。 eBPF Manager Operator を使用するように
FlowCollectorカスタムリソースを設定します。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: features: - EbpfManager
検証
- Web コンソールで、Ecosystem → Installed Operators に移動します。
eBPF Manager Operator → All instances タブをクリックします。
各ノードについて、
netobservという名前のBpfApplicationと、BpfProgramオブジェクトのペア (Traffic Control (TCx) Ingress 用と TCx Egress 用のもの) が存在することを確認します。他の eBPF エージェント機能を有効にすると、オブジェクトが増える可能性があります。
10.2.10. ヒストグラムの使用
ヒストグラムは、ネットワークフローログを視覚的に表示するもので、トラフィック量の傾向を分析したり、特定の時間間隔でフローデータをフィルタリングしたりするために使用できます。
Show histogram をクリックすると、フローの履歴を棒グラフとして視覚化するためのツールバービューが表示されます。ヒストグラムは、時間の経過に伴うログの数を示します。ヒストグラムの一部を選択して、ツールバーに続く表でネットワークフローデータをフィルタリングできます。
10.2.11. アベイラビリティーゾーンの使用
FlowCollector カスタムリソースを設定してアベイラビリティーゾーンデータを収集することで、Web コンソールで異なるクラスターゾーン間のネットワークトラフィックの視覚化と分析が可能になります。
クラスターのアベイラビリティーゾーンに関する情報を収集するように FlowCollector を設定できます。この設定により、ノードに適用される topology.kubernetes.io/zone ラベル値を使用してネットワークフローデータをエンリッチできます。
手順
- Web コンソールで、Ecosystem → Installed Operator に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定し、spec.processor.addZoneパラメーターをtrueに設定します。設定例は次のとおりです。アベイラビリティーゾーン収集用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: # ... processor: addZone: true # ...
検証
Network Traffic ページを更新すると、Overview、Traffic Flow、Topology ビューにアベイラビリティーゾーンに関する新しい情報が表示されます。
- Overview タブに、使用可能な Scope として Zones が表示されます。
- Network Traffic → Traffic flows の SrcK8S_Zone フィールドと DstK8S_Zone フィールドに Zones が表示されます。
- Topology ビューで、Scope または Group として Zones を設定できます。
10.2.12. 複数のルールを使用した eBPF フローデータのフィルタリング
FlowCollector カスタムリソースで複数のフィルタリングルールを設定することで、IP アドレスやパケットの状態に基づいて特定の eBPF フローを受け入れるか拒否するかを決定し、ネットワークトラフィックデータの収集を絞り込むことができます。
- フィルタールールでは重複する Classless Inter-Domain Routing (CIDR) を使用することはできません。
- IP アドレスが複数のフィルタールールにマッチする場合、最も具体的な CIDR 接頭辞 (最も長い接頭辞) を持つルールが優先されます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
-
FlowCollectorカスタムリソースを設定します。
10.2.13. eBPF フローデータフィルタリングの例
これらの FlowCollector カスタムリソースの例を使用して、複数のルールを用いて eBPF フローをフィルタリングし、eBPF フローテーブルにキャッシュされたパケットの流れを制御します。
10.2.13.1. すべての North-South トラフィックと 1:50 の East-West トラフィックをサンプリングする YAML の例
デフォルトでは、他のすべてのフローが拒否されます。
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
agent:
type: eBPF
ebpf:
flowFilter:
enable: true
rules:
- action: Accept
cidr: 0.0.0.0/0
sampling: 1
- action: Accept
cidr: 10.128.0.0/14
peerCIDR: 10.128.0.0/14
- action: Accept
cidr: 172.30.0.0/16
peerCIDR: 10.128.0.0/14
sampling: 50- 1
spec.agent.ebpf.flowFilter.enableをtrueに設定することで、eBPFフローフィルタリングを有効にします。- 2
- フローフィルタールールのアクションを定義します。有効な値は
AcceptまたはRejectです。 - 3
- フローフィルタールールの IP アドレスと
CIDRマスクを定義します。このパラメーターは、IPv4とIPv6 の両方のアドレス形式をサポートしています。任意の IP アドレスに一致させるには、IPv4の場合は0.0.0.0/0、IPv6の場合は::/0を使用してください。 - 4
- 一致するフローのサンプリング間隔を定義し、グローバルサンプリング設定 (
spec.agent.ebpf.sampling) を上書きします。 - 5
- ピア IP
CIDRでフローをフィルタリングします。
10.2.13.2. パケットドロップでフローをフィルタリングする YAML の例
デフォルトでは、他のすべてのフローが拒否されます。
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
agent:
type: eBPF
ebpf:
privileged: true
features:
- PacketDrop
flowFilter:
enable: true
rules:
- action: Accept
cidr: 172.30.0.0/16
pktDrops: true - 1
spec.agent.ebpf.privileged をtrueに設定することで、パケットドロップのレポートを有効にします。- 2
- 各ネットワークフローのパケットドロップを報告するには、
PacketDrop の値をspec.agent.ebpf.featuresリストに追加します。 - 3
spec.agent.ebpf.flowFilter.enableをtrueに設定することで、eBPFフローフィルタリングを有効にします。- 4
- フローフィルタールールのアクションを定義します。有効な値は
AcceptまたはRejectです。 - 5
pktDrops をtrueに設定することで、ドロップを含むフローをフィルタリングします。
10.2.14. エンドポイント変換 (xlat)
エンドポイント変換 (xlat) は、eBPF を使用してネットワークフローログを変換済みの Pod レベルのメタデータで強化し、サービスやロードバランサーの背後でトラフィックを処理する特定のバックエンド Pod を可視化します。
Network Observability と拡張 Berkeley Packet Filter (eBPF) を使用して、統合ビューでトラフィックを処理するエンドポイントを可視化できます。通常、トラフィックがサービス、egressIP、またはロードバランサーを通過する場合、トラフィックフロー情報は、利用可能な Pod の 1 つにルーティングされるときに抽象化されます。トラフィックに関する情報を取得しようとすると、サービス IP やポートなどのサービス関連情報のみが表示され、リクエストを処理している特定の Pod に関する情報は表示されません。多くの場合、サービストラフィックと仮想サービスエンドポイントの両方の情報が 2 つの別々のフローとしてキャプチャーされるため、トラブルシューティングが複雑になります。
この問題の解決において、エンドポイント xlat は次のように役立ちます。
- カーネルレベルでネットワークフローをキャプチャーします。この場合のパフォーマンスへの影響は、最小限に抑えられます。
- 変換されたエンドポイント情報を使用してネットワークフローを拡充し、サービスだけでなく特定のバックエンド Pod も表示することで、どの Pod がリクエストを処理したか確認できます。
ネットワークパケットが処理されると、eBPF フックは、変換されたエンドポイントに関するメタデータでフローログをエンリッチします。これには、Network Traffic ページに 1 行で表示できる次の情報が含まれます。
- ソース Pod IP
- 送信元ポート
- 宛先 Pod IP
- 宛先ポート
- Conntrack Zone ID
10.2.15. エンドポイント変換 (xlat) の操作
FlowCollector リソースでエンドポイント変換 (xlat) を有効にすると、ネットワークフローに翻訳済みのパケット情報を追加できます。この情報を使用すると、専用の xlat 列を通じて、サービストラフィックを処理する特定の Pod とオブジェクトを特定できます。
Network Observability と eBPF を使用すると、Kubernetes サービスからのネットワークフローを変換されたエンドポイント情報でエンリッチして、トラフィックを処理するエンドポイントに関する詳細情報を得ることができます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
PacketTranslationのFlowCollectorカスタムリソースを、設定します。以下はその例です。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - PacketTranslation-
spec.agent.ebpf.features仕様リストにPacketTranslationパラメーターをリストすることで、変換されたパケット情報を使用してネットワークフローを充実させることができます。
-
翻訳されたパケットに関する情報をフィルタリングするには、ネットワークトラフィック ページを更新してください。
- Destination kind: Service に基づき、ネットワークフローデータをフィルタリングします。
変換された情報が表示される場所を区別する xlat 列と、次のデフォルト列が表示されます。
- Xlat Zone ID
- Xlat Src Kubernetes Object
- Xlat Dst Kubernetes Object
- 追加の xlat 列の表示は、Manage columns で管理できます。
10.2.16. ユーザー定義ネットワークの操作
FlowCollector カスタムリソースを設定して、ユーザー定義ネットワーク (UDN) マッピングを有効にし、Web コンソール内でカスタムネットワークインターフェイスを介したトラフィックを可視化します。
Network Observability リソースでユーザー定義ネットワーク (UDN) を有効にできます。次の例は、FlowCollector リソースの設定を示しています。
前提条件
- Red Hat OpenShift Networking で UDN を設定した。詳細は、「CLI を使用した UserDefinedNetwork の作成」または「Web コンソールを使用した UserDefinedNetwork の作成」を参照してください。
手順
次のコマンドを実行して、Network Observability の
FlowCollectorリソースを編集します。$ oc edit flowcollectorFlowCollectorリソースのebpfセクションを設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: sampling: 1 privileged: true features: - UDNMappingここでは、以下のようになります。
仕様エージェント ebpf サンプリング-
ネットワークイベントのサンプリングレートを指定します。すべてのネットワークイベントをキャプチャーするには、値を
1に設定してください。サンプリング1ではリソースが多すぎる場合、サンプリングをニーズに合わせてより適切な値に設定します。 仕様エージェント ebpf 特権-
特権モードが有効になっているかどうかを指定します。ユーザー定義のネットワークマッピングを行うには、
trueに設定する必要があります。
検証
Network Traffic ページを更新して、Traffic Flow と Topology ビューで更新された UDN の情報を表示します。
-
Network Traffic > Traffic flows では、
SrcK8S_NetworkNameフィールドとDstK8S_NetworkNameフィールドで UDN を確認できます。 - Topology ビューでは、Network を Scope または Group に設定できます。
-
Network Traffic > Traffic flows では、
10.2.17. ネットワークイベントの表示
FlowCollector カスタムリソースを設定して、ネットワークイベントトラッキングを有効にし、セキュリティーポリシー、ファイアウォール、および分離ルールが Web コンソールのトラフィックフローにどのように影響するかを監査できるようにします。
OVN-Kubernetes ネットワークイベントの追跡は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
FlowCollector を編集して、次のリソースによってドロップまたは許可されたネットワークフローなどのネットワークトラフィックイベントに関する情報を表示できます。
-
NetworkPolicy -
AdminNetworkPolicy -
BaselineNetworkPolicy -
EgressFirewall -
UserDefinedNetwork分離 - マルチキャスト ACL
前提条件
-
clusterという名前のFeatureGateカスタムリソース (CR) でTechPreviewNoUpgrade機能セットを設定することで、OVNObservabilityを有効にした。詳細は、「CLI を使用した機能セットの有効化」および「CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認する」を参照してください。 -
NetworkPolicy、AdminNetworkPolicy、BaselineNetworkPolicy、UserDefinedNetworkの分離、マルチキャスト、またはEgressFirewallのいずれかのネットワーク API を 1 つ以上作成した。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
NetworkEventsの表示を有効にするには、FlowCollectorCR を設定します。例:FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: type: eBPF ebpf: # sampling: 1 privileged: true features: - "NetworkEvents"ここでは、以下のようになります。
仕様エージェント ebpf サンプリング-
ネットワークイベントのサンプリングレートを指定します。すべてのネットワークイベントをキャプチャーするには、値を
1に設定してください。サンプリング1 がリソースを過剰に消費する場合は、ニーズに合ったより適切なサンプリング値に設定してください。この値はオプションです。 仕様エージェント ebpf 特権-
eBPF エージェントを特権モードで実行するかどうかを指定します。OVN オブザーバビリティーライブラリーはローカルの Open vSwitch (OVS) ソケットおよび Open Virtual Network (OVN) データベースにアクセスする必要があるため、
trueに設定されています。
検証
- Network Traffic ビューに移動し、Traffic flows テーブルを選択します。
Network Events という新しい列が表示されます。ここでは、有効にしたネットワーク API (
NetworkPolicy、AdminNetworkPolicy、BaselineNetworkPolicy、UserDefinedNetworkの分離、マルチキャスト、Egress ファイアウォール) のいずれかがもたらす影響に関する情報を表示できます。この列で確認できるイベントの kind の例は次のとおりです。
Network Events の出力例
<Dropped_or_Allowed> by <network_event_and_event_name>, direction <Ingress_or_Egress>
10.3. トポロジービューからのネットワークトラフィックの観察
ネットワークトラフィック ページの トポロジー ビューでは、OpenShift Container Platform クラスター全体のネットワークフローとトラフィック量をグラフィカルに表示します。管理者として、このビューを使用してアプリケーションのトラフィックデータを監視したり、さまざまなネットワークコンポーネント間の関係を視覚化したりできます。
この可視化では、ネットワーク上の実体をノードとして、トラフィックの流れをエッジとして表現しています。グラフ内の個々のコンポーネントを選択すると、そのリソースに関する特定のメトリクスと健全性の詳細を含むサイドパネルにアクセスできます。このインタラクティブなアプローチにより、クラスター内のトラフィックパターンや接続の問題を迅速に特定することが可能になります。
複雑な環境を管理するために、トポロジー ビューには、レイアウトとデータ密度をカスタマイズできる高度な設定オプションが含まれています。ビューの 範囲を 調整したり、リソースの所有権を表す グループを 適用したり、さまざまな レイアウト アルゴリズムを選択してグラフィック表示を最適化したりできます。さらに、エッジラベルを 有効にすることで、平均バイトレートなどのリアルタイムの測定値をフローライン上に直接表示できます。
レポート作成や外部分析のために、トポロジー ビューにはエクスポート機能が備わっています。現在のグラフィック表示を PNG イメージとしてダウンロードするか、特定のビュー設定への直接リンクを生成して他の管理者と共有することができます。これらのツールは、ネットワークに関する知見へのアクセスを容易にし、かつ容易に文書化することを保証します。
10.3.1. トポロジービューの操作
トポロジー ビューにアクセスすると、クラスターネットワークの関係を視覚的に確認でき、個々のコンポーネントを選択して詳細なトラフィックメトリクスとメタデータを表示できます。
管理者は、Topology ビューに移動して、コンポーネントの詳細とメトリクスを確認できます。
前提条件
- あなたは管理者権限を持っています。
手順
- Observe → Network Traffic に移動します。
- Network Traffic ページで、Topology タブをクリックします。
- トポロジー タブで各コンポーネントをクリックすると、その詳細とメトリクスが表示されます。
10.3.2. トポロジービューの詳細オプションの設定
トポロジー ビューで利用可能な詳細オプションを確認して、表示設定のカスタマイズ、コンポーネントのグループ化とレイアウトの設定、ネットワークグラフのイメージとしてのエクスポートを行ってください。
Show advanced options を使用して、ビューをカスタマイズおよびエクスポートできます。詳細オプションビューには、次の機能があります。
- Find in view で必要なコンポーネントを検索します。
Display options: 次のオプションを設定するには:
- Edge labels: 指定した測定値をエッジラベルとして表示します。デフォルトでは、Average rate が Bytes 単位で表示されます。
- Scope: ネットワークトラフィックが流れるコンポーネントのスコープを選択します。デフォルト値は Namespace です。
- Groups: コンポーネントをグループ化することにより、所有権をわかりやすくします。デフォルト値は None です。
- Layout: グラフィック表示のレイアウトを選択します。デフォルト値は ColaNoForce です。
- 表示: 表示する必要がある詳細を選択します。デフォルトでは、すべてのオプションがチェックされています。使用可能なオプションは、Edges、Edges label、および Badges です。
- Truncate labels: ドロップダウンリストから必要なラベルの幅を選択します。デフォルト値は M です。
- グループを Collapse groups を展開または折りたたみます。グループはデフォルトで展開されています。Groups の値が None の場合、このオプションは無効になります。
10.3.2.1. トポロジービューのエクスポート
ビューをエクスポートするには、Export topology view をクリックします。ビューは PNG 形式でダウンロードされます。
10.4. ネットワークトラフィックのフィルタリング
ネットワークトラフィック ビューで利用可能なクエリーオプションとフィルタリングパラメーターを確認し、データ検索の最適化、特定のログタイプの分析、および方向性トラフィックの可視性の管理を行ってください。
デフォルトでは、ネットワークトラフィック ページには、FlowCollector インスタンスで設定されたデフォルトフィルターに基づいて、クラスター内のトラフィックフローデータが表示されます。フィルターオプションを使用して、プリセットフィルターを変更することにより、必要なデータを観察できます。
または、Namespaces、Services、Routes、Nodes、および Workloads ページの Network Traffic タブでトラフィックフローデータにアクセスして、対応する集約のフィルタリングされたデータを提供します。
- クエリーオプション
以下に示すように、Query Options を使用して検索結果を最適化できます。
- Log Type: 利用可能なオプション Conversation と Flows では、フローログ、新しい会話、完了した会話、および長い会話の更新を含む定期的なレコードであるハートビートなどのログタイプ別にフローをクエリーする機能が提供されます。会話は、同じピア間のフローの集合体です。
- Match filters: 高度なフィルターで選択されたさまざまなフィルターパラメーター間の関係を決定できます。利用可能なオプションは、Match all と Match any です。Match all はすべての値に一致する結果を提供し、Match any は入力された値のいずれかに一致する結果を提供します。デフォルト値は Match all です。
- Datasource: クエリーに使用するデータソース (Loki、Prometheus、Auto) を選択できます。Loki ではなく Prometheus をデータソースとして使用すると、パフォーマンスが大幅に向上します。ただし、Prometheus がサポートするフィルターと集計は限られています。デフォルトのデータソースは Auto です。Auto の場合、Prometheus をサポートしているクエリーでは Prometheus を使用し、サポートしていないクエリーでは Loki を使用します。
Drops filter: 次のクエリーオプションを使用して、各レベルのドロップパケットを表示できます。
- Fully dropped の場合、パケットが完全にドロップされたフローレコードが表示されます。
- Containing drops の場合、ドロップが発生したが送信可能なフローレコードが表示されます。
- Without drops の場合、送信されたパケットを含むレコードが表示されます。
- All の場合、上記のレコードがすべて表示されます。
- Limit: 内部バックエンドクエリーのデータ制限。マッチングやフィルターの設定に応じて、トラフィックフローデータの数が指定した制限内で表示されます。
- クイックフィルター
-
Quick filters ドロップダウンメニューのデフォルト値は、
FlowCollector設定で定義されます。コンソールからオプションを変更できます。 - 高度なフィルター
- ドロップダウンリストからフィルタリングするパラメーターを選択することで、詳細フィルター (Common、Source、Destination) を設定できます。フローデータは選択に基づいてフィルタリングされます。適用されたフィルターを有効または無効にするには、フィルターオプションの下にリストされている適用されたフィルターをクリックします。
一方向フィルタリング と
往復 フィルタリングを切り替えることができます。
一方向 フィルターは、フィルターの選択に基づいて、送信元 と 宛先の トラフィックのみを表示します。Swap を使用すると、Source および Destination トラフィックの方向ビューを変更できます。
往復 フィルターには、送信元フィルター と 宛先 フィルターによる戻りトラフィックが含まれます。ネットワークトラフィックの方向性があるフローは、Traffic flows テーブルの Direction 列に、ノード間トラフィックの場合は Ingress`or `Egress として、シングルノード内のトラフィックの場合は `Inner` として表示されます。
Reset defaults をクリックすると、既存のフィルターが削除され、FlowCollector 設定で定義されたフィルターが適用されます。
テキスト値の指定規則を理解するには、Learn More をクリックしてください。
第11章 ネットワークオブザーバビリティーに関する健全性ルール
Network Observability Operator は、組み込みのメトリクスと OpenShift Container Platform モニタリングスタックを使用して、クラスターネットワークの状態を報告するアラートを提供します。
ネットワークオブザーバビリティーに関するヘルスアラート機能を利用するには、OpenShift Container Platform 4.16 以降が必要です。
11.1. ネットワークの健全性とパフォーマンスに関するオブザーバビリティールール
ネットワークのオブザーバビリティーには、Prometheus ベースのルールを管理するシステムが含まれています。これらのルールを使用して、OpenShift Container Platform のアプリケーションとインフラストラクチャーの健全性とパフォーマンスを監視します。
Network Observability Operator は、これらのルールを PrometheusRule リソースに変換します。Network Observability Operator は、以下のルールタイプをサポートしています。
-
アラートルール: ネットワーク異常やインフラストラクチャー障害の通知を行うために、Prometheus
AlertManagerによって管理されるルールを指定します。 - 記録ルール: ダッシュボードのパフォーマンスと視覚化を向上させるために、複雑な Prometheus Query Language (PromQL) 式を新しい時系列に事前に計算することを指定します。
以下のコマンドを実行して、netobserv 名前空間内の PrometheusRule リソースを表示します。
$ oc get prometheusrules -n netobserv -o yaml11.1.1. ネットワークの状態監視およびアラートに関するルール
Network Observability Operator には、ネットワークの異常やインフラストラクチャーの障害を検出するためのルールベースのシステムが含まれています。Operator は、設定をアラートルールに変換することで、OpenShift Container Platform の Web コンソールを介した自動監視とトラブルシューティングを可能にします。
11.1.1.1. 結果のモニタリング
Network Observability Operator は、以下の領域におけるネットワークの状態を表示します。
- アラート UI
-
特定のアラートは 監視 → アラート に表示され、そこで通知は Prometheus
AlertManagerを通じて管理されます。 - ネットワークヘルス ダッシュボード
- 監視 → ネットワーク状態 にある専用ダッシュボードでは、クラスターネットワークの状態に関する概要を高いレベルで確認できます。
ネットワーク健全性 ダッシュボードは、違反をタブに分類することで、問題の範囲を絞り込むことができます。
- グローバル: クラスター全体の総合的な健全性。
- ノード: インフラストラクチャーノードに特有の違反。
- 名前空間: 個々の名前空間に固有の違反。
-
ワークロード:
デプロイメントやデーモンセットなどのリソースに固有の違反。
11.1.1.2. 事前定義された健康ルール
Network Observability Operator は、一般的なネットワークシナリオに対するデフォルトルールを提供します。これらのルールは、FlowCollector カスタムリソース (CR) で対応する機能が有効になっている場合にのみ有効になります。
以下のリストには、利用可能なデフォルトルールの一部が含まれています。
PacketDropsByDevice-
ネットワーク機器からのパケット損失率が高い場合にトリガーされます。これは標準的なノードエクスポーターのメトリクスに基づいており、
PacketDropエージェント機能は必要ありません。 PacketDropsByKernel-
カーネルによるパケット損失率が高い場合にトリガーされます。
PacketDropエージェント機能が必要です。 IPsecErrors-
IPsec 暗号化エラーが検出された場合にトリガーされます。
IPSecエージェント機能が必要です。 NetpolDenied-
ネットワークポリシーによって拒否されたトラフィックが検出された場合にトリガーされます。
NetworkEventsエージェント機能が必要です。 LatencyHighTrend-
TCP 遅延の大幅な増加が検出された場合にトリガーされます。
FlowRTTエージェント機能が必要です。 DNSErrors-
DNS エラーが検出された際にトリガーされます。
DNS トラッキングエージェント機能が必要です。
Network Observability Operator 向けの運用アラート:
NetObservNoFlows- パイプラインがアクティブであるにもかかわらず、フローが観測されない場合にトリガーされます。
NetObservLokiError- Loki のエラーが原因でフローがドロップされた場合にトリガーされます。
ルールとランブックの完全なリストについては、Network Observability Operator のランブックを 参照してください。
11.1.1.3. ルールの依存関係と機能要件
Network Observability Operator は、FlowCollector カスタムリソース (CR) で有効になっている機能に基づいてルールを作成します。
たとえば、パケットドロップ関連のルールは、PacketDrop エージェント機能が有効になっている場合にのみ作成されます。ルールはメトリクスに基づいて構築されます。必要なメトリクスが不足している場合、設定に関する警告が表示される可能性があります。FlowCollector リソースの spec.processor.metrics.includeList オブジェクトでメトリクスを設定します。
11.2. 記録ルールによるパフォーマンス最適化
大規模クラスターの場合、記録ルールによって Prometheus がネットワークデータを処理する方法が最適化されます。記録ルールを設定することで、ダッシュボードの応答性が向上し、複雑なクエリーの計算負荷が軽減されます。
11.2.1. 最適化のメリット
記録ルールは、複雑な Prometheus Query Language (PromQL) 式を事前に計算し、その結果を新しい時系列データとして保存します。アラートルールとは異なり、記録ルールはしきい値を監視しません。
記録ルールを使用することには、次のような利点があります。
- パフォーマンスの向上
- Prometheus クエリーを事前に計算することで、長期的な傾向に関するオンデマンド計算を回避し、ダッシュボードの読み込み速度を向上させることができます。
- リソース効率
- 一定間隔でデータを計算すると、ダッシュボードの更新ごとにデータを再計算する場合と比較して、Prometheus サーバーの CPU 負荷が軽減されます。
- 簡略化されたクエリー
-
cluster:network_traffic:rate_5mのような短いメトリクス名を使用すると、カスタムダッシュボードでの複雑な集計計算が簡素化されます。
11.2.2. ルールモードの比較
以下の表は、期待される結果に基づいてルールモードを比較したものです。
| 説明 | アラートルール | 記録ルール |
|---|---|---|
| 目的 | 問題通知。 | 高レベルメトリクスの履歴を保存します。 |
| データ結果 | 警告状態を生成します。 | 永続的なメトリクスを作成します。 |
| 制約 | アラート UI と ネットワーク状態 ビュー。 | メトリクスエクスプローラー と ネットワーク健全性 ビュー。 |
| 通知 |
| 通知は発生しません。 |
11.3. ネットワークオブザーバビリティー健全性ルール構造とカスタマイズ
Network Observability Operator のヘルスルールは、FlowCollector カスタムリソース (CR) の spec.processor.metrics.healthRules オブジェクト内のルールテンプレートとバリアントを使用して定義されます。デフォルトのテンプレートとバリアントをカスタマイズして、柔軟できめ細かなアラートを作成できます。
テンプレートごとに、それぞれ固有のしきい値とグループ化設定を持つバリアントのリストを定義できます。詳細は、デフォルトのアラートテンプレートリストを参照してください。
次の例はアラートを示しています。
apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
name: flow-collector
spec:
processor:
metrics:
healthRules:
- template: PacketDropsByKernel
mode: Alert # or Recording
variants:
# triggered when the whole cluster traffic (no grouping) reaches 10% of drops
- thresholds:
critical: "10"
# triggered when per-node traffic reaches 5% of drops, with gradual severity
- thresholds:
critical: "15"
warning: "10"
info: "5"
groupBy: Nodeここでは、以下のようになります。
spec.processor.metrics.healthRules.template- 定義済みのルールテンプレートの名前を指定します。
spec.processor.metrics.healthRules.mode-
ルールが
アラートルールとして機能するか、記録ルールとして機能するかを指定します。この設定は、バリアントごとに定義することも、テンプレート全体に対して定義することもできます。 spec.processor.metrics.healthRules.variants.thresholds-
ルールをトリガーする数値を指定します。1 つのバリアント内で、重大度レベル (
クリティカル、警告、情報など) を複数定義できます。 クラスター全体にわたる変異-
groupBy設定なしで定義されたバリアントを指定します。提供された例では、このバリアントはクラスター全体のトラフィックが 10% 減少したときにトリガーされます。 spec.processor.metrics.healthRules.variants.groupBy- メトリクスを集計するために使用するディメンションを指定します。提供された例では、アラートは各 *Node8 ごとに個別に評価されます。
ルールをカスタマイズすると、そのテンプレートのデフォルト設定が置き換えられます。デフォルト設定を維持する場合は、手動で複製する必要があります。
11.3.1. ヘルスルールの PromQL 式とメタデータ
Prometheus Query Language (PromQL) のベースクエリーと、それをカスタマイズして特定のニーズに合わせて Network Observability アラートを設定する方法を説明します。
ネットワークオブザーバビリティー フローコレクター カスタムリソース (CR) のヘルスルール API は、Prometheus Operator API にマッピングされ、PrometheusRule を生成します。次のコマンドを実行すると、デフォルトの netobserv namespace 内の PrometheusRule を確認できます。
$ oc get prometheusrules -n netobserv -oyaml11.3.1.1. 受信トラフィックの急増に関するアラートのクエリー例
この例では、受信トラフィックの急増に関するアラートの PromQL ベースクエリーパターンを示します。
sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace)
このクエリーは、過去 30 分間に openshift-ingress namespace からいずれかのワークロードの namespace に送信されたバイトレートを計算します。
このクエリーをカスタマイズして、一部のレートのみを保持したり、特定の期間にクエリーを実行したり、最終的なしきい値を設定したりできます。
- ノイズのフィルタリング
このクエリーに
> 1000を追加すると、1 KB/sを超える観測レートのみが保持され、通信量が少ないコンシューマーからのノイズが除去されます。(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)バイトレートは、
FlowCollectorカスタムリソース (CR) 設定で定義されたサンプリング間隔と相対的な関係にあります。サンプリング間隔が1:100の場合、実際のトラフィックは報告されたメトリクスの約 100 倍であると考えられます。- 期間の比較
offset修飾子を使用すると、特定の期間に同じクエリーを実行できます。たとえば、offset 1d使用すると 1 日前にクエリーを実行でき、offset 5hを使用すると 5 時間前にクエリーを実行できます。sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))100 * (<query now> - <query from the previous day>) / <query from the previous day>という数式を使用すると、前日と比較した増加率を計算できます。今日のバイトレートが前日よりも低い場合、この値は負になることがあります。- 最終的なしきい値
-
最終的なしきい値を適用すると、目的のパーセンテージに満たない増加分を除外できます。たとえば、
> 100は 100% 未満の増加分を除外します。
まとめると、PrometheusRule の完全な式は次のようになります。
...
expr: |-
(100 *
(
(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
- sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
)
/ sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
> 10011.3.1.2. アラートのメタデータフィールド
Network Observability Operator は、モニタリングスタックなど、他の OpenShift Container Platform 機能のコンポーネントを使用して、ネットワークトラフィックの可視性を強化します。詳細は、「モニタリングスタックアーキテクチャー」を参照してください。
ルール定義には、いくつかのメタデータを設定する必要があります。このメタデータは、モニタリングスタックの Prometheus および Alertmanager サービス、または Network Health ダッシュボードによって使用されます。
次の例は、メタデータが設定された AlertingRule リソースを示しています。
apiVersion: monitoring.openshift.io/v1
kind: AlertingRule
metadata:
name: netobserv-alerts
namespace: openshift-monitoring
spec:
groups:
- name: NetObservAlerts
rules:
- alert: NetObservIncomingBandwidth
annotations:
netobserv_io_network_health: '{"namespaceLabels":["DstK8S_Namespace"],"threshold":"100","unit":"%","upperBound":"500"}'
message: |-
NetObserv is detecting a surge of incoming traffic: current traffic to {{ $labels.DstK8S_Namespace }} has increased by more than 100% since yesterday.
summary: "Surge in incoming traffic"
expr: |-
(100 *
(
(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
- sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
)
/ sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
> 100
for: 1m
labels:
app: netobserv
netobserv: "true"
severity: warningここでは、以下のようになります。
spec.groups.rules.alert.labels.netobserv-
trueに設定すると、このアラートが、Network Health ダッシュボードによって検出されるべきアラートとして指定されます。 spec.groups.rules.alert.labels.severity-
アラートの重大度を指定します。有効な値は、
critical、warning、またはinfoです。
message アノテーションで定義されている PromQL 式からの出力ラベルを活用できます。この例では、結果が DstK8S_Namespace ごとにグループ化されるため、メッセージテキストで {{ $labels.DstK8S_Namespace }} という式が使用されています。
netobserv_io_network_health アノテーションは任意であり、Network Health ページでアラートをどのようにレンダリングするかを制御します。
netobserv_io_network_health アノテーションは、次のフィールドで構成される JSON 文字列です。
| フィールド | 型 | 説明 |
|---|---|---|
|
| 文字列のリスト | namespace を保持する 1 つ以上のラベル。指定すると、アラートが Namespaces タブに表示されます。 |
|
| 文字列のリスト | ノード名を保持する 1 つ以上のラベル。指定すると、アラートが Nodes タブに表示されます。 |
|
| 文字列のリスト |
所有者名やワークロード名などを格納するラベルが 1 つ以上あります。 |
|
| 文字列のリスト |
所有者/ワークロードの種類を保持する 1 つ以上のラベル。 |
|
| 文字列 |
アラートしきい値。 |
|
| 文字列 | 表示目的でのみ使用されるデータ単位。 |
|
| 文字列 | 閉じた尺度でスコアを計算するために使用される上限値。この上限を超えるメトリクス値は丸められます。 |
|
| オブジェクトのリスト |
アラートに応じて表示されるリンクのリスト。各リンクには、 |
|
| 文字列 |
URL 構築のための、ネットワークトラフィック ページへのリンクに関する情報。 |
namespaceLabels と nodeLabels は相互に排他的です。どちらも指定されていない場合は、Global タブにアラートが表示されます。
| フィールド | 説明 |
|---|---|
|
| 追加で挿入するフィルター (たとえば、DNS 関連のアラートの場合は DNS 応答コード)。 |
|
|
フィルターにリターントラフィックを含めるかどうか ( |
|
|
フィルターがトラフィックの送信元ではなく宛先を対象とするかどうか ( |
11.3.2. カスタムヘルスルールの設定
Prometheus Query Language (PromQL) を使用して、特定のネットワークメトリクス (トラフィックの急増など) に基づいてアラートをトリガーするカスタム AlertingRule リソースを定義します。
前提条件
-
PromQLに関する知識。 - OpenShift Container Platform 4.16 以降がインストールされている必要があります。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - Network Observability Operator がインストールされている。
手順
-
AlertingRuleリソースを含む、custom-alert.yamlという名前の YAML ファイルを作成します。 次のコマンドを実行して、カスタムアラートルールを適用します。
$ oc apply -f custom-alert.yaml
検証
次のコマンドを実行して、
PrometheusRuleリソースがnetobservnamespace に作成されたことを確認します。$ oc get prometheusrules -n netobserv -oyaml出力に、作成した
netobserv-alertsルールが含まれているはずです。これにより、リソースが正しく生成されたことを確認できます。- OpenShift Container Platform Web コンソールの Network Health ダッシュボード → Observe をチェックして、ルールがアクティブであることを確認します。
11.4. 定義済みルールを無効にする
ルールテンプレートは、FlowCollector カスタムリソース (CR) の spec.processor.metrics.disableAlerts フィールドで無効にすることができます。この設定では、ルールテンプレート名のリストを指定できます。アラートテンプレート名のリストについては、デフォルトルールのリストを参照してください。
テンプレートが無効化され、かつ spec.processor.metrics.healthRules フィールドで上書きされている場合、無効化設定が優先され、アラートルールは作成されません。
第12章 ダッシュボードとアラートでのメトリクスの使用
Network Observability Operator は、flowlogs-pipeline コンポーネントを使用して、フローログからメトリクスを生成します。カスタムアラートを設定し、ネットワークアクティビティー分析用のダッシュボードを表示するには、これらのメトリクスを使用します。
12.1. Network Observability メトリクスのダッシュボードの表示
OpenShift Container Platform コンソールの Overview タブを使用してネットワークオブザーバビリティーメトリクスダッシュボードを表示し、全体的なトラフィックフローとシステムの健全性を監視します。必要に応じて、ノード、namespace、所有者、Pod、サービスでメトリクスをフィルタリングできます。
手順
- Web コンソールの Observe → Dashboards で、Netobserv ダッシュボードを選択します。
次のカテゴリーのネットワークトラフィックメトリクスを表示します。各カテゴリーには、ノード、namespace、送信元、宛先ごとのサブセットがあります。
- バイトレート
- パケットドロップ
- DNS
- RTT
- Netobserv/Health ダッシュボードを選択します。
Operator の状態に関するメトリクスを以下のカテゴリーで表示します。各カテゴリーには、ノード、ネームスペース、送信元、送信先ごとのサブセットが含まれています。
- フロー
- フローのオーバーヘッド
- フローレート
- エージェント
- プロセッサー
Operator
Infrastructure および Application メトリクスは、namespace とワークロードの分割ビューで表示されます。
12.2. Network Observability メトリクス
netobserv_ というプレフィックスが付いたネットワークオブザーバビリティーメトリクスの包括的なリストを確認します。これは、FlowCollector リソースで設定でき、トラフィックを監視して Prometheus アラートを作成するために使用できます。
flowlogs-pipeline によって生成されるメトリクスは、FlowCollector カスタムリソースの spec.processor.metrics.includeList で設定して追加または削除できます。
Prometheus ルールの includeList メトリクスを使用してアラートを作成することもできます。「アラートの作成」の例を参照してください。
コンソールで Observe → Metrics を選択するなどして Prometheus でこれらのメトリクスを探す場合、またはアラートを定義する場合、すべてのメトリクス名に netobserv_ という接頭辞が付きます。たとえば、netobserv_namespace_flows_total です。利用可能なメトリクス名は以下のとおりです。
- includeList のメトリクス名
名前の後にアスタリスク
*が付いているものは、デフォルトで有効です。-
namespace_egress_bytes_total -
namespace_egress_packets_total -
namespace_ingress_bytes_total -
namespace_ingress_packets_total -
namespace_flows_total* -
node_egress_bytes_total -
node_egress_packets_total -
node_ingress_bytes_total* -
node_ingress_packets_total -
node_flows_total -
workload_egress_bytes_total -
workload_egress_packets_total -
workload_ingress_bytes_total* -
workload_ingress_packets_total -
workload_flows_total
-
- PacketDrop のメトリクス名
PacketDrop機能が (privilegedモードにより)spec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_drop_bytes_total -
namespace_drop_packets_total* -
node_drop_bytes_total -
node_drop_packets_total -
workload_drop_bytes_total -
workload_drop_packets_total
-
- DNS のメトリクス名
DNSTracking機能がspec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_dns_latency_seconds* -
node_dns_latency_seconds -
workload_dns_latency_seconds
-
- FlowRTT のメトリクス名
FlowRTT機能がspec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_rtt_seconds* -
node_rtt_seconds -
workload_rtt_seconds
-
- ネットワークイベントメトリクス名
NetworkEvents機能が有効になっている場合、このメトリクスはデフォルトで利用できます。-
namespace_network_policy_events_total
-
12.3. アラートの作成
Netobserv ダッシュボードメトリクスに基づいてカスタム AlertingRule リソースを作成し、OpenShift Container Platform コンソールでアラートをトリガーする条件を定義します。
前提条件
- cluster-admin ロールを持つユーザー、またはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。
- Network Observability Operator がインストールされています。
手順
- インポートアイコン + をクリックして、YAML ファイルを作成します。
アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、クラスターの Ingress トラフィックが宛先ワークロードごとの指定しきい値 (10 MBps) に達したときに、アラートが作成されます。
apiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: netobserv-alerts namespace: openshift-monitoring spec: groups: - name: NetObservAlerts rules: - alert: NetObservIncomingBandwidth annotations: message: |- {{ $labels.job }}: incoming traffic exceeding 10 MBps for 30s on {{ $labels.DstK8S_OwnerType }} {{ $labels.DstK8S_OwnerName }} ({{ $labels.DstK8S_Namespace }}). summary: "High incoming traffic." expr: sum(rate(netobserv_workload_ingress_bytes_total {SrcK8S_Namespace="openshift-ingress"}[1m])) by (job, DstK8S_Namespace, DstK8S_OwnerName, DstK8S_OwnerType) > 10000000 for: 30s labels: severity: warning-
netobserv_workload_ingress_bytes_totalメトリクスは、spec.processor.metrics.includeListでデフォルトで有効です。
-
- Create をクリックして設定ファイルをクラスターに適用します。
12.4. カスタムメトリクス
FlowMetric API を使用してフローログデータからカスタムメトリクスを定義します。このとき、ログフィールドを Prometheus ラベルとして活用してダッシュボード情報をカスタマイズし、特定のクラスターデータを監視します。
収集されるすべてのフローログデータには、送信元名や宛先名など、ログごとのラベルが付けられたフィールドがいくつかあります。これらのフィールドを Prometheus ラベルとして活用して、ダッシュボード上のクラスター情報をカスタマイズできます。
12.5. FlowMetric API を使用したカスタムメトリクスの設定
特定の監視ニーズを満たすために、フローログフィールドをラベルとしてマッピングしてカスタム Prometheus メトリクスを作成するように FlowMetric API を設定します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
-
FlowMetricリソースを設定します。カスタムメトリクスの設定例を参照してください。
検証
- Pod が更新されたら、Observe → Metrics に移動します。
-
Expression フィールドにメトリクス名を入力して、対応する結果を表示します。
topk(5, sum(rate(netobserv_cluster_external_ingress_bytes_total{DstK8S_Namespace="my-namespace"}[2m])) by (DstK8S_HostName, DstK8S_OwnerName, DstK8S_OwnerType))などの式を入力することもできます。
12.5.1. カスタムメトリクスの設定例
デフォルトのメトリクスではカバーされない、外部トラフィック量やレイテンシーの急増など、特定のネットワーク動作を監視するには、FlowMetric カスタムリソース (CR) を使用します。これらの例は、ネットワークフローから特定の Prometheus メトリクスを生成するために必要な設定を示しています。
12.5.1.1. クラスター外部ソースからの受信バイトを追跡
外部ネットワークからクラスターに流入するデータ量を測定するには、以下の FlowMetric 設定を使用します。このメトリクスは、潜在的な帯域幅の問題や予期せぬ外部データ転送コストを特定するのに役立ちます。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
spec:
metricName: cluster_external_ingress_bytes_total
type: Counter
valueField: Bytes
direction: Ingress
labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
filters:
- field: SrcSubnetLabel
matchType: Absenceここでは、以下のようになります。
metadata.namespace-
FlowMetricリソースが作成される名前空間を指定します。これは、FlowCollectorリソースのspec.namespaceフィールドで定義されている名前空間と一致する必要があります。デフォルトではnetobservです。 仕様メトリクス名-
Prometheus メトリクスの名前を指定します。OpenShift Container Platform の Web コンソールでは、
netobserv-<metricName> というプレフィックス付きで表示されます。 spec.type-
メトリクスの種類を指定します。
カウンター型は、バイト数やパケット数をカウントするのに便利です。 仕様方向- キャプチャーするトラフィックの方向を指定します。指定しない場合は、Ingress と Egress の両方がキャプチャーされ、重複したカウントが発生する可能性があります。
spec.labels-
メトリクスの外観、異なるエンティティー間の関係、およびメトリクスのカーディナリティーを定義するラベルを指定します。たとえば、
SrcK8S_Nameはカーディナリティーが高いメトリクスです。 仕様フィルター-
記載された基準に基づいて結果を絞り込むための基準を指定します。この例では、
SrcSubnetLabelが存在しないフローのみを照合することによって、クラスターの外部トラフィックのみを選択します。これは、サブネットラベル機能が有効になっていることを前提としています (spec.processor.subnetLabels経由)。これはデフォルトで有効になっています。
12.5.1.2. クラスター外部入力トラフィックの RTT 遅延を監視する
外部接続のパフォーマンスを分析し、高遅延パスを特定するには、以下の FlowMetric 設定を使用してください。このメトリクスは、標準的な Prometheus のレイテンシーダッシュボードに合わせるため、ナノ秒を秒に変換します。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-rtt
namespace: netobserv
spec:
metricName: cluster_external_ingress_rtt_seconds
type: Histogram
valueField: TimeFlowRttNs
direction: Ingress
labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
filters:
- field: SrcSubnetLabel
matchType: Absence
- field: TimeFlowRttNs
matchType: Presence
divider: "1000000000"
buckets: [".001", ".005", ".01", ".02", ".03", ".04", ".05", ".075", ".1", ".25", "1"]ここでは、以下のようになります。
metadata.namespace-
FlowMetricリソースが作成される名前空間を指定します。これは、FlowCollectorリソースのspec.namespaceフィールドで定義されている名前空間と一致する必要があります。デフォルトではnetobservです。 spec.type-
メトリクスの種類を指定します。
ヒストグラム型は、TimeFlowRttNsなどのレイテンシー値に便利です。 仕様区切り線- メトリクスを分割するために使用する値を指定します。フローでは往復時間 (RTT) がナノ秒単位で提供されるため、1,000,000,000 を除数として秒に変換してください。これは Prometheus ガイドラインの標準です。
仕様バケット- RTT 精度のためのカスタムバケットを指定します。最適な精度範囲は 5ms から 250ms です。
12.6. Traffic flows テーブルのネストされたフィールドまたは配列フィールドからメトリクスを作成する
FlowMetric カスタムリソースを作成して、Traffic flows テーブル内のネストされたフィールドまたは配列フィールド (Network events や Interfaces など) のメトリクスを生成します。
OVN Observability/NetworkEvents の表示はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OVN Observability とネットワークイベントの表示および追跡機能は、OpenShift Container Platform 4.17 および 4.18 でのみ利用できます。
次の例は、ネットワークポリシーイベントの Network events フィールドからメトリクスを生成する方法を示しています。
前提条件
-
NetworkEvents featureを有効にする。これを行う方法は、関連情報を参照してください。 - ネットワークポリシーが指定されている。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
FlowMetricリソースを作成して、次の設定を追加します。ポリシー名と namespace ごとにネットワークポリシーイベントをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: network-policy-events namespace: netobserv spec: metricName: network_policy_events_total type: Counter labels: [NetworkEvents>Type, NetworkEvents>Namespace, NetworkEvents>Name, NetworkEvents>Action, NetworkEvents>Direction] filters: - field: NetworkEvents>Feature value: acl flatten: [NetworkEvents] remap: "NetworkEvents>Type": type "NetworkEvents>Namespace": namespace "NetworkEvents>Name": name "NetworkEvents>Direction": directionここでは、以下のようになります。
spec.labels-
トラフィックフロー テーブルの ネットワークイベント のネストされたフィールドを表すラベルを指定します。各ネットワークイベントには、特定のタイプ、namespace、名前、アクション、方向があります。OpenShift Container Platform のバージョンで
NetworkEventsが利用できない場合は、代わりにInterfacesを指定することもできます。 仕様をフラット化する- 個別の項目として表現される項目のリストを含むオプションのフィールドを指定します。
仕様リマップ- Prometheus で名前を変更するオプションのフィールドセットを指定します。
検証
- Web コンソールで、Observe → Dashboards に移動し、下にスクロールして Network Policy タブを表示します。
- 作成したメトリクスとネットワークポリシー仕様に基づき、メトリクスのフィルタリングが適用されているはずです。
カーディナリティーが高いと、Prometheus のメモリー使用量に影響する可能性があります。特定のラベルのカーディナリティーが高いかどうかは、ネットワークフロー形式のリファレンス で確認できます。
12.7. FlowMetric API を使用したカスタムグラフの設定
FlowMetric カスタムリソースのチャートセクションを定義して、OpenShift Container Platform Web コンソールダッシュボードのカスタムチャートを生成します。
管理者は、Dashboard メニューでカスタムチャートを表示できます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
-
FlowMetricリソースを設定します。フローメトリクスチャートの設定例を参照してください。
検証
- Pod が更新されたら、Observe → Dashboards に移動します。
NetObserv / Main ダッシュボードを検索します。NetObserv / Main ダッシュボードの下、または必要に応じて作成したダッシュボード名の下にある次の 2 つのパネルを確認します。
- すべてのディメンションにわたりグローバルな外部 Ingress レートを合計したテキスト形式の単一の統計
- 上記と同じメトリクスを示す、宛先ワークロードごとの時系列グラフ
クエリー言語の詳細は、Prometheus のドキュメント を参照してください。
12.7.1. フローメトリクスチャートの設定例
これらの FlowMetric カスタムリソースの例では、外部からの受信トラフィックとラウンドトリップタイム (RTT) の遅延を追跡するために、OpenShift Container Platform の Web コンソールでグラフを定義する方法を示しています。
12.7.1.1. クラスター外部ソースのイングレスバイトチャート
クラスター外部ソースからの受信トラフィックのレートを追跡するには、以下の設定を使用してください。これらのグラフは、ワークロードごとの帯域幅使用量を把握するのに役立ちます。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
# ...
charts:
- dashboardName: Main
title: External ingress traffic
unit: Bps
type: SingleStat
queries:
- promQL: "sum(rate($METRIC[2m]))"
legend: ""
- dashboardName: Main
sectionName: External
title: Top external ingress traffic per workload
unit: Bps
type: StackArea
queries:
- promQL: "sum(rate($METRIC{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace, DstK8S_OwnerName)"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...ここでは、以下のようになります。
metadata.namespace-
FlowMetricリソースが作成される名前空間を指定します。これは、FlowCollectorspec.namespaceで定義されている名前空間と一致する必要があります。デフォルトではnetobservです。 spec.charts.dashboardName-
ダッシュボードの名前を指定します。異なる
dashboardNameを使用すると、接頭辞がNetobservである新しいダッシュボードが作成されます。たとえば、Netobserv / <dashboard_name> です。
12.7.1.2. クラスター外部入力トラフィックの RTT 遅延チャート
クラスター外部からの受信トラフィックの往復時間 (RTT) を監視するには、以下の設定を使用してください。これらの例では、histogram_quantile 関数を使用して 50 パーセンタイルと 99 パーセンタイル (p50 と p99) を表示します。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
# ...
charts:
- dashboardName: Main
title: External ingress TCP latency
unit: seconds
type: SingleStat
queries:
- promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket[2m])) by (le)) > 0"
legend: "p99"
- dashboardName: Main
sectionName: External
title: "Top external ingress sRTT per workload, p50 (ms)"
unit: seconds
type: Line
queries:
- promQL: "histogram_quantile(0.5, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
- dashboardName: Main
sectionName: External
title: "Top external ingress sRTT per workload, p99 (ms)"
unit: seconds
type: Line
queries:
- promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...ここでは、以下のようになります。
metadata.namespace-
FlowMetricリソースが作成される名前空間を指定します。これは、FlowCollectorspec.namespaceで定義されている名前空間と一致する必要があります。デフォルトではnetobservです。 spec.charts.dashboardName-
ダッシュボードの名前を指定します。異なる
dashboardNameを使用すると、接頭辞がNetobservである新しいダッシュボードが作成されます。たとえば、Netobserv / <dashboard_name> です。
12.7.1.3. ヒストグラムの平均値を計算する
ヒストグラムを作成するときに自動的に生成されるメトリクス $METRIC_sum をメトリクス $METRIC_count で割ることで、ヒストグラムの平均を表示できます。前述の例では、これを実行するための Prometheus クエリーは次のとおりです。
promQL: "(sum(rate($METRIC_sum{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName) / sum(rate($METRIC_count{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName))*1000"12.8. FlowMetric API と TCP フラグを使用した SYN フラッディングの検出
TCP フラグを監視するカスタムの AlertingRule および FlowMetric 設定をデプロイし、クラスターに対する SYN フラッディング攻撃をリアルタイムで検出し、警告できるようにします。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
FlowMetricリソースを作成して、次の設定を追加します。TCP フラグを使用して、宛先ホストとリソースごとにフローをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: flows-with-flags-per-destination spec: metricName: flows_with_flags_per_destination_total type: Counter labels: [SrcSubnetLabel,DstSubnetLabel,DstK8S_Name,DstK8S_Type,DstK8S_HostName,DstK8S_Namespace,Flags]TCP フラグを使用して、ソースホストとリソースごとにフローをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: flows-with-flags-per-source spec: metricName: flows_with_flags_per_source_total type: Counter labels: [DstSubnetLabel,SrcSubnetLabel,SrcK8S_Name,SrcK8S_Type,SrcK8S_HostName,SrcK8S_Namespace,Flags]SYN フラッディングを警告するための次の
AlertingRuleリソースをデプロイします。SYN フラッディングの
AlertingRuleapiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: netobserv-syn-alerts namespace: openshift-monitoring # ... spec: groups: - name: NetObservSYNAlerts rules: - alert: NetObserv-SYNFlood-in annotations: message: |- {{ $labels.job }}: incoming SYN-flood attack suspected to Host={{ $labels.DstK8S_HostName}}, Namespace={{ $labels.DstK8S_Namespace }}, Resource={{ $labels.DstK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports. summary: "Incoming SYN-flood" expr: sum(rate(netobserv_flows_with_flags_per_destination_total{Flags="2"}[1m])) by (job, DstK8S_HostName, DstK8S_Namespace, DstK8S_Name) > 300 for: 15s labels: severity: warning app: netobserv - alert: NetObserv-SYNFlood-out annotations: message: |- {{ $labels.job }}: outgoing SYN-flood attack suspected from Host={{ $labels.SrcK8S_HostName}}, Namespace={{ $labels.SrcK8S_Namespace }}, Resource={{ $labels.SrcK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports. summary: "Outgoing SYN-flood" expr: sum(rate(netobserv_flows_with_flags_per_source_total{Flags="2"}[1m])) by (job, SrcK8S_HostName, SrcK8S_Namespace, SrcK8S_Name) > 300 for: 15s labels: severity: warning app: netobserv # ...この例では、アラートのしきい値は
300ですが、この値は環境に応じて調整できます。しきい値が低すぎると誤検出が発生する可能性があります。また、しきい値が高すぎると実際の攻撃を見逃す可能性があります。
検証
- Web コンソールで、Network Traffic テーブルビューの Manage Columns をクリックし、TCP flags をクリックします。
- Network Traffic テーブルビューで、TCP protocol SYN TCPFlag でフィルタリングします。同じ byteSize を持つフローが多数ある場合は、SYN フラッドが発生しています。
- Observe → Alerting に移動し、Alerting Rules タブを選択します。
- netobserv-synflood-in alert でフィルタリングします。SYN フラッディングが発生すると、アラートが起動するはずです。
第13章 Network Observability Operator の監視
OpenShift Container Platform Web コンソールを使用して、Network Observability Operator の健全性に関連するアラートを監視します。これにより、システムの安定性を維持し、運用上の問題を迅速に検出できます。
13.1. 健全性ダッシュボード
OpenShift Container Platform Web コンソールで Network Observability Operator ヘルスダッシュボードを表示して、Operator とそのコンポーネントのヘルスステータス、リソース使用率、内部統計を監視します。
メトリクスは、OpenShift Container Platform Web コンソールの Observe → Dashboards ページにあります。Network Observability Operator の健全性に関する次のカテゴリーのメトリクスを表示できます。
- 1 秒あたりのフロー数
- Sampling
- 過去 1 分間のエラー数
- 1 秒あたりのドロップされたフロー数
- flowlogs-pipeline 統計
- flowlogs-pipeline 統計ビュー
- eBPF エージェント統計ビュー
- Operator 統計
- リソースの使用状況
13.2. 健全性アラート
Loki 取り込みエラー、ゼロフロー取り込み、eBPF フローのドロップなどの発生時にバナーをトリガーする、Network Observability Operator によって生成されるヘルスアラートについて説明します。
アラートがトリガーされると、ダッシュボードに誘導するヘルスアラートバナーが Network Traffic ページと Home ページに表示されることがあります。アラートは次の場合に生成されます。
-
NetObservLokiErrorアラートは、Loki 取り込みレート制限に達した場合など、Loki エラーが原因でflowlogs-pipelineワークロードがフローをドロップすると発生します。 -
NetObservNoFlowsアラートは、一定時間フローが取り込まれない場合に発生します。 -
NetObservFlowsDroppedアラートは、Network Observability eBPF エージェントの HashMap テーブルがいっぱいで、eBPF エージェントがパフォーマンスが低下した状態でフローを処理している場合、または容量制限がトリガーされた場合に発生します。
13.3. 健全性情報の表示
OpenShift Container Platform Web コンソール内の Netobserv/Health ダッシュボードを表示して、Network Observability Operator とそのコンポーネントのヘルスステータスとリソース使用状況を監視します。
前提条件
- Network Observability Operator がインストールされています。
-
cluster-adminロールまたはすべてのプロジェクトの表示パーミッションを持つユーザーとしてクラスターにアクセスできる。
手順
- Web コンソールの Administrator パースペクティブから、Observe → Dashboards に移動します。
- Dashboards ドロップダウンメニューから、Netobserv/Health を選択します。
- ページに表示された Operator の健全性に関するメトリクスを確認します。
13.3.1. ヘルスアラートの無効化
FlowCollector リソースを編集し、spec.processor.metrics.disableAlerts 仕様を使用して、NetObservLokiError や NetObservNoFlows などの特定のヘルスアラートを無効にします。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
次の YAML サンプルのように、
spec.processor.metrics.disableAlertsを追加してヘルスアラートを無効にします。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: metrics: disableAlerts: [NetObservLokiError, NetObservNoFlows]ここでは、以下のようになります。
spec.processor.metrics.disableAlerts- 無効にするアラートの種類を 1 つ以上指定します。
13.4. NetObserv ダッシュボードの Loki レート制限アラートの作成
Loki メトリクスに基づいてカスタム AlertingRule リソースを作成して、HTTP 429 エラーによって示される Loki 取り込みレート制限への到達を監視し、アラートをトリガーします。
Netobserv ダッシュボードメトリクスのカスタム警告ルールを作成して、Loki のレート制限に達した場合にアラートをトリガーできます。
前提条件
- cluster-admin ロールを持つユーザー、またはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。
- Network Observability Operator がインストールされています。
手順
- インポートアイコン + をクリックして、YAML ファイルを作成します。
アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、Loki のレート制限に達した場合にアラートが作成されます。
apiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: loki-alerts namespace: openshift-monitoring spec: groups: - name: LokiRateLimitAlerts rules: - alert: LokiTenantRateLimit annotations: message: |- {{ $labels.job }} {{ $labels.route }} is experiencing 429 errors. summary: "At any number of requests are responded with the rate limit error code." expr: sum(irate(loki_request_duration_seconds_count{status_code="429"}[1m])) by (job, namespace, route) / sum(irate(loki_request_duration_seconds_count[1m])) by (job, namespace, route) * 100 > 0 for: 10s labels: severity: warning- Create をクリックして設定ファイルをクラスターに適用します。
13.5. eBPF エージェントアラートの使用
FlowCollector カスタムリソースの spec.agent.ebpf.cacheMaxFlows 値を増やして、eBPF エージェントハッシュマップがいっぱいになったときに発生する NetObservAgentFlowsDropped アラートを解決します。
容量制限がトリガーされると、NetObservAgentFlowsDropped アラートもトリガーされます。このアラートが表示された場合は、次の例に示すように、FlowCollector の cacheMaxFlows を増やすことを検討してください。
cacheMaxFlows を増やすと、eBPF エージェントのメモリー使用量が増加する可能性があります。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
次の YAML サンプルに示すように、
spec.agent.ebpf.cacheMaxFlowsの値を増やします。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv deploymentModel: Service agent: type: eBPF ebpf: cacheMaxFlows: 200000ここでは、以下のようになります。
spec.agent.ebpf.cacheMaxFlows-
キャッシュするフローの最大数を指定します。
NetObservAgentFlowsDroppedアラートが発生した場合は、この値を現在のレベルから増やしてください。
第14章 リソースのスケジューリング
taint と toleration は、どのノードに特定の Pod を配置するかを制御するのに役立ちます。Network Observability コンポーネントの配置を制御するには、これらの手段をノードセレクターとともに使用します。
ノードセレクターは、ノードのカスタムラベルと Pod で指定されたセレクターを使用して定義されるキー/値のペアのマップを指定します。
Pod がノードで実行する要件を満たすには、Pod にはノードのラベルと同じキー/値のペアがなければなりません。
14.1. 特定のノードにおける Network Observability デプロイメント
NodeSelector、Tolerations、Affinity などのスケジューリング仕様を使用して FlowCollector リソースを設定し、特定のノード上のネットワークオブザーバビリティーコンポーネントのデプロイメントを制御します。
spec.agent.ebpf.advanced.scheduling、spec.processor.advanced.scheduling、および spec.consolePlugin.advanced.scheduling 仕様で、次の設定が可能です。
-
NodeSelector -
Tolerations -
Affinity -
PriorityClassName
spec.<component>.advanced.scheduling のサンプル FlowCollector リソース
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
# ...
advanced:
scheduling:
tolerations:
- key: "<taint key>"
operator: "Equal"
value: "<taint value>"
effect: "<taint effect>"
nodeSelector:
<key>: <value>
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: name
operator: In
values:
- app-worker-node
priorityClassName: """
# ...第15章 セカンダリーネットワーク
Network Observability Operator を設定して、SR-IOV や OVN-Kubernetes などのセカンダリーネットワークからネットワークフローデータを収集し、データをエンリッチすることができます。
15.1. 前提条件
- セカンダリーインターフェイスや L2 ネットワークなど、追加のネットワークインターフェイスを備えた OpenShift Container Platform クラスターへのアクセス。
15.2. SR-IOV インターフェイストラフィックの監視の設定
FlowCollector リソースを設定して、spec.agent.ebpf.privileged フィールドを true に設定することで、Single Root I/O Virtualization (SR-IOV) デバイス上のトラフィックを監視できるようになります。これにより、eBPF エージェントが他のネットワーク名前空間を監視できるようになります。
eBPF エージェントは、デフォルトで監視されるホストネットワーク名前空間に加えて、他のネットワーク名前空間も監視します。仮想機能 (VF) インターフェイスを持つ Pod が作成されると、新しいネットワーク namespace が作成されます。SRIOVNetwork ポリシーの IPAM 設定を指定すると、VF インターフェイスがホストネットワーク namespace から Pod ネットワーク namespace に移行されます。
前提条件
- SR-IOV デバイスを使用して OpenShift Container Platform クラスターにアクセスできる。
-
SRIOVNetworkカスタムリソース (CR) のspec.ipam設定は、インターフェイスのリストにある範囲または他のプラグインからの IP アドレスを使用して設定する必要があります。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。SR-IOV モニタリング用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv deploymentModel: Service agent: type: eBPF ebpf: privileged: true-
SR-IOV モニタリングを有効にするには、
spec.agent.ebpf.privilegedフィールドの値をtrueに設定する必要があります。
-
SR-IOV モニタリングを有効にするには、
15.3. 仮想マシン (VM) のセカンダリーネットワークインターフェイスを Network Observability 用に設定する
eBPF エージェントを 特権 モードに設定し、セカンダリーネットワークのインデックスを定義することで、FlowCollector を 設定して仮想マシンのセカンダリーネットワークトラフィックを監視し、OpenShift 仮想化からのフローのキャプチャーとエンリッチメントを有効にします。
デフォルトの内部 Pod ネットワークに接続されている仮想マシンから発信されるネットワークフローは、ネットワークオブザーバビリティーによって自動的に捕捉されます。
手順
次のコマンドを実行して、仮想マシンのランチャー Pod に関する情報を取得します。この情報はステップ 5 で使用します。
$ oc get pod virt-launcher-<vm_name>-<suffix> -n <namespace> -o yamlapiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/network-status: |- [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.129.2.39" ], "mac": "0a:58:0a:81:02:27", "default": true, "dns": {} }, { "name": "my-vms/l2-network", "interface": "podc0f69e19ba2", "ips": [ "10.10.10.15" ], "mac": "02:fb:f8:00:00:12", "dns": {} }] name: virt-launcher-fedora-aqua-fowl-13-zr2x9 namespace: my-vms spec: # ... status: # ...ここでは、以下のようになります。
name- セカンダリーネットワークの名前を指定します。
interface- セカンダリーネットワークのネットワークインターフェイスを指定します。
ips- セカンダリーネットワークで使用される IP アドレスのリストを指定します。
mac- セカンダリーネットワークで使用する MAC アドレスを指定します。
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
追加のネットワーク調査で調べた情報に基づいて
FlowCollectorを設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: privileged: true processor: advanced: secondaryNetworks: - index: - MAC name: my-vms/l2-network # ...ここでは、以下のようになります。
仕様エージェント ebpf 特権-
eBPF エージェントが
特権モードで実行されることを指定します。これは、仮想マシンランチャー Pod 上のセカンダリーネットワークインターフェイスからフローを収集するために必要です。 spec.processor.advanced.secondaryNetworks.index-
仮想マシンランチャー Pod のインデックス作成に使用するフィールドを指定します。セカンダリーインターフェイスのネットワークフローのエンリッチメントを取得するには、
MACアドレスをインデックスフィールドとして使用することを推奨します。Pod 間で MAC アドレスが重複している場合は、IP アドレスやインターフェイスなどの追加のインデックスフィールドを追加することで、正確なエンリッチメントを確保できます。 MAC-
インデックスフィールドの値として MAC アドレスを指定します。追加のネットワーク情報に MAC アドレスが含まれている場合は、
インデックスフィールドリストにMACを追加してください。 仕様プロセッサー.高度なセカンダリーネットワーク名-
仮想マシンランチャー Pod の
k8s.v1.cni.cncf.io/network-statusアノテーションに記載されているセカンダリーネットワークの名前を指定します。形式は通常、< 名前空間 >/< ネットワーク接続定義名 >です。
検証
仮想マシンのトラフィックを観測します。
- Network Traffic ページに移動します。
-
k8s.v1.cni.cncf.io/network-statusアノテーションで見つかった仮想マシンの IP を使用して、Source IP でフィルタリングします。 - エンリッチする必要がある Source フィールドと Destination フィールドの両方を表示し、仮想マシンランチャー Pod と仮想マシンインスタンスを所有者として指定します。
第16章 Network Observability CLI
16.1. Network Observability CLI のインストール
Network Observability CLI (oc netobserv) は、Network Observability Operator とは別にデプロイされます。CLI は、OpenShift CLI (oc) プラグインとして利用できます。CLI は、Network Observability を活用して、迅速にデバッグおよびトラブルシューティングを行う軽量な方法です。
16.1.1. Network Observability CLI について
Network Observability CLI (oc netobserv) を使用して、ネットワークの問題を迅速にデバッグおよびトラブルシューティングします。このツールを使用することで、Network Observability Operator をインストールしなくても、フローとパケットに関するライブ分析情報が即座に提供されます。
Network Observability CLI は、eBPF エージェントを利用して収集したデータを一時的なコレクター Pod にストリーミングするフローおよびパケット可視化ツールです。キャプチャー中に永続的なストレージは必要ありません。実行後、出力がローカルマシンに転送されます。
CLI のキャプチャーは、8 - 10 分などの短い期間のみ実行されるように設計されています。実行時間が長すぎると、実行中のプロセスを削除するのが難しくなる可能性があります。
16.1.2. Network Observability CLI のインストール
Network Observability CLI は、ネットワーク可観測性のデバッグおよびトラブルシューティングを迅速に行う軽量な方法です。これは、別途インストールする必要があります。
Network Observability CLI (oc netobserv) のインストールは、Network Observability Operator のインストールとは別の手順です。つまり、Operator がソフトウェアカタログからインストールされている場合でも、CLI を別途インストールする必要があります。
ユーザーは、必要に応じて、Krew を使用して netobserv CLI プラグインをインストールできます。詳細は、「Krew を使用した CLI プラグインのインストール」を参照してください。
前提条件
-
OpenShift CLI (
oc) をインストールしておく。 - macOS または Linux オペレーティングシステムがある。
-
dockerまたはpodmanをインストールする必要があります。
インストールコマンドの実行には、podman または docker を使用できます。この手順では podman を使用します。
手順
次のコマンドを実行して、Red Hat レジストリー にログインします。
$ podman login registry.redhat.io次のコマンドを実行して、イメージから
oc-netobservファイルを抽出します。$ podman create --name netobserv-cli registry.redhat.io/network-observability/network-observability-cli-rhel9:1.11 $ podman cp netobserv-cli:/oc-netobserv . $ podman rm netobserv-cli次のコマンドを実行して、抽出したファイルをシステムの
PATHにあるディレクトリー (/usr/local/bin/など) に移動します。$ sudo mv oc-netobserv /usr/local/bin/
検証
oc netobservが利用可能であることを確認します。$ oc netobserv versionこのコマンドを実行すると、次の例のような結果が生成されるはずです。
Netobserv CLI version <version>16.2. Network Observability CLI の使用
フローやパケットデータをターミナル内で直接可視化およびフィルタリングすると、特定のポートを使用しているユーザーの特定など、詳細な使用状況を確認できます。Network Observability CLI は、フローを JSON およびデータベースファイルとして、パケットを PCAP ファイルとして収集します。これらのファイルはサードパーティーツールで使用できます。
16.2.1. フローのキャプチャー
ネットワークフローをキャプチャーし、リソースまたはゾーンに基づいてフィルターを CLI で直接適用します。これは、2 つの異なるゾーン間のラウンドトリップタイム (RTT) を可視化するなど、複雑なユースケースを解決するために役立ちます。
CLI でのテーブル視覚化により、表示機能とフロー検索機能が提供されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
次のコマンドを実行して、フィルターを有効にしてフローをキャプチャーします。
$ oc netobserv flows --enable_filter=true --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルの
live table filterプロンプトでフィルターを追加して、受信するフローをさらに絞り込みます。以下に例を示します。live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once- PageUp キーと PageDown キーを使用して、None、Resource、Zone、Host、Owner、および all of the above を切り替えます。
-
キャプチャーを停止するには、Ctrl+C を押します。キャプチャーされたデータは、CLI のインストールに使用したのと同じパスにある
./outputディレクトリー内の 2 つの異なるファイルに書き込まれます。 キャプチャーされたデータを、JSON ファイル
./output/flow/<capture_date_time>.jsonで確認します。このファイルには、キャプチャーされたデータの JSON 配列が含まれています。JSON ファイルの例:
{ "AgentIP": "10.0.1.76", "Bytes": 561, "DnsErrno": 0, "Dscp": 20, "DstAddr": "f904:ece9:ba63:6ac7:8018:1e5:7130:0", "DstMac": "0A:58:0A:80:00:37", "DstPort": 9999, "Duplicate": false, "Etype": 2048, "Flags": 16, "FlowDirection": 0, "IfDirection": 0, "Interface": "ens5", "K8S_FlowLayer": "infra", "Packets": 1, "Proto": 6, "SrcAddr": "3e06:6c10:6440:2:a80:37:b756:270f", "SrcMac": "0A:58:0A:80:00:01", "SrcPort": 46934, "TimeFlowEndMs": 1709741962111, "TimeFlowRttNs": 121000, "TimeFlowStartMs": 1709741962111, "TimeReceived": 1709741964 }SQLite を使用して、
./output/flow/<capture_date_time>.dbデータベースファイルを検査できます。以下に例を示します。次のコマンドを実行してファイルを開きます。
$ sqlite3 ./output/flow/<capture_date_time>.dbSQLite
SELECTステートメントを実行してデータをクエリーします。次に例を示します。sqlite> SELECT DnsLatencyMs, DnsFlagsResponseCode, DnsId, DstAddr, DstPort, Interface, Proto, SrcAddr, SrcPort, Bytes, Packets FROM flow WHERE DnsLatencyMs >10 LIMIT 10;出力例
12|NoError|58747|10.128.0.63|57856||17|172.30.0.10|53|284|1 11|NoError|20486|10.128.0.52|56575||17|169.254.169.254|53|225|1 11|NoError|59544|10.128.0.103|51089||17|172.30.0.10|53|307|1 13|NoError|32519|10.128.0.52|55241||17|169.254.169.254|53|254|1 12|NoError|32519|10.0.0.3|55241||17|169.254.169.254|53|254|1 15|NoError|57673|10.128.0.19|59051||17|172.30.0.10|53|313|1 13|NoError|35652|10.0.0.3|46532||17|169.254.169.254|53|183|1 32|NoError|37326|10.0.0.3|52718||17|169.254.169.254|53|169|1 14|NoError|14530|10.0.0.3|58203||17|169.254.169.254|53|246|1 15|NoError|40548|10.0.0.3|45933||17|169.254.169.254|53|174|1
16.2.2. パケットのキャプチャー
ネットワークパケットをキャプチャーするには、Network Observability CLI を使用します。正確なリアルタイムデバッグを実現するために、ターミナル内でフィルターを適用して調整できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
フィルターを有効にしてパケットキャプチャーを実行します。
$ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルの
live table filterプロンプトでフィルターを追加して、受信するパケットを絞り込みます。フィルターの例は次のとおりです。live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once- PageUp キーと PageDown キーを使用して、None、Resource、Zone、Host、Owner、および all of the above を切り替えます。
- キャプチャーを停止するには、Ctrl+C を押します。
キャプチャーされたデータを確認します。このデータは、CLI のインストールに使用したのと同じパスにある
./output/pcapディレクトリー内の 1 つのファイルに書き込まれます。-
./output/pcap/<capture_date_time>.pcapファイルは Wireshark で開くことができます。
-
16.2.3. メトリクスの取得
サービスモニターを使用して、Prometheus でオンデマンドネットワークオブザーバビリティーダッシュボードを生成します。これにより、ネットワークメトリクスをすばやく表示および分析できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
次のコマンドを実行して、フィルターを有効にしてメトリクスをキャプチャーします。
出力例
$ oc netobserv metrics --enable_filter=true --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルで提供されているリンクを開いて NetObserv / On-Demand ダッシュボードを表示します。
URL の例
https://console-openshift-console.apps.rosa...openshiftapps.com/monitoring/dashboards/netobserv-cli注記有効になっていない機能は空のグラフとして表示されます。
16.2.4. Network Observability CLI のクリーンアップ
oc netobserv cleanup を使用して、Network Observability CLI によってインストールされたすべてのコンポーネントをクラスターから手動で削除します。クライアントはキャプチャー後にこのコマンドを自動的に実行しますが、接続の問題が発生した場合は手動で実行する必要があります。
手順
以下のコマンドを実行します。
$ oc netobserv cleanup
16.3. Network Observability CLI (oc netobserv) リファレンス
Network Observability CLI (oc netobserv) は、Network Observability Operator で使用できるほとんどの機能とフィルタリングオプションを備えています。コマンドライン引数を渡すことで、機能やフィルタリングオプションを有効にできます。
16.3.1. Network Observability CLI の使用
Network Observability CLI (oc netobserv) を使用して、コマンドライン引数を渡してさらに分析するためのフローデータ、パケットデータ、メトリクスをキャプチャーしたり、Network Observability Operator がサポートする機能を有効にしたりできます。
16.3.1.1. 構文
oc netobserv コマンドの基本構文:
oc netobserv の構文
$ oc netobserv [<command>] [<feature_option>] [<command_options>] - 1
- 機能オプションは、
oc netobserv flowsコマンドでのみ使用できます。oc netobserv packetsコマンドでは使用できません。
16.3.1.2. 基本コマンド
| コマンド | 説明 |
|---|---|
| flows | フロー情報をキャプチャーします。サブコマンドは、「フローキャプチャーのオプション」表を参照してください。 |
| packets | パケットデータをキャプチャーします。サブコマンドは、「パケットキャプチャーのオプション」表を参照してください。 |
| metrics | メトリクスデータをキャプチャーします。サブコマンドは、「メトリクスキャプチャーのオプション」の表を参照してください。 |
| follow | バックグラウンドで実行しているときはコレクターログに従います。 |
| stop | エージェントデーモンセットを削除して収集を停止します。 |
| copy | コレクターが生成したファイルをローカルにコピーします。 |
| cleanup | Network Observability CLI コンポーネントを削除します。 |
| version | ソフトウェアのバージョンを出力します。 |
| help | ヘルプを表示します。 |
16.3.1.3. フローキャプチャーのオプション
フローキャプチャーには、必須コマンドのほか、パケットドロップ、DNS 遅延、ラウンドトリップタイム、フィルタリングに関する追加機能の有効化などの追加オプションがあります。
oc netobserv flows の構文
$ oc netobserv flows [<feature_option>] [<command_options>]| オプション | 説明 | デフォルト |
|---|---|---|
| --enable_all | すべての eBPF 機能の有効化 | false |
| --enable_dns | DNS 追跡の有効化 | false |
| --enable_ipsec | IPsec トラッキングの有効化 | false |
| --enable_network_events | ネットワークイベントモニタリングの有効化 | false |
| --enable_pkt_translation | パケット変換の有効化 | false |
| --enable_pkt_drop | パケットドロップの有効化 | false |
| --enable_rtt | RTT 追跡の有効化 | false |
| --enable_udn_mapping | ユーザー定義ネットワークマッピングの有効化 | false |
| --get-subnets | サブネット情報の取得 | false |
| --privileged | eBPF エージェント特権モードの強制 | auto |
| --sampling | パケットサンプリング間隔 | 1 |
| --background | バックグラウンドでの実行 | false |
| --copy | 出力ファイルをローカルにコピー | prompt |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 5m |
| --max-bytes | 最大キャプチャーバイト数 | 50000000 = 50 MB |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
| --interfaces | 監視するインターフェイスのリスト (コンマ区切り) | - |
| --exclude_interfaces | 除外するインターフェイスのリスト (コンマ区切り) | lo |
PacketDrop および RTT 機能を有効にして TCP プロトコルとポート 49051 でフローキャプチャーを実行する例:
$ oc netobserv flows --enable_pkt_drop --enable_rtt --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=4905116.3.1.4. パケットキャプチャーのオプション
フィルターを使用すると、フローのキャプチャーと同じようにパケットのキャプチャーデータをフィルタリングできます。パケットドロップ、DNS、RTT、ネットワークイベントなどの特定の機能は、フローおよびメトリクスのキャプチャーでのみ使用できます。
oc netobserv packets の構文
$ oc netobserv packets [<option>]| オプション | 説明 | デフォルト |
|---|---|---|
| --background | バックグラウンドでの実行 | false |
| --copy | 出力ファイルをローカルにコピー | prompt |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 5m |
| --max-bytes | 最大キャプチャーバイト数 | 50000000 = 50 MB |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
TCP プロトコルとポート 49051 でパケットキャプチャーを実行する例:
$ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=4905116.3.1.5. メトリクスキャプチャーのオプション
フローキャプチャーと同じように、メトリクスキャプチャーでも機能を有効にしてフィルターを使用できます。生成されたグラフはダッシュボードに適宜表示されます。
oc netobserv metrics 構文
$ oc netobserv metrics [<option>]| オプション | 説明 | デフォルト |
|---|---|---|
| --enable_all | すべての eBPF 機能の有効化 | false |
| --enable_dns | DNS 追跡の有効化 | false |
| --enable_ipsec | IPsec トラッキングの有効化 | false |
| --enable_network_events | ネットワークイベントモニタリングの有効化 | false |
| --enable_pkt_translation | パケット変換の有効化 | false |
| --enable_pkt_drop | パケットドロップの有効化 | false |
| --enable_rtt | RTT 追跡の有効化 | false |
| --enable_udn_mapping | ユーザー定義ネットワークマッピングの有効化 | false |
| --get-subnets | サブネット情報の取得 | false |
| --privileged | eBPF エージェント特権モードの強制 | auto |
| --sampling | パケットサンプリング間隔 | 1 |
| --background | バックグラウンドでの実行 | false |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 1h |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
| --include_list | 生成するメトリクス名のリスト (コンマ区切り) | namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total |
| --interfaces | 監視するインターフェイスのリスト (コンマ区切り) | - |
| --exclude_interfaces | 除外するインターフェイスのリスト (コンマ区切り) | lo |
TCP ドロップのメトリクスキャプチャーの実行例
$ oc netobserv metrics --enable_pkt_drop --protocol=TCP第17章 FlowCollector API リファレンス
FlowCollector API は、ネットワークフローを収集するためのデプロイメントを制御および設定するために使用される基礎となるスキーマです。このリファレンスガイドは、このような重要な設定を管理するのに役立ちます。
17.1. FlowCollector API 仕様
- 説明
-
FlowCollectorは、基盤となるデプロイメントを操作および設定するネットワークフロー収集 API のスキーマです。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。 |
|
|
| 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。 |
|
|
|
FlowCollector リソースの望ましい状態を定義します。 *: このドキュメントで「サポート対象外」または「非推奨」と記載されている場合、Red Hat はその機能を公式にサポートしていません。たとえば、コミュニティーによって提供され、メンテナンスに関する正式な合意なしに受け入れられた可能性があります。製品のメンテナーは、ベストエフォートに限定してこれらの機能に対するサポートを提供する場合があります。 |
17.1.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
17.1.2. .spec
- 説明
FlowCollector リソースの望ましい状態を定義します。
*: このドキュメントで「サポート対象外」または「非推奨」と記載されている場合、Red Hat はその機能を公式にサポートしていません。たとえば、コミュニティーによって提供され、メンテナンスに関する正式な合意なしに受け入れられた可能性があります。製品のメンテナーは、ベストエフォートに限定してこれらの機能に対するサポートを提供する場合があります。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| フローを抽出するためのエージェント設定。 |
|
|
|
|
|
|
|
-
-
- フロープロセッサーが、DaemonSet をバックエンドとするホストネットワークを使用するエージェントから
Kafka は、より優れたスケーラビリティー、回復力、および高可用性を提供できます (詳細は、https://www.redhat.com/en/topics/integration/what-is-apache-kafka を 参照してください)。
メモリー効率が低いため、大規模クラスターでは |
|
|
|
|
|
|
|
Kafka 設定。Kafka をフローコレクションパイプラインの一部としてブローカーとして使用できます。この設定を利用できるのは、 |
|
|
|
|
|
|
| Network Observability Pod がデプロイされる namespace。 |
|
|
|
|
|
|
|
|
|
|
|
|
17.1.3. .spec.agent
- 説明
- フローを抽出するためのエージェント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.4. .spec.agent.ebpf
- 説明
-
ebpfは、spec.agent.typeがeBPFに設定されている場合、eBPF ベースのフローレポーターに関連する設定を示します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
有効にする追加機能のリスト。これらはデフォルトですべて無効になっています。追加機能を有効にすると、パフォーマンスに影響が出る可能性があります。可能な値は次のとおりです。
-
-
-
-
-
-
-
この機能を使用するには、カーネルデバッグファイルシステムをマウントする必要があるため、eBPF エージェント Pod を
- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eBPF Agent コンテナーの特権モード。 |
|
|
|
|
|
|
| eBPF プローブのサンプリング間隔。100 を指定すると、100 分の 1 のパケットが送信されます。0 または 1 を指定すると、すべてのパケットがサンプリングされます。 |
17.1.5. .spec.agent.ebpf.advanced
- 説明
-
advancedを使用すると、eBPF エージェントの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。このセクションでは、デフォルトの Linux ケイパビリティーをオーバーライドすることもできます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 特権モードで実行されていない場合に、Linux ケイパビリティーをオーバーライドします。デフォルトのケイパビリティーは、BPF、PERFMON、NET_ADMIN です。 |
|
|
|
|
|
|
| scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。 |
17.1.6. .spec.agent.ebpf.advanced.scheduling
- 説明
- scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.7. .spec.agent.ebpf.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.8. .spec.agent.ebpf.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.9. .spec.agent.ebpf.flowFilter
- 説明
-
flowFilterは、フローフィルタリングに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eBPF フローのフィルタリング機能を有効にするには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.10. .spec.agent.ebpf.flowFilter.rules
- 説明
-
rulesは、eBPF エージェントのフィルタリングルールのリストを定義します。フィルタリングが有効になっている場合、どのルールにも一致しないフローはデフォルトで拒否されます。デフォルトを変更するには、すべてを受け入れるルール ({ action: "Accept", cidr: "0.0.0.0/0" }) を定義してから拒否ルールで調整します。 - 型
-
array
17.1.11. .spec.agent.ebpf.flowFilter.rules[]
- 説明
-
EBPFFlowFilterRuleは、フローフィルタリングルールに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.12. .spec.agent.ebpf.metrics
- 説明
-
metricsは、メトリクスに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
eBPF エージェントのメトリクス収集を無効にするには、 |
|
|
| Prometheus スクレイパーのメトリクスサーバーエンドポイント設定。 |
17.1.13. .spec.agent.ebpf.metrics.server
- 説明
- Prometheus スクレイパーのメトリクスサーバーエンドポイント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| メトリクスサーバーの HTTP ポート。 |
|
|
| TLS 設定。 |
17.1.14. .spec.agent.ebpf.metrics.server.tls
- 説明
- TLS 設定。
- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TLS 設定のタイプを選択します。
- |
17.1.15. .spec.agent.ebpf.metrics.server.tls.provided
- 説明
-
typeがProvidedに設定されている場合の TLS 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.16. .spec.agent.ebpf.metrics.server.tls.providedCaFile
- 説明
-
typeがProvidedに設定されている場合の CA ファイルへの参照。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.17. .spec.agent.ebpf.resources
- 説明
-
resourcesは、このコンテナーが必要とするコンピューティングリソースです。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで Requests が省略される場合、明示的に指定される場合にデフォルトで Limits に設定されます。指定しない場合は、実装定義の値に設定されます。リクエストは制限を超えることはできません。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
17.1.18. .spec.consolePlugin
- 説明
-
consolePluginは、利用可能な場合、OpenShift Container Platform コンソールプラグインに関連する設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| コンソールプラグインのデプロイメントを有効にします。 |
|
|
|
|
|
|
|
コンソールプラグインバックエンドの |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| OpenShift Container Platform Console のプラグインとしてではなく、スタンドアロンのコンソールとしてデプロイします。OpenShift Container Platform と併用する場合は、統合されたエクスペリエンスが提供されないため、推奨されません。[サポート対象外 (*)] |
|
|
|
|
17.1.19. .spec.consolePlugin.advanced
- 説明
-
advancedを使用すると、コンソールプラグインの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.20. .spec.consolePlugin.advanced.scheduling
- 説明
-
schedulingは、Pod がノードでどのようにスケジュールされるかを制御します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.21. .spec.consolePlugin.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.22. .spec.consolePlugin.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.23. .spec.consolePlugin.autoscaler
- 説明
-
autoscaler[非推奨 (*)] プラグインデプロイメント用にセットアップする水平 Pod オートスケーラーの仕様。非推奨のお知らせ: マネージドオートスケーラーは将来のバージョンで削除されます。代わりに、お好みのオートスケーラーを設定し、spec.consolePlugin.unmanagedReplicasをtrueに設定することもできます。HorizontalPodAutoscaler のドキュメント (自動スケーリング/v2) を参照してください。 - 型
-
object
17.1.24. .spec.consolePlugin.portNaming
- 説明
-
portNaming は、ポート番号とサービス名の変換設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| コンソールプラグインのポートからサービス名への変換を有効にします。 |
|
|
|
|
17.1.25. .spec.consolePlugin.quickFilters
- 説明
-
quickFilters は、コンソールプラグイン用のクイックフィルタープリセットを設定します。外部トラフィック用のフィルターは、サブネットラベルが内部トラフィックと外部トラフィックを区別するように設定されていることを前提としています (spec.processor.subnetLabels を参照)。 - 型
-
array
17.1.26. .spec.consolePlugin.quickFilters[]
- 説明
-
QuickFilterは、コンソールのクイックフィルターのプリセット設定を定義します。 - 型
-
object - 必須
-
filter -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| コンソールに表示されるフィルターの名前 |
17.1.27. .spec.consolePlugin.resources
- 説明
-
resources(コンピューティングリソースから見た場合にコンテナーに必要)。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで Requests が省略される場合、明示的に指定される場合にデフォルトで Limits に設定されます。指定しない場合は、実装定義の値に設定されます。リクエストは制限を超えることはできません。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
17.1.28. .spec.exporters
- 説明
-
exportersは、カスタム消費またはストレージ用の追加のオプションのエクスポーターを定義します。 - 型
-
array
17.1.29. .spec.exporters[]
- 説明
-
FlowCollectorExporterは、エンリッチされたフローを送信する追加のエクスポーターを定義します。 - 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| エンリッチされた IPFIX フローの送信先の IP アドレスやポートなどの IPFIX 設定。 |
|
|
| エンリッチされたフローの送信先のアドレスやトピックなどの Kafka 設定。 |
|
|
| エンリッチされたログやメトリクスの送信先の IP アドレスやポートなどの OpenTelemetry 設定。 |
|
|
|
|
17.1.30. .spec.exporters[].ipfix
- 説明
- エンリッチされた IPFIX フローの送信先の IP アドレスやポートなどの IPFIX 設定。
- 型
-
object - 必須
-
エンタープライズ ID -
targetHost -
targetPort
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 企業 ID、または民間企業番号 (PEN)。現在、ネットワークオブザーバビリティーには割り当て番号がないため、設定のために空いた状態になっています。PEN は、Kubernetes 名、RTT などの非標準データを収集するために必要です。 |
|
|
| IPFIX 外部レシーバーのアドレス。 |
|
|
| IPFIX 外部レシーバー用のポート。 |
|
|
|
IPFIX 接続に使用されるトランスポートプロトコル ( |
17.1.31. .spec.exporters[].kafka
- 説明
- エンリッチされたフローの送信先のアドレスやトピックなどの Kafka 設定。
- 型
-
object - 必須
-
address -
topic
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Kafka サーバーのアドレス |
|
|
| SASL 認証の設定。[サポート対象外 (*)]。 |
|
|
| TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。 |
|
|
| 使用する Kafka トピック。これは必ず存在する必要があります。Network Observability はこれを作成しません。 |
17.1.32. .spec.exporters[].kafka.sasl
- 説明
- SASL 認証の設定。[サポート対象外 (*)]。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| クライアント ID を含むシークレットまたは config map への参照 |
|
|
| クライアントシークレットを含むシークレットまたは config map への参照 |
|
|
|
使用する SASL 認証のタイプ。SASL を使用しない場合は |
17.1.33. .spec.exporters[].kafka.sasl.clientIDReference
- 説明
- クライアント ID を含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.34. .spec.exporters[].kafka.sasl.clientSecretReference
- 説明
- クライアントシークレットを含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.35. .spec.exporters[].kafka.tls
- 説明
- TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.36. .spec.exporters[].kafka.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.37. .spec.exporters[].kafka.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.38. .spec.exporters[].openTelemetry
- 説明
- エンリッチされたログやメトリクスの送信先の IP アドレスやポートなどの OpenTelemetry 設定。
- 型
-
object - 必須
-
targetHost -
targetPort
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| OpenTelemetry 準拠の形式にマッピングされるカスタムフィールド。デフォルトでは、Network Observability の形式の提案 (https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal) が使用されます。L3 または L4 エンリッチ化ネットワークログは、現在、受け入れられている標準が存在しないため、デフォルトを独自の形式で自由にオーバーライドできます。 |
|
|
| メッセージに追加するヘッダー (任意)。 |
|
|
| ログの OpenTelemetry 設定。 |
|
|
| メトリクスの OpenTelemetry 設定。 |
|
|
|
OpenTelemetry 接続のプロトコル。使用可能なオプションは |
|
|
| OpenTelemetry レシーバーのアドレス。 |
|
|
| OpenTelemetry レシーバーのポート。 |
|
|
| TLS クライアント設定。 |
17.1.39. .spec.exporters[].openTelemetry.fieldsMapping
- 説明
- OpenTelemetry 準拠の形式にマッピングされるカスタムフィールド。デフォルトでは、Network Observability の形式の提案 (https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal) が使用されます。L3 または L4 エンリッチ化ネットワークログは、現在、受け入れられている標準が存在しないため、デフォルトを独自の形式で自由にオーバーライドできます。
- 型
-
array
17.1.40. .spec.exporters[].openTelemetry.fieldsMapping[]
- 説明
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| |
|
|
| |
|
|
|
17.1.41. .spec.exporters[].openTelemetry.logs
- 説明
- ログの OpenTelemetry 設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
ログを OpenTelemetry レシーバーに送信するには、 |
17.1.42. .spec.exporters[].openTelemetry.metrics
- 説明
- メトリクスの OpenTelemetry 設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
メトリクスを OpenTelemetry レシーバーに送信するには、 |
|
|
| メトリクスをコレクターに送信する頻度を指定します。 |
17.1.43. .spec.exporters[].openTelemetry.tls
- 説明
- TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.44. .spec.exporters[].openTelemetry.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.45. .spec.exporters[].openTelemetry.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.46. .spec.kafka
- 説明
-
Kafka 設定。Kafka をフローコレクションパイプラインの一部としてブローカーとして使用できます。この設定を利用できるのは、
spec.deploymentModelがKafkaの場合です。 - 型
-
object - 必須
-
address -
topic
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Kafka サーバーのアドレス |
|
|
| SASL 認証の設定。[サポート対象外 (*)]。 |
|
|
| TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。 |
|
|
| 使用する Kafka トピック。これは必ず存在する必要があります。Network Observability はこれを作成しません。 |
17.1.47. .spec.kafka.sasl
- 説明
- SASL 認証の設定。[サポート対象外 (*)]。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| クライアント ID を含むシークレットまたは config map への参照 |
|
|
| クライアントシークレットを含むシークレットまたは config map への参照 |
|
|
|
使用する SASL 認証のタイプ。SASL を使用しない場合は |
17.1.48. .spec.kafka.sasl.clientIDReference
- 説明
- クライアント ID を含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.49. .spec.kafka.sasl.clientSecretReference
- 説明
- クライアントシークレットを含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.50. .spec.kafka.tls
- 説明
- TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.51. .spec.kafka.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.52. .spec.kafka.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.53. .spec.loki
- 説明
-
loki(フローストア) のクライアント設定。 - 型
-
object - 必須
-
mode
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
Loki にフローを保存するには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Loki が Loki Operator を使用して管理されている場合は、
- Loki がモノリシックなワークロードとしてインストールされている場合は、
- Loki がマイクロサービスとしてインストールされているが、Loki Operator がない場合は、
- 上記のオプションが、いずれもお使いのセットアップに合わない場合は、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.54. .spec.loki.advanced
- 説明
-
advancedを使用すると、Loki クライアントの内部設定のいくつかの側面を設定できます。このセクションは、デバッグと詳細なパフォーマンスの最適化を主な目的としています。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.55. .spec.loki.lokiStack
- 説明
-
LokiStackモードの Loki 設定。これは、Loki Operator を簡単に設定するのに役立ちます。他のモードでは無視されます。 - 型
-
object - 必須
-
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 使用する既存の LokiStack リソースの名前。 |
|
|
|
この |
17.1.56. .spec.loki.manual
- 説明
-
Manualモードの Loki 設定。これは最も柔軟な設定です。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
-
-
-
Loki Operator を使用する場合、 |
|
|
|
|
|
|
|
|
|
|
| Loki ステータス URL の TLS クライアント設定。 |
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
17.1.57. .spec.loki.manual.statusTls
- 説明
- Loki ステータス URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.58. .spec.loki.manual.statusTls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.59. .spec.loki.manual.statusTls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.60. .spec.loki.manual.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.61. .spec.loki.manual.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.62. .spec.loki.manual.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.63. .spec.loki.microservices
- 説明
-
Microservicesモードの Loki 設定。このオプションは、Loki がマイクロサービスデプロイメントモード (https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode) を使用してインストールされている場合に使用します。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
17.1.64. .spec.loki.microservices.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.65. .spec.loki.microservices.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.66. .spec.loki.microservices.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.67. .spec.loki.monolithic
- 説明
-
Monolithicモードの Loki 設定。このオプションは、Loki がモノリシックデプロイメントモード (https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode) を使用してインストールされている場合に使用します。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
|
|
|
|
17.1.68. .spec.loki.monolithic.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.69. .spec.loki.monolithic.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.70. .spec.loki.monolithic.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.71. .spec.networkPolicy
- 説明
-
networkPolicyは、Network Observability のコンポーネントを分離するためのネットワークポリシー設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| ネットワークオブザーバビリティーで使用される namespace (メインおよび特権付き) にネットワークポリシーをデプロイします。このネットワークポリシーにより、ネットワークオブザーバビリティーコンポーネントが適切に分離され、コンポーネントとの不要な接続が防止されます。OVNKubernetes で使用する場合、このオプションはデフォルトで有効になっており、それ以外の場合は無効になっています (他の CNI ではテストされていません)。無効になっている場合、ネットワークオブザーバビリティーコンポーネントのネットワークポリシーを手動で作成できます。 |
17.1.72. .spec.processor
- 説明
-
processorは、エージェントからフローを受信してエンリッチし、メトリクスを生成して Loki 永続化レイヤーや利用可能なエクスポーターに転送するコンポーネントの設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
プロセッサーランタイムの |
|
|
|
- 通常のネットワークフローをエクスポートする場合は
-
-
- |
|
|
|
|
|
|
|
マルチクラスター機能を有効にするには、 |
|
|
|
|
|
|
| FlowCollectorSlices のカスタムリソースを管理するグローバル設定。 |
|
|
|
|
|
|
|
|
17.1.73. .spec.processor.advanced
- 説明
-
advancedを使用すると、フロープロセッサーの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| フローコレクターのポート (ホストポート)。慣例により、一部の値は禁止されています。1024 より大きい値とし、4500、4789、6081 は使用できません。 |
|
|
|
|
|
|
| scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。 |
|
|
| リソース識別のためにチェックするセカンダリーネットワークを定義します。正確な識別を確実に行うために、インデックス値からクラスター全体で一意の識別子が形成されるようにする必要があります。同じインデックスが複数のリソースで使用されている場合、それらのリソースに誤ったラベルが付けられる可能性があります。 |
17.1.74. .spec.processor.advanced.scheduling
- 説明
- scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.75. .spec.processor.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.76. .spec.processor.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.77. .spec.processor.advanced.secondaryNetworks
- 説明
- リソース識別のためにチェックするセカンダリーネットワークを定義します。正確な識別を確実に行うために、インデックス値からクラスター全体で一意の識別子が形成されるようにする必要があります。同じインデックスが複数のリソースで使用されている場合、それらのリソースに誤ったラベルが付けられる可能性があります。
- 型
-
array
17.1.78. .spec.processor.advanced.secondaryNetworks[]
- 説明
- 型
-
object - 必須
-
index -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.79. .spec.processor.deduper
- 説明
-
deduperを使用すると、重複として識別されたフローをサンプリングまたはドロップして、リソース使用量を節約できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
プロセッサーの重複排除モードを設定します。エージェントは別々のノードから報告された同じフローを重複排除できないため、これはエージェントベースの重複排除に加えて設定されます。
-
- 重複と見なされる 50 (デフォルト) のフローのうち 1 つだけランダムに保持するには、
- プロセッサーベースの重複排除をオフにするには、 |
|
|
|
|
17.1.80. .spec.processor.filters
- 説明
-
filtersを使用すると、生成されるフローの量を制限するカスタムフィルターを定義できます。これらのフィルターは、Kubernetes namespace によるフィルター処理などを含め、eBPF エージェントフィルター (spec.agent.ebpf.flowFilter内) よりも柔軟性が高くなりますが、パフォーマンスの向上は少なくなります。 - 型
-
array
17.1.81. .spec.processor.filters[]
- 説明
-
FLPFilterSetは、すべての条件を満たす FLP ベースのフィルタリングに必要な設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
指定されている場合、これらのフィルターのターゲットが、1 つの出力 ( |
|
|
| 保存するネットワークフローを選択するクエリー。このクエリー言語の詳細は、https://github.com/netobserv/flowlogs-pipeline/blob/main/docs/filtering.md を参照してください。 |
|
|
|
|
17.1.82. .spec.processor.kafkaConsumerAutoscaler
- 説明
-
kafkaConsumerAutoscaler[非推奨 (*)] は、Kafka メッセージを処理するflowlogs-pipeline-transformer用にセットアップする水平 Pod オートスケーラーの仕様です。Kafka が無効になっている場合、この設定は無視されます。非推奨のお知らせ: マネージドオートスケーラーは将来のバージョンで削除されます。代わりに、お好みのオートスケーラーを設定し、spec.processor.unmanagedReplicasをtrueに設定することもできます。HorizontalPodAutoscaler のドキュメント (自動スケーリング/v2) を参照してください。 - 型
-
object
17.1.83. .spec.processor.metrics
- 説明
-
Metricsは、メトリクスに関するプロセッサー設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Prometheus スクレイパーのメトリクスサーバーエンドポイント設定 |
17.1.84. .spec.processor.metrics.healthRules
- 説明
-
healthRules は、Prometheus 用に作成されるヘルスルールのリストであり、テンプレートとバリアントごとに整理されています。各ヘルスルールは、モードフィールドに基づいて、アラートまたは記録ルールのいずれかを生成するように設定できます。ヘルスルールに関する詳細情報: https://github.com/netobserv/network- オブザーバビリティー -operator/blob/main/docs/HealthRules.md - 型
-
array
17.1.85. .spec.processor.metrics.healthRules[]
- 説明
- 型
-
object - 必須
-
template -
variants
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
モードは、このヘルスルールをアラートとして生成するか、記録ルールとして生成するかを定義します。指定可能な値は、 |
|
|
|
健康ルールテンプレート名。指定可能な値は、 |
|
|
| このテンプレートのバリアントのリスト |
17.1.86. .spec.processor.metrics.healthRules[].variants
- 説明
- このテンプレートのバリアントのリスト
- 型
-
array
17.1.87. .spec.processor.metrics.healthRules[].variants[]
- 説明
- 型
-
object - 必須
-
thresholds
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
オプションのグループ化基準。指定可能な値は、 |
|
|
| 低ボリュームしきい値を使用すると、S/N 比を改善するために、トラフィック量が少なすぎるメトリクスを無視できます。これは絶対レート (コンテキストに応じて、1 秒あたりのバイト数または 1 秒あたりのパケット数) の形で指定します。指定した場合、浮動小数点数として解析可能である必要があります。 |
|
|
|
このモードは、この特定のバリアントの健康ルールモードを上書きします。指定されていない場合は、親ヘルスルールのモードを継承します。指定可能な値は、 |
|
|
| 重症度ごとの健康ルールの閾値。これらの値は、アラートがトリガーされる基準となるエラーのパーセンテージとして表されます。浮動小数点数として解析可能である必要があります。アラートモードと録画モードの両方に必要 |
|
|
| トレンド健康ルールの場合、基準値との比較のための期間間隔。たとえば、"2h" は 2 時間の平均と比較することを意味します。デフォルトは 2h です。 |
|
|
| トレンド分析の健康ルールについては、基準値との比較のための時間オフセットを設定します。たとえば、"1d" は昨日と比較することを意味します。デフォルトは 1d です。 |
17.1.88. .spec.processor.metrics.healthRules[].variants[].thresholds
- 説明
- 重症度ごとの健康ルールの閾値。これらの値は、アラートがトリガーされる基準となるエラーのパーセンテージとして表されます。浮動小数点数として解析可能である必要があります。アラートモードと録画モードの両方に必要
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
重大度 |
|
|
|
重大度 |
|
|
|
重大度 |
17.1.89. .spec.processor.metrics.server
- 説明
- Prometheus スクレイパーのメトリクスサーバーエンドポイント設定
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| メトリクスサーバーの HTTP ポート。 |
|
|
| TLS 設定。 |
17.1.90. .spec.processor.metrics.server.tls
- 説明
- TLS 設定。
- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TLS 設定のタイプを選択します。
- |
17.1.91. .spec.processor.metrics.server.tls.provided
- 説明
-
typeがProvidedに設定されている場合の TLS 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.92. .spec.processor.metrics.server.tls.providedCaFile
- 説明
-
typeがProvidedに設定されている場合の CA ファイルへの参照。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.93. .spec.processor.resources
- 説明
-
resourcesは、このコンテナーが必要とするコンピューティングリソースです。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで Requests が省略される場合、明示的に指定される場合にデフォルトで Limits に設定されます。指定しない場合は、実装定義の値に設定されます。リクエストは制限を超えることはできません。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
17.1.94. .spec.processor.slicesConfig
- 説明
- FlowCollectorSlices のカスタムリソースを管理するグローバル設定。
- 型
-
object - 必須
-
enable
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
-
- |
|
|
|
|
|
|
|
|
17.1.95. .spec.processor.subnetLabels
- 説明
-
subnetLabels を使用すると、サブネットや IP アドレスにカスタムラベルを定義したり、OpenShift Container Platform で認識されたサブネットの自動ラベル付けを有効にしたりできます。これは、クラスターの外部トラフィックを識別するために使用されます。サブネットがフローの送信元 IP または宛先 IP と一致する場合、対応するフィールドSrcSubnetLabelまたはDstSubnetLabelが追加されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.96. .spec.processor.subnetLabels.customLabels
- 説明
customLabels を使用すると、サブネットや IP アドレスのラベル付けをカスタマイズして、クラスター外部のワークロードや Web サービスを識別することができます。デフォルトのクイックフィルターや提供されているメトリクス例を使用するには、外部サブネットにはEXT:という接頭辞を付けるか、ラベルを付けないかのどちらかにする必要があります。
openShiftAutoDetect が無効になっている場合、または OpenShift Container Platform を使用していない場合は、内部トラフィックと外部トラフィックを区別するために、クラスターサブネットのラベルを手動で設定することを推奨します。
openShiftAutoDetectが有効になっている場合、customLabels は検出されたサブネットが重複する場合に、検出されたサブネットを上書きします。
- 型
-
array
17.1.97. .spec.processor.subnetLabels.customLabels[]
- 説明
- SubnetLabel を使用すると、クラスター外部のワークロードや Web サービスの識別などのために、サブネットと IP にラベルを付けることができます。
- 型
-
object - 必須
-
cidrs -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
マッチしたフローにフラグを設定するために使用するラベル名。デフォルトのクイックフィルターや提供されているメトリクス例を使用するには、外部サブネットには |
17.1.98. .spec.prometheus
- 説明
-
prometheusは、コンソールプラグインからメトリクスを取得するために使用されるクエリー設定などの Prometheus 設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| コンソールプラグインで使用される、クライアント設定などの Prometheus クエリー設定。 |
17.1.99. .spec.prometheus.querier
- 説明
- コンソールプラグインで使用される、クライアント設定などの Prometheus クエリー設定。
- 型
-
object - 必須
-
mode
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
- 自動設定を試行するには、
手動で設定する場合は、 |
|
|
|
|
17.1.100. .spec.prometheus.querier.manual
- 説明
-
Manualモードの Prometheus 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| AlertManager の設定。これはコンソールで、ミュートされたアラートを照会し、健康情報を表示するために使用されます。OpenShift Container Platform で使用する場合、コンソール API を使用するために空欄のままにしておくことができます。[サポートされていません (*)] |
|
|
|
ログインしたユーザートークンをクエリーで Prometheus に転送するには、 |
|
|
| Prometheus URL の TLS クライアント設定。 |
|
|
|
|
17.1.101. .spec.prometheus.querier.manual.alertManager
- 説明
- AlertManager の設定。これはコンソールで、ミュートされたアラートを照会し、健康情報を表示するために使用されます。OpenShift Container Platform で使用する場合、コンソール API を使用するために空欄のままにしておくことができます。[サポートされていません (*)]
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Prometheus AlertManager URL の TLS クライアント設定。 |
|
|
|
|
17.1.102. .spec.prometheus.querier.manual.alertManager.tls
- 説明
- Prometheus AlertManager URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.103. .spec.prometheus.querier.manual.alertManager.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.104. .spec.prometheus.querier.manual.alertManager.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.105. .spec.prometheus.querier.manual.tls
- 説明
- Prometheus URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.106. .spec.prometheus.querier.manual.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.107. .spec.prometheus.querier.manual.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
第18章 FlowMetric 設定パラメーター
FlowMetric API は、収集されたネットワークフローログからカスタムの可観測性メトリクスを生成するために使用されます。
18.1. FlowMetric [flows.netobserv.io/v1alpha1]
- 説明
- FlowMetric は、収集されたフローログからカスタムメトリクスを作成することを可能にする API です。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds を参照してください。 |
|
|
| 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。 |
|
|
|
FlowMetricSpec は、FlowMetric の目的の状態を定義します。提供されている API を使用すると、ニーズに応じてこれらのメトリクスをカスタマイズできます。
新しいメトリクスを追加したり、既存のラベルを変更したりする場合は、大きな影響を与える可能性があります。そのため、Prometheus ワークロードのメモリー使用量を注意深く監視する必要があります。https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric
すべての Network Observability メトリクスのカーディナリティーを確認するには、 |
18.1.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
18.1.2. .spec
- 説明
FlowMetricSpec は、FlowMetric の目的の状態を定義します。提供されている API を使用すると、ニーズに応じてこれらのメトリクスをカスタマイズできます。
新しいメトリクスを追加したり、既存のラベルを変更したりする場合は、大きな影響を与える可能性があります。そのため、Prometheus ワークロードのメモリー使用量を注意深く監視する必要があります。https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric
を参照してください。すべての Network Observability メトリクスのカーディナリティーを確認するには、
promql:count({name=~"netobserv.*"}) by (name)を実行します。- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| 管理者ビューの Dashboards メニューにある OpenShift Container Platform コンソールのチャート設定。 |
|
|
|
Ingress、Egress、または任意の方向のフローをフィルタリングします。 |
|
|
| ゼロ以外の場合、値の換算係数 (除数)。メトリクス値 = フロー値/除数。 |
|
|
|
|
|
|
|
|
|
|
| Prometheus に表示される、メトリクスのヘルプテキスト。 |
|
|
|
|
|
|
|
メトリクスの名前。Prometheus では、自動的に "netobserv_" という接頭辞が付けられます。 |
|
|
|
生成されるメトリクスラベルにフローフィールドとは異なる名前を使用するには、 |
|
|
| メトリクスタイプ: "Counter"、"Histogram"、または"Gauge"。"Counter" は、バイト数やパケット数など、時間の経過とともに増加し、レートを計算できる値に使用します。"Histogram" は、遅延など、個別にサンプリングする必要がある値に使用します。"Gauge" は、経時的な正確さが必要がないその他の値に使用します (ゲージは、Prometheus がメトリクスを取得するときに N 秒ごとにのみサンプリングされます)。 |
|
|
|
|
18.1.3. .spec.charts
- 説明
- 管理者ビューの Dashboards メニューにある OpenShift Container Platform コンソールのチャート設定。
- 型
-
array
18.1.4. .spec.charts[]
- 説明
- メトリクスに関連するグラフ/ダッシュボード生成を設定します。
- 型
-
object - 必須
-
dashboardName -
queries -
title -
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 配置先のダッシュボードの名前。この名前が既存のダッシュボードを示すものでない場合は、新しいダッシュボードが作成されます。 |
|
|
|
このグラフに表示するクエリーのリスト。 |
|
|
|
配置先のダッシュボードセクションの名前。この名前が既存のセクションを示すものでない場合は、新しいセクションが作成されます。 |
|
|
| グラフのタイトル。 |
|
|
| グラフの種類。 |
|
|
| このグラフの単位。現在サポートされている単位はごく少数です。一般的な数字を使用する場合は空白のままにします。 |
18.1.5. .spec.charts[].queries
- 説明
-
このグラフに表示するクエリーのリスト。
typeがSingleStatで、複数のクエリーが指定されている場合、このグラフは複数のパネル (クエリーごとに 1 つ) に自動的に展開されます。 - 型
-
array
18.1.6. .spec.charts[].queries[]
- 説明
- PromQL クエリーを設定します。
- 型
-
object - 必須
-
legend -
promQL -
top
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
このグラフに表示する各時系列に適用するクエリーの凡例。複数の時系列を表示する場合は、それぞれを区別する凡例を設定する必要があります。これは |
|
|
|
Prometheus に対して実行する |
|
|
|
タイムスタンプごとに表示する上位 N 個の系列。 |
18.1.7. .spec.filters
- 説明
-
filtersは、考慮されるフローを制限するために使用するフィールドと値のリストです。使用可能なフィールドのリストは、ドキュメント https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference を参照してください。 - 型
-
array
18.1.8. .spec.filters[]
- 説明
- 型
-
object - 必須
-
field -
matchType
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
フィルタリングするフィールドの名前 (例: |
|
|
| 適用するマッチングのタイプ |
|
|
|
フィルタリングする値。 |
第19章 ネットワークフロー形式のリファレンス
ネットワークフロー形式の仕様をご確認ください。この仕様は、フローデータを Kafka にエクスポートするために内部的に使用されます。
19.1. ネットワークフロー形式のリファレンス
これはネットワークフロー形式の仕様です。この形式は、Prometheus メトリクスラベルに、および内部で Loki ストアに Kafka エクスポーターが設定されているときに使用されます。
"フィルター ID" 列は、クイックフィルターを定義するときに使用する関連名を示します (FlowCollector 仕様の spec.consolePlugin.quickFilters を参照)。
"Loki ラベル" 列は、Loki に直接クエリーを実行する場合に役立ちます。ラベルフィールドは、stream selectors を使用して選択する必要があります。
"カーディナリティー" 列は、このフィールドが FlowMetrics API で Prometheus ラベルとして使用される場合の暗黙のメトリクスカーディナリティーに関する情報を示します。この API の使用に関する詳細は、FlowMetrics のドキュメントを参照してください。
| 名前 | 型 | 説明 | フィルター ID | Loki ラベル | カーディナリティー | OpenTelemetry |
|---|---|---|---|---|---|---|
|
| number | バイト数 | 該当なし | いいえ | avoid | bytes |
|
| number | DNS トラッカーの ebpf フック関数から返されたエラー番号 |
| いいえ | fine | dns.errno |
|
| number | DNS レコードの DNS フラグ | 該当なし | いいえ | fine | dns.flags |
|
| string | 解析された DNS ヘッダーの RCODEs 名 |
| いいえ | fine | dns.responsecode |
|
| number | DNS レコード id |
| いいえ | avoid | dns.id |
|
| number | DNS リクエストとレスポンスの間の時間 (ミリ秒単位) |
| いいえ | avoid | dns.latency |
|
| string | DNS クエリー名 |
| いいえ | careful | 該当なし |
|
| number | Differentiated Services Code Point (DSCP) の値 |
| いいえ | fine | dscp |
|
| string | 宛先 IP アドレス (ipv4 または ipv6) |
| いいえ | avoid | destination.address |
|
| string | 送信先ノード IP |
| いいえ | fine | destination.k8s.host.address |
|
| string | 送信先ノード名 |
| いいえ | fine | destination.k8s.host.name |
|
| string | 宛先 Kubernetes オブジェクトの名前 (Pod 名、Service 名、Node 名など)。 |
| いいえ | careful | destination.k8s.name |
|
| string | 宛先 namespace |
| はい | fine | destination.k8s.namespace.name |
|
| string | 宛先ネットワーク名 |
| いいえ | fine | 該当なし |
|
| string | 宛先所有者の名前 (Deployment 名、StatefulSet 名など)。 |
| はい | fine | destination.k8s.owner.name |
|
| string | 宛先所有者の種類 (Deployment、StatefulSet など)。 |
| いいえ | fine | destination.k8s.owner.kind |
|
| string | 宛先 Kubernetes オブジェクトの種類 (Pod、Service、Node など)。 |
| はい | fine | destination.k8s.kind |
|
| string | 宛先アベイラビリティーゾーン |
| はい | fine | destination.zone |
|
| string | 宛先 MAC アドレス |
| いいえ | avoid | destination.mac |
|
| number | 送信先ポート |
| いいえ | careful | destination.port |
|
| string | 宛先サブネットラベル |
| いいえ | fine | destination.subnet.label |
|
| string[] |
RFC-9293 に基づく、フローに含まれる TCP フラグのリスト。パケットごとの組み合わせ ( |
| いいえ | careful | tcp.flags |
|
| number |
ノード観測点から解釈されたフローの方向。次のいずれかになります。 |
| はい | fine | host.direction |
|
| string | IPsec 暗号化のステータス (Egress 時、カーネルの xfrm_output 関数によって指定) または復号化のステータス (Ingress 時、xfrm_input 経由) |
| いいえ | fine | 該当なし |
|
| number | ICMP コード |
| いいえ | fine | icmp.code |
|
| number | ICMP のタイプ |
| いいえ | fine | icmp.type |
|
| number[] |
ネットワークインターフェイス観測点からのフローの方向。次のいずれかになります。 |
| いいえ | fine | interface.directions |
|
| string[] | ネットワークインターフェイス |
| いいえ | careful | interface.names |
|
| string | クラスター名またはクラスター識別子 |
| はい | fine | k8s.cluster.name |
|
| string | フローのレイヤー: 'app' または 'infra' |
| はい | fine | k8s.layer |
|
| object[] |
ネストされたフィールドで構成されるネットワークポリシーアクションなどのネットワークイベント: |
| いいえ | avoid | 該当なし |
|
| number | パケット数 | 該当なし | いいえ | avoid | packets |
|
| number | カーネルによってドロップされたバイト数 | 該当なし | いいえ | avoid | drops.bytes |
|
| string | 最新のドロップの原因 |
| いいえ | fine | drops.latestcause |
|
| number | 最後にドロップされたパケットの TCP フラグ | 該当なし | いいえ | fine | drops.latestflags |
|
| string | 最後にドロップされたパケットの TCP 状態 |
| いいえ | fine | drops.lateststate |
|
| number | カーネルによってドロップされたパケットの数 | 該当なし | いいえ | avoid | drops.packets |
|
| number | L4 プロトコル |
| いいえ | fine | protocol |
|
| number | このフローで使用されるサンプリング間隔 | 該当なし | いいえ | fine | 該当なし |
|
| string | 送信元 IP アドレス (ipv4 または ipv6) |
| いいえ | avoid | source.address |
|
| string | 送信元ノード IP |
| いいえ | fine | source.k8s.host.address |
|
| string | 送信元ノード名 |
| いいえ | fine | source.k8s.host.name |
|
| string | 送信元 Kubernetes オブジェクトの名前 (Pod 名、サービス名、ノード名など) |
| いいえ | careful | source.k8s.name |
|
| string | 送信元 namespace |
| はい | fine | source.k8s.namespace.name |
|
| string | 送信元ネットワーク名 |
| いいえ | fine | 該当なし |
|
| string | 送信元所有者の名前 (Deployment 名、StatefulSet 名など)。 |
| はい | fine | source.k8s.owner.name |
|
| string | 送信元所有者の種類 (Deployment、StatefulSet など)。 |
| いいえ | fine | source.k8s.owner.kind |
|
| string | 送信元 Kubernetes オブジェクトの種類 (Pod、Service、Node など)。 |
| はい | fine | source.k8s.kind |
|
| string | 送信元アベイラビリティーゾーン |
| はい | fine | source.zone |
|
| string | 送信元 MAC アドレス |
| いいえ | avoid | source.mac |
|
| number | 送信元ポート |
| いいえ | careful | source.port |
|
| string | 送信元サブネットラベル |
| いいえ | fine | source.subnet.label |
|
| number | このフローの終了タイムスタンプ (ミリ秒単位) | 該当なし | いいえ | avoid | timeflowend |
|
| number | TCP の平滑化されたラウンドトリップタイム (SRTT) (ナノ秒単位) |
| いいえ | avoid | tcp.rtt |
|
| number | このフローの開始タイムスタンプ (ミリ秒単位) | 該当なし | いいえ | avoid | timeflowstart |
|
| number | このフローがフローコレクターによって受信および処理されたときのタイムスタンプ (秒単位) | 該当なし | いいえ | avoid | timereceived |
|
| string[] | ユーザー定義ネットワークのリスト |
| いいえ | careful | 該当なし |
|
| string | パケット変換の送信先アドレス |
| いいえ | avoid | 該当なし |
|
| number | パケット変換の送信先ポート |
| いいえ | careful | 該当なし |
|
| string | パケット変換の送信元アドレス |
| いいえ | avoid | 該当なし |
|
| number | パケット変換の送信元ポート |
| いいえ | careful | 該当なし |
|
| number | パケット変換のゾーン ID |
| いいえ | avoid | 該当なし |
|
| string | 会話追跡では、会話識別子 |
| いいえ | avoid | 該当なし |
|
| string |
レコードの種類: 通常のフローログの場合は |
| はい | fine | 該当なし |
第20章 Network Observability のトラブルシューティング
Network Observability Operator とそのコンポーネントに関連する一般的な問題をトラブルシューティングするための診断アクションを実行します。
20.1. must-gather ツールの使用
must-gather ツールを使用して、Pod ログや設定の詳細など、Network Observability Operator リソースに関する診断情報を収集し、クラスターの問題のトラブルシューティングに役立ててください。
手順
- must-gather データを保存するディレクトリーに移動します。
次のコマンドを実行して、クラスター全体の must-gather リソースを収集します。
$ oc adm must-gather --image-stream=openshift/must-gather \ --image=quay.io/netobserv/must-gather
20.2. OpenShift Container Platform コンソールでのネットワークトラフィックメニューエントリーの設定
OpenShift Container Platform コンソールの 監視 メニューに欠落しているネットワークトラフィックメニューエントリーを復元するには、FlowCollector リソースとコンソールオペレーター設定にコンソールプラグインを手動で登録します。
前提条件
- OpenShift Container Platform バージョン 4.10 以降がインストールされている。
手順
次のコマンドを実行して、
spec.consolePlugin.registerフィールドがtrueに設定されているかどうかを確認します。$ oc -n netobserv get flowcollector cluster -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: consolePlugin: register: falseオプション: Console Operator 設定を手動で編集して、
netobserv-pluginプラグインを追加します。$ oc edit console.operator.openshift.io cluster出力例
... spec: plugins: - netobserv-plugin ...オプション: 次のコマンドを実行して、
spec.consolePlugin.registerフィールドをtrueに設定します。$ oc -n netobserv edit flowcollector cluster -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: consolePlugin: register: true次のコマンドを実行して、コンソール Pod のステータスが
runningであることを確認します。$ oc get pods -n openshift-console -l app=console次のコマンドを実行して、コンソール Pod を再起動します。
$ oc delete pods -n openshift-console -l app=console- ブラウザーのキャッシュと履歴をクリアします。
次のコマンドを実行して、Network Observability プラグイン Pod のステータスを確認します。
$ oc get pods -n netobserv -l app=netobserv-plugin出力例
NAME READY STATUS RESTARTS AGE netobserv-plugin-68c7bbb9bb-b69q6 1/1 Running 0 21s次のコマンドを実行して、Network Observability プラグイン Pod のログを確認します。
$ oc logs -n netobserv -l app=netobserv-plugin出力例
time="2022-12-13T12:06:49Z" level=info msg="Starting netobserv-console-plugin [build version: , build date: 2022-10-21 15:15] at log level info" module=main time="2022-12-13T12:06:49Z" level=info msg="listening on https://:9001" module=server
20.3. Kafka をインストールした後、Flowlogs-Pipeline がネットワークフローを消費しない
フローパイプラインが Kafka からのネットワークフローを消費できない場合は、フローパイプラインの Pod を手動で再起動して、フローコレクターと Kafka デプロイメント間の接続を復元することで問題を解決します。
最初に deploymentModel: KAFKA を使用してフローコレクターをデプロイし、次に Kafka をデプロイした場合、フローコレクターが Kafka に正しく接続されない可能性があります。Flowlogs-pipeline が Kafka からのネットワークフローを消費しないフローパイプライン Pod を手動で再起動します。
手順
次のコマンドを実行して、flow-pipeline Pod を削除して再起動します。
$ oc delete pods -n netobserv -l app=flowlogs-pipeline-transformer
20.4. br-int インターフェイスと br-ex インターフェイスの両方からのネットワークフローが表示されない
br-int や br-ex などの仮想ブリッジデバイスのインターフェイス制限を解除することで、ネットワークフローが欠落している問題を解決し、eBPF エージェントが適切なレイヤ 3 インターフェイスに接続できるようにします。
br-ex と br-int は、OSI レイヤー 2 で動作する仮想ブリッジデバイスです。eBPF エージェントは、IP レベルと TCP レベル、それぞれレイヤー 3 と 4 で動作します。ネットワークトラフィックが物理ホストや仮想 Pod インターフェイスなどの他のインターフェイスによって処理される場合、eBPF エージェントは br-ex および br-int を通過するネットワークトラフィックをキャプチャすることが期待できます。eBPF エージェントのネットワークインターフェイスを br-ex および br-int のみに接続するように制限すると、ネットワークフローは表示されません。
ネットワークインターフェイスを br-int および br-ex に制限する interfaces または excludeInterfaces の部分を手動で削除します。
手順
interfaces: [ 'br-int', 'br-ex' ]フィールド。これにより、エージェントはすべてのインターフェイスから情報を取得できます。または、レイヤー 3 インターフェイス (例:eth0) を指定することもできます。以下のコマンドを実行します。$ oc edit -n netobserv flowcollector.yaml -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: agent: type: EBPF ebpf: interfaces: [ 'br-int', 'br-ex' ]1 - 1
- ネットワークインターフェイスを指定します。
20.5. Network Observability コントローラーマネージャー Pod のメモリーが不足する
Network Observability Operator のメモリー問題を解決するには、サブスクリプション オブジェクトのメモリー制限を増やして、コントローラーマネージャー Pod のメモリー不足を防いでください。
Subscription オブジェクトの spec.config.resources.limits.memory 仕様を編集することで、Network Observability Operator のメモリー制限を引き上げることができます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability をクリックし、Subscription を選択します。
Actions メニューから、Edit Subscription をクリックします。
または、CLI を使用して次のコマンドを実行して、
Subscriptionオブジェクトの YAML 設定を開くこともできます。$ oc edit subscription netobserv-operator -n openshift-netobserv-operator
Subscriptionオブジェクトを編集してconfig.resources.limits.memory仕様を追加し、メモリー要件を考慮して値を設定します。リソースに関する考慮事項の詳細は、関連情報を参照してください。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: netobserv-operator namespace: openshift-netobserv-operator spec: channel: stable config: resources: limits: memory: 800Mi1 requests: cpu: 100m memory: 100Mi installPlanApproval: Automatic name: netobserv-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: <network_observability_operator_latest_version>2
20.6. Loki へのカスタムクエリーの実行
コマンドラインインターフェイスを使用して、カスタム Loki クエリーを実行して利用可能なラベルを取得したり、ソース名前空間などの特定の基準でログをフィルタリングしたりすることで、ネットワークフローデータのトラブルシューティングを行います。
これを行う方法の例が 2 つあり、<api_token> を独自のものに置き換えることで、ニーズに合わせて調整できます。
これらの例では、Network Observability Operator および Loki デプロイメントに netobserv namespace を使用します。さらに、例では、LokiStack の名前が loki であると想定しています。オプションで、例 (具体的には -n netobserv または loki-gateway URL) を調整して、異なる namespace と命名を使用することもできます。
前提条件
- Network Observability Operator で使用するために、Loki Operator をインストールしました。
手順
利用可能なすべてのラベルを取得するには、次のコマンドを実行してください。
$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/labels | jqソースネームスペース
my-namespaceからすべてのフローを取得するには、次のコマンドを実行します。$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/query --data-urlencode 'query={SrcK8S_Namespace="my-namespace"}' | jq
20.7. Loki ResourceExhausted エラーのトラブルシューティング
Loki ResourceExhausted エラーを解決するには、FlowCollector リソースの batchSize を 調整するか、Loki 設定の最大メッセージサイズ設定を調整して、フローデータがメモリー制限内に収まるようにしてください。
Network Observability によって送信されたネットワークフローデータが、設定された最大メッセージサイズを超えると、Loki は ResourceExhausted エラーを返すことがあります。Red Hat Loki Operator を使用している場合、この最大メッセージサイズは 100 MiB に設定されています。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンメニューから All projects を表示します。
- Provided APIs リストで、Network Observability Operator を選択します。
Flow Collector をクリックし、YAML view タブをクリックします。
-
Loki Operator を使用している場合は、
spec.loki.batchSize値が 98 MiB を超えていないことを確認してください。 -
Red Hat Loki Operator とは異なる Loki インストール方法 (Grafana Loki など) を使用している場合は、Grafana Loki サーバー設定 の
grpc_server_max_recv_msg_sizeが、FlowCollectorリソースのspec.loki.batchSize値より大きいことを確認してください。大きくない場合は、grpc_server_max_recv_msg_size値を増やすか、spec.loki.batchSize値を制限値よりも小さくなるように減らす必要があります。
-
Loki Operator を使用している場合は、
- FlowCollector を編集した場合は、Save をクリックします。
20.8. Loki の empty ring エラー
Loki の空のリングエラーを調査して解決するには、Pod の状態を確認したり、古い永続ボリューム要求をクリアしたり、Pod を再起動して接続を復元し、ネットワークフローが適切に保存および表示されるようにします。
Loki の "empty ring" エラーにより、フローが Loki に保存されず、Web コンソールに表示されなくなります。このエラーはさまざまな状況で発生する可能性があります。これらすべてに対処できる 1 つの回避策はありません。Loki Pod 内のログを調査し、LokiStack が健全な状態で準備が整っていることを確認するために、いくつかのアクションを実行できます。
このエラーが発生する状況には次のようなものがあります。
LokiStackをアンインストールし、同じ namespace に再インストールすると、古い PVC が削除されないため、このエラーが発生する可能性があります。-
アクション:
LokiStackを再度削除し、PVC を削除してから、LokiStackの再インストールをお試しください。
-
アクション:
証明書のローテーション後、このエラーにより、
flowlogs-pipelinePod およびconsole-pluginPod との通信が妨げられる可能性があります。- アクション: Pod を再起動すると、接続を復元できます。
20.9. リソースのトラブルシューティング
20.10. LokiStack レート制限エラー
Loki のレート制限エラーを解決し、データ損失を防ぐには、LokiStack リソースを更新して、ネットワークオブザーバビリティーデータストリームの取り込みレートとバースト制限を引き上げてください。
Loki テナントにレート制限が設定されていると、データが一時的に失われ、429 エラー (Per stream rate limit exceeded (limit:xMB/sec) while attempting to ingest for stream) が発生する可能性があります。このエラーを通知するようにアラートを設定することを検討してください。詳細は、このセクションの関連情報として記載されている「NetObserv ダッシュボードの Loki レート制限アラートの作成」を参照してください。
次に示す手順を実行して、perStreamRateLimit および perStreamRateLimitBurst 仕様で LokiStack CRD を更新できます。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンから All projects を表示します。
- Loki Operator を見つけて、LokiStack タブを選択します。
YAML view を使用して LokiStack インスタンスを作成するか既存のものを編集し、
perStreamRateLimitおよびperStreamRateLimitBurst仕様を追加します。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: loki namespace: netobserv spec: limits: global: ingestion: perStreamRateLimit: 61 perStreamRateLimitBurst: 302 tenants: mode: openshift-network managementState: Managed- Save をクリックします。
検証
perStreamRateLimit および perStreamRateLimitBurst 仕様を更新すると、クラスター内の Pod が再起動し、429 レート制限エラーが発生しなくなります。
20.11. 大きなクエリーを実行すると Loki エラーが発生する
インデックス付きフィルターの使用、長期間にわたる Prometheus の活用、カスタムメトリクスの作成、Loki および FlowCollector のパフォーマンス設定の調整などにより、大規模なクエリーを実行する際に発生する Loki のタイムアウトやリクエストエラーを軽減する方法を理解しましょう。
大規模なクエリーを長時間実行すると、timeout や too many outstanding requests などの Loki エラーが発生する可能性があります。この問題を完全に修正する方法はありませんが、軽減する方法はいくつかあります。
- クエリーを調整してインデックス付きフィルターを追加する
-
Loki クエリーを使用すると、インデックスが付けられたフィールドまたはラベルと、インデックスが付けられていないフィールドまたはラベルの両方に対してクエリーを実行できます。ラベルにフィルターを含むクエリーのパフォーマンスが向上します。たとえば、インデックス付きフィールドではない特定の Pod をクエリーする場合は、その namespace をクエリーに追加できます。インデックス付きフィールドのリストは、"Network flows format reference" の
Loki label列にあります。 - Loki ではなく Prometheus にクエリーすることを検討する
- 長い時間範囲でクエリーを実行するには、Loki よりも Prometheus の方が適しています。ただし、Loki の代わりに Prometheus を使用できるかどうかは、ユースケースによって異なります。たとえば、Prometheus のクエリーは Loki よりもはるかに高速であり、時間範囲が長くてもパフォーマンスに影響はありません。しかし、Prometheus メトリクスには、Loki のフローログほど多くの情報は含まれていません。Network Observability OpenShift Web コンソールは、クエリーに互換性がある場合は、自動的に Loki よりも Prometheus を優先します。互換性がない場合は、デフォルトで Loki が使用されます。クエリーが Prometheus に対して実行されない場合は、いくつかのフィルターまたは集計を変更して切り替えることができます。OpenShift Web コンソールでは、Prometheus の使用を強制できます。互換性のないクエリーが失敗するとエラーメッセージが表示され、クエリーを互換性のあるものにするためにどのラベルを変更すればよいかを判断するのに役立ちます。たとえば、フィルターまたは集計を Resource または Pods から Owner に変更します。
- FlowMetrics API を使用して独自のメトリクスを作成することを検討する
- 必要なデータが Prometheus メトリクスとして利用できない場合は、FlowMetrics API を使用して独自のメトリクスを作成できます。詳細は、「FlowMetrics API リファレンス」および「FlowMetric API を使用したカスタムメトリクスの設定」を参照してください。
- クエリーパフォーマンスを向上させるために Loki を設定する
問題が解決しない場合は、クエリーのパフォーマンスを向上させるために Loki を設定することを検討してください。一部のオプションは、Operator と
LokiStackの使用、Monolithicモード、Microservicesモードなど、Loki に使用したインストールモードによって異なります。-
LokiStackまたはMicroservicesモードでは、クエリーレプリカの数を増やして みてください。 -
クエリーのタイムアウト を増やします。また、
FlowCollectorspec.loki.readTimeoutで、Loki への Network Observability の読み取りタイムアウトを増やす必要があります。
-
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}