時代はモニタリングツール大戦争時代。。。 数多のツールが登場し人々は何を使うべきか混乱していた!
TL;DR
- こんな感じに分類して自分たちが持ってるツールを横軸に並べる
- この例だとサービスヘルスチェックとSEIMが無いので早急に導入を検討するべき
Category | Zabbix | OEM | Confluent | ELK | NewRelic | Adobe Analytics | Firebase |
---|---|---|---|---|---|---|---|
Digital Experience Management | x | x | |||||
Service Health Check | |||||||
Application Performance Monitoring | x | ||||||
Distribution Tracing | x | ||||||
Middleware Monitoring | x | x | |||||
Server Monitoring | x | ||||||
Infrastructure Monitoring | x | ||||||
Security Information and Event Management(SIEM) | |||||||
Event Management | x | ||||||
Log Analysis/Dashboard | x | x |
はじめに
さて、みなさんは監視ツールは何を使っていますか?
Zabbixですか? Prometheusですか? あるいはDatadogでしょうか? Mackerelとかを使ってる人もいらっしゃると思います。
それとは別にNew RelicやDynatrace、InstanaのようなAPMを使ってる人も多いと思います。他にも分散トレースとしてOpenZipkinやJaegerを使うこともありますよね。あるいはこれらに加えてログ分析としてKibanaを入れてるケースもあるでしょうし、アラート管理にPagerDutyを入れてることもありますよね。
では、それらのツールの使い分けはどうされていますか? それぞれが単機能なら話は簡単ですが多くのツールは色々な機能をもっており「似たようなツールをすでに入れてますよね?」どれか一つ例えばPrometheusだけあれば大丈夫でしょうか不十分でしょうか?
と、監視ツールというのは領域が非常に複雑でかつ1つの製品で複数の機能を持ってるものが多いと思います。
そのため新しく入れたいツールを入れるときに、既に入れてる〇〇と何が違うの? みたいな話になりがちです。
もちろん導入に際してツールの評価はするのですが、ZabbixとNew RelicのどちらでもCPUメトリクスが見れたりZabbixも作りこめばアプリケーションレスポンスを可視化できるからといって同じ土俵で比較して良いのか疑問が残ります。
それぞれに得意分野があるので複数ツールを入れる事にはなると思いますがそれでも
というわけで、モニタリングツールのロールを分類して自分たちが持ってるツールがどういった範囲をカバーするものかを考えやすくしてみました。
以下のようにモニタリングツールのロールを以下の10個に分類してみました。
- Digital Experience Management
- Service Health Check
- Application Performance Monitoring(APM)
- Distribution Tracing
- Middleware Monitoring
- Server Monitoring
- Infrastructure Monitoring
- Security Information and Event Management(SIEM)
- Event Management
- Log Analysis/Dashboard
それぞれのロールの中でコンテナに対応しているとかしてないとかレベルはありますが、ロールとしてはこのくらいで分類しておけばいいかな、と思います。
各ロールの解説
Digital Experience Management
代表ツール:
- マーケッティング由来: Adobe Analytics, Google Analytics.
- APM由来: Fireabase, Dynatrace UEM, New Relic, AppDynamics
概要:
- UXのモニタリングツール。マーケッティングツールを出自とするものとAPMを出自とするものがあるけど、ようはユーザの行動分析をするツール。User Experience Monitoringとも。
- たぶん導入にさいして出自の違う似た目的の機能の代表格なので一番導入が揉める
- APM由来のものはなんだかんだでビジネス情報の分析にはマーケッティング由来のものには劣る印象。ただレスポンスと滞在率やドロップ数の相関を出すのには向いてるかも。
- 逆にマーケッティング由来はレスポンスが分からない事も多いので当面は両方入れるのが吉かなぁ
- 即時性が要求されないので、ログ解析をして自前で作ってるところも多いと思う。
Service Health Check
代表ツール:
- Zabbix, NetCool, Dynatrace, New Relic
概要:
- 外形監視またはヘルスチェック。サービスとして正常に動作している事を確認する。典型的なのは特定URL(/healthcheckとか)に投げたリクエストが正常に変えるのを確認する
- サーバが生きてるとかプロセスが生きてるとかではなくアプリケーションとして正常であることが大事
- healthcheckの実装がシンプル過ぎてhealthchekc以外は400とか500のゾンビを作らないように注意
- 高度なアプリケーション/ミドルウェアだとどの機能が動かないかも合わせて連携される。
- ほとんどのAPMや統合監視ツールの1機能として存在してるけど、単独で入れることも無くはないので分離
- コンテナの普及でプロセスが当たり前に死ぬようになり、ヒートマップのようなUIや個々のアプリの死は普段は見せないなど新しいUIが必要になってきた領域
Application Performance Monitoring(APM)
代表ツール:
- Dynatrace, New Relic, DataDog, ENdoSnipe, Stackdriver APM
概要:
- アプリケーションの性能をモニタリング/分析するツール
- レスポンスの劣化の検知、原因の特定(Diagnosis)が主な機能。その特性上、分散トレーシングをサポートするものが多い
- メソッドレベルでどこが遅いかを検知できるのでこの手のツールの有無で障害時の対策の早さは格段と変わる
- サーバメトリクスとかは参考情報として取ってるだけで個別ではCPUとメモリくらいしかないことも多い
Distribution Tracing
代表ツール:
- Dynatrace, New Relic, DataDog, Stackdriver APM, Jaeger, Dapper, OpenTracing
概要:
- 複数のアプリケーションをコンテキストにそってトラッキングするツール
- SOAやMSAでは複数のアプリケーションを必然またぐので原因分析のためにトラッキングが必須となり重要度が増してきた
- 汎用的なツールが出来るまではみんなログにトレースIDを書いたりタイムスタンプで絞り込んだり気合で頑張っていた
- APMとも関わり深くて開発が盛んな分野。OpenTracing, OpenCensusを統合して各種商用ツールがサポートするOpenTelemetryが今後のデファクトスタンダード予定
Midleware Monitoring
代表ツール:
- Oracle Enterprise Manager, Cloudera Manager, Confluent Control Center, Prometheus
概要:
- DBやMQ、あるいは分散処理基盤といったミドルウェアのモニタリングに特化したツール。大抵そのミドルウェアのベンダーが出している
- 一般的なモニタリングツールを超えて特化した作りなのでデータの詳細度もUIの使いやすさも格段と優れてる場合が多い
- ただし、他のシステムと分断されてサイロ化したり、アラート機能が弱い事はあるので、Event Managementに使ってるツールに主要メトリクスは投げて問題時の分析ツールとして使うのが無難
Server Monitoring
代表ツール:
- Zabbix, DataDog, Prometheus, Mackerel, Nagios, Dynatrace
概要:
- CPUやメモリ、Loadなど様々なサーバのメトリクスを収集して監視するツール
- LinuxサーバやWindowsサーバの監視はここ
- 昔からよく使われてるタイプのツール。モニタリングの基本。
- ただ、本質的にサービスレベル指標(SLI)では無いのでAIOpsとかの文脈では普段は気にしない事が推奨されてる値でもある
Infrastructure Monitoring
- Zabbix, DataDog, Prometheus, Mackerel, Nagios
概要:
- ネットワーク機器やストレージ機器などの値をSNMPとかを使って監視する
- Server Monitoringと基本的には同じだがエージェントのインストールが可能か不可能かが境目。なのでアプライアンスも実質こちら。
- 共有リソースの可能性が高くNoisy Neighboursの影響を受けやすい重要な監視ポイント
Security Information and Event Management(SIEM)
代表ツール:
- Splunk, Kibana SIEM, Azure Sentinel, McAfee SIEM,
概要:
- セキュリティログの収集・分析をするツール。「シーム」と発音する。
- 監査ログ(いつ、だれが、どんな操作をしたか)をPCからサーバ/運用ツール、バックオフィスツールの操作まで集め集約する
- 内側の情報だけでは無くネットワークパケットなどの監視もし侵入の分析にも使う。
- 分析した情報をレポート化しSOCチームやCIRTが分析/対応する。最近はAIとかで自動検知するものも多い
- ちゃんと入れとかないと個人情報を取り扱うタイプの会社だと国とかにめっちゃ怒られる
Event Management
代表ツール:
- Zabbix, Prometheus, Stackdriver Error Reporting, PagerDuty
概要:
- アラートをレポートする機能。ほぼ全ての監視ツールに基本的には付いている
- 複数の監視ツールを利用する時はそれぞれからアラートを出すと管理がキツイので、特定の監視ツールに集約してそこからアクションするのが基本
- 最も基本的なアラートはメールだが「メールはインシデントマネージメントツールではない」。可能ならJIRAやREDMINE, ServiceNowなどに飛ばそう
- 優先度の高いものはメールやChat、あるいは電話に流せる機能のものもある
- 賢いツールは単にイベントが発生したら即アラートを飛ばすのではなく、類似するアラートをまとめたりカスタムスクリプトでチェックをしたりAIで他のメトリクスとの相関をチェックしてアラートの数を減らしてくれるので本質的な問題に注力できる
- AIOpsの主戦場。Noisy Alert/オオカミ少年アラートの脱却は運用の最適化のための重要機能
Log Analysis/Dashboard
代表ツール:
- ELK, Metabase, Redash, StackDriver + BigQuery, grafana, Splunk
概要:
- 各種ログを集めて分析して可視化するツール。基本的には収集/分析/可視化が別々のツールで組み合わせを変えることもできる
- 既存のツールでは出来ない分析を自前のダッシュボードに表示するのが主な使い方
- DEM/UEMとして使うことも多い。
- システムの監視用途だけではなくBIとしてビジネスサイドで同一基盤を利用することも多い
- ログが膨大な場合はKafkaやSparkなどストリーム処理を間に咬ませることもある
モニタリングツールのポートフォリオ例
例えばとある企業が複数のモニタリングツールを使っている時、以下のようにあらわす事が出来ます。
Category | Zabbix | OEM | Confluent | ELK | NewRelic | Adobe Analytics | Firebase |
---|---|---|---|---|---|---|---|
Digital Experience Management | x | x | |||||
Service Health Check | |||||||
Application Performance Monitoring | x | ||||||
Distribution Tracing | x | ||||||
Middleware Monitoring | x | x | |||||
Server Monitoring | x | ||||||
Infrastructure Monitoring | x | ||||||
Security Information and Event Management(SIEM) | |||||||
Event Management | x | ||||||
Log Analysis/Dashboard | x | x |
で、APMを入れたいときはNew Relicと導入したいツールを入れることになりますし、そのツールがServer MonitoringをカバーしてるならZabbixとも部分的に比較することになるのが分かります。
あと、Service Health CheckやSIEMが無いので会社によっては「そんな装備で大丈夫か?」という事も分かります。
なお、これはあくまでポートフォリオをチェックして不足してツールや重複してるツールを探すための表なので、例えばAPMとしてDynatraceとInstanaの評価とかは別項目でする必要があります。
まとめ
主に自分で使うために分類してみたのですが、何となく便利そうなので公開してみました。
各ロールの中での機能のレベルももちろん大切なんですが、どういう機能のツールでそれはすでに運用のポートフォリオとしてカバーしてるのか否かを整理して会話するほうが楽なので、コミュニケーションツールとして使えるのではないかと。
一般論として広範囲をカバーするツールは高価なので、複数のツールを組合わせて自分たちが使いやすいものを低コストで作るか、商用の統合監視ツールをいれてそのフレームワークに則るのが良いのかと思います。
それではHappy Hacking!