エンタープライズトラフィックマネージャーのメトリクス要件は単純です。システムはどのくらい負荷がかかっているか、各vServiceはどれだけのリクエストを処理しているか、どのバックエンドが遅くなっているか、どのヘルスチェックがDOWNか、WAAP攻撃レートは上昇しているか？しかし多くのアーキテクチャでは、これらの質問に答えるために独立したexporterバイナリのデプロイ、監視、更新、回復が必要になります。
マルチプロセスとフォークアーキテクチャでは問題が複合します。すべてのワーカーが独自の統計を生成し、それらの数値を単一のスクレイプポイントにマージする必要があります。集約が適切に行われないと、Prometheusは欠落したメトリクス、二重カウントされた値、または一貫性のないパネルに行き着きます。運用チームはメトリクスパイプラインを第2のアプリケーションとして管理することになります。
ダッシュボード側も独自のコストを持ちます。空白のGrafanaインスタンスにデータを接続するのは始まりにすぎません。パネル、ラベル、アラート、しきい値、サービスごとの内訳はすべてゼロから構築する必要があります。適切なvService、バックエンドグループ、ヘルスチェック状態、テナントラベルモデルがないと、ダッシュボードは実用的な運用上の洞察ではなく汎用的なシステムグラフのみを提供します。
メトリクスタイプの規律も重要な懸念事項です。単調増加の値はcounterとして、瞬間的な読み取りと制限値はgaugeとして公開する必要があります。型の誤りはレート計算、アラートルール、長期トレンド分析を同等に壊します。
TR7ネイティブPrometheus + Grafana統合はこの負担を取り除きます。50+メトリクス、マルチプロセス集約、正確なgauge/counter分離、vServiceとバックエンドのラベルモデル、すぐに使えるGrafanaダッシュボードJSONファイルがオブザーバビリティをプラットフォームの自然な一部にします。
TR7は組み込みエンドポイント、プロセス集約、すぐに使えるダッシュボードパッケージを通じてメトリクスの公開を解決します — 外部のexporterは不要です。
TR7はHELPとTYPEラインを含むPrometheus exposition形式でメトリクスを公開します。gaugeとcounterの値は追加設定なしに直接スクレイプ可能な形式で提示されます。
フォークワーカーと子プロセスからのトラフィック統計がプライマリメトリクスパブリッシャーに集約されます。Prometheusは単一エンドポイントをスクレイプして統合されたビューを受け取ります。オペレーターはプロセスごとのexporterを管理する必要がありません。
単調増加のcounterと瞬間的なgaugeはスキーマで正しく型付けされています。この分離によりPrometheusのレート計算、アラートルール、ダッシュボードパネルのための正しいデータモデルが提供されます。
TR7はグローバルと詳細の両方のビュー向けのGrafanaダッシュボードJSONファイルを同梱しています。運用チームはゼロからパネルを構築する代わりに、プロダクション対応のメトリクスモデルでインポートして作業できます。
ネイティブPrometheus + Grafana統合はデバイス、vService、バックエンド、QoS、ヘルスチェックのメトリクスを単一のオブザーバビリティモデルにまとめます。
`tr7_device_uptime`はホストごとのデバイスアップタイムを秒単位で報告します。`tr7_device_cpu_detailed`はユーザー、システム、nice、irqによるCPU内訳をgaugeとして公開します。`tr7_device_mem_detailed`はtotal、active、cached、bufferのメモリ値をMBの粒度で追跡します。これらのメトリクスはトラフィック動作を基礎となるシステムリソースと相関させるためのベースラインを形成します。
`tr7_tm_qos_cpu_count`はvServiceに割り当てられたCPUコア数を報告します。`tr7_tm_qos_cpu_percent_limit`はCPUパーセント制限を、`tr7_tm_qos_memory_limit`はメモリ制限を公開します。これらのメトリクスはキャパシティ計画とテナントレベルのリソース追跡に不可欠です。オペレーターはトラフィックの成長を生のリクエスト数としてだけでなく、割り当てられたリソースエンベロープと合わせて確認できます。
vServiceレベルでは、アップタイム、プロセスアイドルパーセント、SSL接続、SSL合計、SSLレート、圧縮in/out、ドロップされたログ、メモリ使用量、セッション制限、セッション合計、リクエストレート、リクエスト合計などのメトリクスが含まれます。1xx〜5xxのレスポンスコード数はcounterとして公開されます。接続合計、バイトin/out、リクエストエラーはサービスの動作を明確にします。これらのメトリクスはSLAトラッキング、キャパシティ分析、エラー診断のためのプライマリパネルデータです。
`tr7_tm_vservice_waf_attack_rate`はWAAP攻撃レートをPrometheus側に運びます。セキュリティチームはこのメトリクスに対してアラートルールを記述し、ダッシュボードで攻撃トレンドを追跡できます。トラフィック量と攻撃レートは同じvServiceラベルモデルを共有するため、セキュリティシグナルは運用コンテキストと接続されたままです。
バックエンドレベルでは、newsession、session、レスポンスクラスカウンター、バイトin/out、接続エラー、レスポンスエラー、接続プール状態のメトリクスをカバーします。キュータイム、接続時間、レスポンスタイム、トータルタイムのメトリクスはバックエンドのレイテンシー分析に役立ちます。これらの測定値は特定のどのターゲットが遅くなっているかエラーを生成し始めているかを明らかにし、集約されたvServiceグラフの背後にある実際のバックエンドの動作を可視化します。
`tr7_tm_bservice_hc_state`はhost、vservice、bservice_group、bservice、stateラベルでヘルスチェック状態を報告します。UPは1、DOWNは0、NOCHECKは2としてエンコードされます。この数値モデルはPrometheusのアラートルールに便利です。DOWNのバックエンドは直接アラートをトリガーできます。`tr7_tm_bservice_hc_time`はヘルスチェックの実行時間もミリ秒単位で追跡します。
バックエンドラベルモデルにはbservice_groupフィールドが含まれており、デフォルトグループとダイナミックまたは条件付きで割り当てられたバックエンドグループを区別します。大きなvService設定では、オペレーターはダッシュボードパネルから直接どのグループが影響を受けているかを特定できます。運用チームはフラットなターゲットリストではなくトポロジー的な可視性を得ます。
TR7ワーカープロセスからのメトリクスはプライマリパブリッシャーにマージされます。Prometheusは単一の`/metrics`エンドポイントをスクレイプして完全な可視性を得ます。これによりプロセスごとのスクレイプと手動集約の必要がなくなります。高トラフィックのマルチフォークデプロイメントで一貫したダッシュボードを生成するために特に重要です。
値のないメトリクスフィールドは発行されません。これによりPrometheus側での無意味なnull gaugeの汚染を防ぎます。ダッシュボードパネルは実際に存在する値のみを表示します。現在の設定に存在しないフィールドはメトリクスシリーズ数を膨らませません。
TR7_Detailed_DashboardとTR7_Global_DashboardのJSONパッケージはGrafanaに直接インポートできます。グローバルダッシュボードはデバイスとサービスの全体的なビューを提供し、詳細なダッシュボードはvServiceとバックエンドごとの内訳に焦点を当てます。運用チームはゼロからパネルを構築する必要がありません。両方のダッシュボードはTR7が提供するPrometheusラベルモデルに沿って構造化されています。
Prometheus統合はメトリクスプレフィックス、定義されたラベルモデル、タイプ分離、数値によるヘルスチェック状態コードを通じて運用されます。
トラフィックマネージャーのメトリクスは`tr7_tm_*`プレフィックスの下で公開されます。システムレベルのメトリクスは`tr7_device_*`プレフィックスを使用します。この命名規則によりPromQLクエリとGrafanaの変数セレクターでメトリクスファミリーを簡単に見つけられます。
vServiceメトリクスは`{host, vservice}`ラベルセットで公開されます。host値はデバイスのホスト名から来ます。vserviceラベルはサービスごとのフィルタリングとGrafanaダッシュボード変数に使用されます。
バックエンドメトリクスは`{host, vservice, bservice_group, bservice}`ラベルセットで公開されます。このモデルはサービス、バックエンドグループ、個別のターゲットレベルでの分析をサポートします。アラートルールは特定のバックエンドまで絞り込めます。
ヘルスチェック状態メトリクスはUP、DOWN、またはNOCHECKの値を持つstateラベルを持ちます。数値エンコーディングによりアラートルールの記述が簡単になります。DOWNマッチはPrometheusのアラート定義に直接リンクできます。
単調増加する値 — req_tot、ssl_tot、session_total、レスポンスコード数、バイトin/out、リクエストエラー — はcounterとして公開されます。これらの値はPrometheusのrateまたはincrease関数で分析する必要があります。長期的なトラフィックトレンド分析に適切なメトリクスタイプです。
瞬間的な読み取り — リクエストレート、現在の接続数、制限値、ヘルスチェック時間、キュータイム、接続時間、レスポンスタイム — はgaugeとして公開されます。gaugeは現在の状態を反映し、しきい値ベースのアラートルールに使用されます。制限と使用率の値は同じダッシュボードパネルに並べて表示できます。
SREチームはTR7の`/metrics`エンドポイントをPrometheusのスクレイプターゲットとして追加します。すぐに使えるGrafanaダッシュボードJSONファイルをインポートすることでグローバルと詳細なビューが即座に開きます。独立したexporterのデプロイは不要です。
運用チームは`tr7_tm_vservice_memory_alloc`と関連するメモリメトリクスを時間をかけて追跡できます。使用率が定義されたしきい値に近づくとアラートが発生できます。キャパシティの判断は推定ではなく測定されたトレンドに基づきます。
セキュリティチームは`tr7_tm_vservice_waf_attack_rate`に対してPrometheusアラートルールを定義できます。特定のvServiceで攻撃レートが上昇すると、インシデント管理ワークフローがトリガーされます。トラフィックとセキュリティの可視性が同じダッシュボードに収束します。
`tr7_tm_bservice_hc_state`がDOWN状態を0として報告すると、アラートが発生できます。アラートはhost、vservice、bservice_group、bserviceラベルを通じて影響を受けるターゲットを直接識別します。SREチームはログをスキャンせずにどのバックエンドがダウンしたかを特定できます。
50+の組み込みメトリクス、マルチプロセス集約、すぐに使えるダッシュボードJSONファイル。お客様自身の環境でライブセットアップをご案内します。