Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

9.2. Network Observability のアラート (テクノロジープレビュー) の有効化

Network Observability Operator アラートはテクノロジープレビュー機能です。この機能を使用するには、FlowCollector カスタムリソース (CR) でこの機能を有効にしてから、お客様のニーズに合わせてアラートを設定する必要があります。

手順

  1. FlowCollector CR を編集して、実験的なアラートのフラグを true に設定します。 
apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: flow-collector
spec:
  processor:
    advanced:
      env:
        EXPERIMENTAL_ALERTS_HEALTH: "true"

9.2.1. 事前定義済みアラートの設定
リンクのコピー

Network Observability Operator のアラートは、FlowCollector カスタムリソース (CR) の spec.processor.metrics.alerts オブジェクト内のアラートテンプレートおよびバリアントを使用して定義されます。デフォルトのテンプレートとバリアントをカスタマイズして、柔軟できめ細かなアラートを作成できます。

アラートを有効にすると、OpenShift Container Platform Web コンソールの Observe セクションに Network Health ダッシュボードが表示されます。

テンプレートごとに、それぞれ固有のしきい値とグループ化設定を持つバリアントのリストを定義できます。詳細は、「デフォルトのアラートテンプレートのリスト」を参照してください。

以下に例を示します。 

apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: flow-collector
spec:
  processor:
    metrics:
      alerts:
      - template: PacketDropsByKernel
        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
注記

アラートをカスタマイズすると、そのテンプレートのデフォルト設定が置き換えられます。デフォルト設定を維持する場合は、手動で複製する必要があります。

9.2.2. アラートの PromQL 式について
リンクのコピー

Prometheus Query Language (PromQL) のベースクエリーと、それをカスタマイズして特定のニーズに合わせて Network Observability アラートを設定する方法を説明します。

Network Observability の FlowCollector カスタムリソース (CR) 内のアラート API は、Prometheus Operator API にマッピングされており、PrometheusRule を生成します。次のコマンドを実行すると、デフォルトの netobserv namespace 内の PrometheusRule を確認できます。 

$ oc get prometheusrules -n netobserv -oyaml

9.2.2.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))
        > 100

9.2.2.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 文字列です。

Expand
表9.1 netobserv_io_network_health アノテーションのフィールド
フィールド型説明

namespaceLabels

文字列のリスト

namespace を保持する 1 つ以上のラベル。指定すると、アラートが Namespaces タブに表示されます。

nodeLabels

文字列のリスト

ノード名を保持する 1 つ以上のラベル。指定すると、アラートが Nodes タブに表示されます。

threshold

文字列

アラートしきい値。PromQL 式で定義したしきい値と同じ値にする必要があります。

unit

文字列

表示目的でのみ使用されるデータ単位。

upperBound

文字列

閉じた尺度でスコアを計算するために使用される上限値。この上限を超えるメトリクス値は丸められます。

links

オブジェクトのリスト

アラートに応じて表示されるリンクのリスト。各リンクには、name (表示名) と url が必要です。

trafficLinkFilter

文字列

Network Traffic ページの URL に注入する追加のフィルター。

namespaceLabels と nodeLabels は相互に排他的です。どちらも指定されていない場合は、Global タブにアラートが表示されます。

9.2.3. カスタムアラートルールの作成
リンクのコピー

Prometheus Query Language (PromQL) を使用して、特定のネットワークメトリクス (トラフィックの急増など) に基づいてアラートをトリガーするカスタム AlertingRule リソースを定義します。

前提条件

  • PromQL に関する知識。
  • OpenShift Container Platform 4.14 以降がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • Network Observability Operator がインストールされている。

手順

  1. AlertingRule リソースを含む、custom-alert.yaml という名前の YAML ファイルを作成します。

  2. 次のコマンドを実行して、カスタムアラートルールを適用します。 

    $ oc apply -f custom-alert.yaml

検証

  1. 次のコマンドを実行して、PrometheusRule リソースが netobserv namespace に作成されたことを確認します。 

    $ oc get prometheusrules -n netobserv -oyaml

    出力に、作成した netobserv-alerts ルールが含まれているはずです。これにより、リソースが正しく生成されたことを確認できます。

  2. OpenShift Container Platform Web コンソールの Network Health ダッシュボード Observe をチェックして、ルールがアクティブであることを確認します。

9.2.4. 事前定義済みアラートの無効化
リンクのコピー

FlowCollector カスタムリソース (CR) の spec.processor.metrics.disableAlerts フィールドで、アラートテンプレートを無効にできます。この設定は、アラートテンプレート名のリストを受け付けます。アラートテンプレート名のリストは、「デフォルトのアラートのリスト」を参照してください。

テンプレートが無効化され、かつ spec.processor.metrics.alerts フィールドでオーバーライドされている場合、無効化の設定が優先され、アラートルールは作成されません。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る