Splunkと4つのゴールデンシグナル

昨年、SplunkのオブザーバビリティエバンジェリストであるJeremy Hicksが、監視の4つのゴールデンシグナルに関するすばらしいブログ記事を投稿しました。そのブログは、分散したクラウドサービスをSplunk Observability Cloudで監視するという観点から書かれていますが、4つのゴールデンシグナルの考え方は従来のオンプレミスのサービスやITインフラにも適用できます。お客様の多く、特に国防関連のお客様は、今でもオンプレミスのITインフラ環境に大きく依存しているため、このブログでは、Splunk EnterpriseまたはSplunk Cloud PlatformとSplunk IT Service Intelligenceを使用するという前提で、このインフラ監視の最新アプローチをご紹介したいと思います。

監視やオブザーバビリティの体制を構築するときにまず直面するのが、「どこから始めるべきか？」や「何を監視すべきか？」といった疑問です。ホストやOSのメトリクスを収集するなど、すぐに思いつくこともありますが、それは全体のほんの一部でしかありません。

出発点として最適なのは、Jeremyがブログ記事でわかりやすく説明しているように、4つのゴールデンシグナルです。それはどのようなものでしょうか？Google社のSREブックには次のように書かれています。

「監視の4つのゴールデンシグナルには、レイテンシー、トラフィック、エラー、サチュレーションがあります。ユーザー向けのシステムのメトリクスを4つだけ測定するとしたら、この4つが最適です」(原文はこちら)

具体的なメトリクスを示しているわけではないため、私はこれらを4つのゴールデンシグナルのカテゴリと考えていますが、話をややこしくしないために、このブログでもGoogle社(とJeremy)の呼び方に従いたいと思います。

4つのゴールデンシグナルの定義

レイテンシー

簡単に言うと、リクエストへの応答にかかる時間です。Webページの読み込み時間のようにエンドユーザーにもはっきりとわかるものもありますが、バックエンドでは、ユーザーエクスペリエンスに直接関わる処理だけでなく、データベースの応答時間など、エンドユーザーには見えないさまざまな処理が関係します。

トラフィック

システムに対する需要を測る指標です。1秒あたりのHTTPリクエスト数、同時接続ユーザーセッション数、1秒あたりのデータベーストランザクション数などが該当します。

エラー

リクエスト処理の失敗率です。1秒あたりに発生したHTTP 500エラー数、ネットワークインターフェイスでのドロップパケット数、各ディスクデバイスで報告されたI/Oエラー数などが該当します。ここにはポリシー上のエラーも含まれます。たとえば、サービスレベル目標(SLO)としてページの平均読み込み時間を1秒と定めている場合、1秒を超えた読み込みはすべてエラーと見なされます。

サチュレーション

ごく簡単に言えば、システムにどのくらい負荷がかかっているかです。ファイルシステム、物理ディスク、論理ディスクの使用率など、わかりやすい指標もあれば、CPU使用率やメモリー負荷など、運用環境に関する知識や経験が必要な指標もあります。

4つのゴールデンシグナルをSplunkで監視する

では、これらのメトリクスをSplunk EnterpriseやSplunk Cloud Platformで監視するにはどうすればよいでしょうか？Splunkで何をするときにも言えることですが、まずは、問題を解決するために必要なデータソースを特定します。この時点で、インフラだけでなく、そこで運用されているアプリケーションやサービスも考慮するとよいでしょう。エンドユーザー向けのサービスレベル契約(SLA)や(当然作成済みですよね？)、サービスレベル目標(SLO)を確認するのもお勧めです。SLOは、監視する対象と、それらを監視するために必要なデータソースの優先順位を判断するために役立ちます。SLOをまだ設定していない場合は、以下の情報を参考にしてください。

データソース

次の表に、推奨される一般的なデータソースと、4つのゴールデンシグナルへの対応を示します。

表に示したソースがすべてではありませんが、従来のITシステム監視ユースケースの大半をカバーしています。たとえば、製造管理システムのコンポーネントを監視する場合、表に示したデータソースの一部と、OT/IoTセンサーデータを組み合わせることになるでしょう。

以下では、表に挙げた各データソースについて1つずつ見ていきます。

Webサーバーログ

Webサーバーは通常、多層構造のアプリケーションスタックの最上位にあり、エンドユーザーエクスペリエンスとアプリケーションスタックの全体的な健全性の両方についてさまざまな情報が得られます。ページの読み込み時間などのレイテンシーメトリクスや、400番台、500番台のステータスコードなどのエラーメトリクスは通常、このログから収集できます。1秒あたりのリクエスト数などのトラフィックメトリクスもここから取得できます。

Splunkbaseには、このログの収集に役立つ以下のようなアプリやアドオンがあります。

• Splunk Add-on for Apache Web Server
• Splunk Add-on for NGINX
• Website Monitoring

アプリケーションログ

監視が必要なアプリケーションは無数にあり、一般的なものだけでもここに挙げきれません。最低でもアプリケーションのエラーイベントは収集すべきです。この情報があればアプリケーションの健全性を把握できます。アプリケーションログには、レイテンシーメトリクスが含まれることもあります。最も良い方法は、Splunkで数日分のアプリケーションログを収集し、キーワードやメッセージをサーチして、特に重要なメトリクスが含まれるイベントログを確認することです。

ホストメトリクス

ハードウェアと仮想インフラのどちらでホストを運用する場合でも、CPU、メモリー、ネットワーク、ディスク/ファイルシステムの使用状況に関するメトリクスは、アプリケーションが動作するシステムの負荷(サチュレーション)を把握するために欠かせません。Splunkでは、各OSに適したアドオンを使用することで、これらのメトリクスを簡単に収集できます。

• Splunk Add-on for Unix and Linux
• Splunk Add-on for Microsoft Windows

(仮想ホストからのホストメトリクス収集の注意点については、このブログの「仮想インフラログ/メトリクス」セクションを参照してください。)

データベースサーバーログ/メトリクス

データベースは多くのアプリケーションで情報源として頻繁に参照されるため、パフォーマンスの問題が起きると、アプリケーションスタック全体に悪影響が及ぶ可能性があります。幸い、ほとんどのデータベースソリューションでは、4つのゴールデンシグナルすべてをカバーする豊富なパフォーマンスメトリクスが提供されます。

Splunkbaseには、データベース情報の収集に役立つ以下のようなアプリやアドオンがあります。

• Splunk Add-on for Microsoft SQL Server
• Splunk Add-on for Oracle Database
• Splunk Add-on for MySQL

ネットワークログ/メトリクス

ネットワークデバイスは、アプリケーションの基盤を支える「配管」の役割を果たし、そのパフォーマンスを監視することは、障害やボトルネックの根本原因を理解するために重要です。Splunkbaseには、主要なネットワークベンダーのハードウェアに対応したアプリやアドオンがあり、ネットワーク情報を収集するのに役立ちます。たとえば以下のものがあります。

• Cisco Networks Add-on for Splunk Enterprise
• Splunk Add-on for Juniper
• Palo Alto Networks Add-on for Splunk

ネットワークの健全性を示すデータソースが多数ある場合は、SNMPも役立ちます。SNMPポーリングやトラップで収集された情報は、Netflow and SNMP Analytics for SplunkやSplunk Connect for SNMPなどのツールを使って簡単に取り込むことができます。

少なくともネットワークデバイスのイベントログは必須です。この情報は、Splunk Connect for Syslog経由でSplunkに簡単に取り込めます。

仮想インフラログ/メトリクス

ホストメトリクスの収集は間違いなく重要ですが、このメトリクスからは、ホストが仮想インフラでゲストとして実行されている間の状況しかわかりません。ホストメトリクスでCPU使用率が10%だとわかっても、物理的なCPUリソースが割り当てられるまでの待ち時間はわかりません。仮想インフラ固有のメトリクスは、仮想インフラから収集する必要があります。ここでも、Splunkでの収集に役立つアドオンがいくつかあります。

• Splunk Add-on for VMware Metrics
• Splunk Add-on for Microsoft Hyper-V

仮想インフラからホストに関するメトリクスを収集するときは注意が必要です。仮想インフラメトリクスを収集する場合は、そのインフラで動作する個々の仮想ホストに関するすべてのメトリクスが収集されるため、WindowsやUnix/Linuxアドオンではホストメトリクスを収集しないでください。Splunk IT Essentials WorkまたはSplunk IT Service Intelligenceアプリを使用する場合、両方のメトリクスを収集すると、情報が重複することになります。

まとめと次のステップ

監視ソリューションを導入するときに、具体的に何を監視すべきかをよく考えないと、十分な情報を得られないばかりか、情報が多すぎて収拾がつかなくなりがちです。重要で価値ある情報の収集にこのブログ記事をぜひお役立てください。

この記事を参考に、現在収集しているデータを見直し、重要なインフラやアプリケーションの状況を正確に把握するために本当に必要なデータが得られているかどうかを確認しましょう。より詳しい情報やアドバイスが必要な場合は、Splunkのアカウントチームに連絡して、担当のソリューションエンジニアやカスタマーサクセスマネージャーにご相談ください。Splunkはいつでも喜んでお客様をご支援します！

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。