古典的なロードバランサーのログは、多くの場合、基本的なアクセスログレベルにとどまります。status code、response time、URL、backend、TLS、WAAPスコア、geo-IP、ユーザーコンテキストが、異なるシステムにあったり、まったく収集されなかったりします。この場合、運用チームは問題を理解するためにログをパースし、別個のダッシュボードを書き、または異なるチームからデータを求めなければなりません。
WAAPログとADCログが別々の場所に保持されると、相関が難しくなります。同じリクエストのパフォーマンスとセキュリティの両方のコンテキストを見るには、request ID、timestamp、IP、path、session情報を手作業で対応付ける必要があります。インシデント時にこの手動相関は時間を浪費させます。
マルチテナントまたは複数vServiceの構成では、retentionとレポーティングも別個の問題になります。あるテナントが大量のログを生む間に別のテナントのデータが失われてはなりません。重要な規制対象のアプリケーションはより長く保持されつつ、公開Webトラフィックはより短いretentionで保持できるべきです。
正しいアプローチは、L7リクエストレベルのログを時系列メトリクスとともに扱うことです。request rate、SSL TPS、status code分布、WAAP attack rate、backendのresponse time、dropped log、ヘルスチェックのメトリクスが同じダッシュボードファミリーで監視されるべきです。
TR7 L7 Reportingアドオンはこのモデルを提供します：L7リクエスト、WAAP、backend、ヘルスチェック、QoSのデータを組み込みダッシュボードとレポーティング層で可視化します。
TR7 L7 Reportingは、エンリッチ化されたログストリーム、時系列メトリクス、組み込みダッシュボード、ドリルダウン変数で動作します。
TR7はL7トラフィックログとWAAPイベントを共通のレポーティングラインに持ち上げます。これにより、パフォーマンス、エラー、攻撃のシグナルを同じvServiceコンテキストで調査できます。
request rate、status code、SSL TPS、throughput、ヘルスチェック、QoSのメトリクスを時間にわたって保持できます。この構造は容量計画、インシデント後分析、定期的なパフォーマンス追跡に使えます。
TR7は詳細なvServiceダッシュボードとグローバルダッシュボードの構造で、基本的な運用パネルを最初から提供します。オペレーターは初日からトラフィック、SSL、backend、メモリ、CPU、WAAPのメトリクスを監視できます。
vService、backend、host変数でダッシュボードフィルタを適用できます。5xxの増加から特定のURLへ、そこから遅くなっているbackendまで調査できます。
L7 Reportingアドオンは、リクエストレベルからプラットフォーム全体まで50+のパネル/要素でアプリケーショントラフィックを監視可能にします。
詳細ダッシュボードは、HTTP/HTTPS request rate、新規request、session request、total connection、SSL TPS、throughput、CPU、memory、SSL cache、errorのメトリクスをvServiceコンテキストで表示します。オペレーターは単一のアプリケーションの動作を、プラットフォーム全体のノイズに紛れることなく調査できます。このビューはインシデント時にどのvServiceが影響を受けたかを素早く切り分けます。パフォーマンスとセキュリティのシグナルが同じ画面で解釈されます。
グローバルダッシュボードは平均CPU使用率、総vService数、総backend数、uptime、全体的なHTTP/SSLメトリクスを表示します。この画面はプラットフォームの全体状況を管理と運用のチームに要約します。複数vService環境では、どの領域が混み合っているかが素早くわかります。容量計画のための最初の一望画面として使えます。
Health Check Status、Health Check Time、Health Check Stateのパネルは、backendの到達可能性と応答時間の状態を表示します。UP、DOWN、NOCHECKといった状態を時間にわたって監視できます。応答時間の増加は、完全な障害が起きる前にパフォーマンスの劣化を示し得ます。これらのメトリクスはfailoverとpoolの動作の理解を容易にします。
1xx、2xx、3xx、4xx、5xxのresponse counterパネルがアプリケーションの応答動作を分類します。5xxの増加はbackendまたはアプリケーションのエラーを、4xxの増加はクライアント、bot、WAAPの影響を示し得ます。オペレーターはまずエラークラスを、次にURLとbackendの詳細を調査できます。この構造はインシデントトリアージの時間を短縮します。
TR7はWAAP攻撃イベントを要約して攻撃タイプを集約レベルで表示できます。個々の生のWAAPログの代わりに、攻撃カテゴリ、強度、時間分布を監視します。セキュリティチームはどのvServiceがどの攻撃ファミリーに直面しているかをより速く見られます。これは日次のSOCレビューと月次のセキュリティレポーティングを容易にします。
`tr7_tm_vservice_waf_attack_rate`メトリクスはvServiceレベルでWAAP攻撃レートを表示できます。急激な増加はbotの波、exploitスキャン、標的型攻撃のシグナルであり得ます。このメトリクスはトラフィック量とともに解釈されると、攻撃の強度がより正確に理解されます。アラートとダッシュボードのシナリオで高い価値を持ちます。
backend側ではsession、new session、response code、inbound/outboundトラフィック、connection error、response error、queue time、connect time、response time、total timeといったメトリクスを監視できます。この分離は、問題がADC側にあるのか、ネットワークにあるのか、backendにあるのかを理解するのに役立ちます。例えばconnect_timeの増加はネットワークまたはサービス受け入れの問題、response_timeの増加はアプリケーションの遅延であり得ます。インシデント分析がより的確に行えます。
高トラフィックまたはログパイプラインの問題が発生すると、dropped logの数が増え得ます。Logs Droppedパネルは可観測性データの信頼性を監視するのに役立ちます。ログ損失がある場合、ダッシュボードの解釈は慎重に扱うべきです。運用チームはトラフィックだけでなく、測定ラインの健全性も追跡します。
Compress in/outメトリクスが圧縮動作を表示します。オペレーターはどのvServiceで圧縮がどれだけのトラフィック効果を生んでいるかを監視できます。これらの値はWANコスト、ユーザー体験、CPU消費とともに評価されます。圧縮ポリシーは勘ではなくデータで管理されます。
`tr7_tm_vservice_memory_usage`や`tr7_tm_vservice_memory_alloc`といったメトリクスはvServiceのメモリ動作を監視できます。時間にわたる増加トレンドは容量計画と潜在的なリーク分析にとって価値があります。オペレーターは瞬間的な障害だけでなく、将来の容量圧迫も見られます。これは増大するアプリケーショントラフィックのための計画的なスケーリングを実現します。
`tr7_tm_qos_cpu_count`、`tr7_tm_qos_cpu_percent_limit`、`tr7_tm_qos_memory_limit`といったメトリクスはプラットフォームのリソース制限を可視化します。これらの値はトラフィックメトリクスとともに監視されることでリソース圧迫が理解されます。あるvServiceのエラー発生がリソース制限への接近と関連している場合、より速く検出されます。QoSの可視性は容量と分離の判断を支えます。
TR7は詳細ダッシュボードとグローバルダッシュボードのinterval構成を個別のファイルで管理できます。これはダッシュボードの更新と時間範囲の動作をより一貫させます。長期トレンドと短期インシデント分析は異なる間隔で行えます。オペレーターは異なるユースケースに応じてパネルのタイミングを調整します。
L7 reportingは、metric namespace、frontend/backendメトリクス、ヘルスチェックstate、QoSフィールド、ダッシュボード変数とともに運用されます。
TR7のメトリクスは`tr7_tm_*`の名前空間の下にグループ化されます。この構造はfrontend、backend、ヘルスチェック、QoS、デバイスのメトリクスを区別することを容易にします。ダッシュボードとアラートのルールはこの命名を通じて標準化されます。
request rate、total connection、inbound/outbound byte、request error、1xx-5xx response、SSL connection、SSL rate、SSL cache、compression、dropped log、メモリのメトリクスがfrontend側で監視できます。これらのメトリクスはユーザーに面するvServiceの動作を説明します。問題が外部トラフィック、TLS、response動作に起因するかどうかが切り分けられます。
backend側ではsession、response code、トラフィック、接続エラー、responseエラー、タイミングのメトリクスを収集できます。Queue、connect、response、total timeの分離はパフォーマンス分析において重要です。アプリケーション、ネットワーク、サービス受け入れの問題が異なるメトリクスで可視化されます。
`tr7_tm_bservice_hc_state`はbackendの健全性状態をUP、DOWN、NOCHECKとして表せます。`tr7_tm_bservice_hc_time`はヘルスチェックの応答時間をミリ秒レベルで表せます。ヘルスチェックのトレンドはfailoverの動作の理解を容易にします。
CPU数、CPU割合の制限、メモリ制限といったQoSフィールドをダッシュボードに持ち込めます。これらのメトリクスは高トラフィック時にリソース制限の影響を理解することを実現します。特にマルチテナントや高負荷のサービスでは容量の判断を支えます。
`$vservice`、`$bservice`、`$host`といった変数でパネルをフィルタできます。オペレーターはグローバルなグラフから特定のvServiceへ、そこから特定のbackendへ掘り下げられます。このドリルダウンのフローはインシデント調査を速めます。
オペレーターは5xxパネルから該当するURLへ、そこから遅くなっているbackendへ掘り下げられます。connect_timeとresponse_timeのメトリクスは、問題がネットワークかアプリケーションかを切り分けるのに役立ちます。
セキュリティチームはSSLメトリクスとWAAP attack rateの値を定期レポートに取り込めます。これらのデータはアプリケーションセキュリティとトラフィック保護の制御の可視性を高めます。
ヘルスケアまたは規制対象のvServiceにはより長いretentionを、公開Webトラフィックにはより短いretentionを適用できます。これにより保管コストとコンプライアンスのニーズが均衡します。
Memory alloc、request rate、throughputのトレンドを監視して、将来の容量ニーズを予測できます。オペレーターはスケーリングの判断を瞬間的な感覚ではなく、時系列データで行います。
WAAP attack rateが増加したとき、攻撃カテゴリを要約し、影響を受けたvServiceをフィルタできます。SOCチームは生のログの中で迷うことなく、攻撃のタイプと強度を見られます。
組み込みダッシュボード、ドリルダウンメトリクス、WAAPレポーティング — すべてをライブ構築でご案内します。