监测工具的十分类别和投资组合
时代正处于监控工具大战时代。。。诸多工具纷纷登场，人们陷入了选择困惑！
TL;DR (太长不读)
-
- こんな感じに分類して自分たちが持ってるツールを横軸に並べる
- この例だとサービスヘルスチェックとSEIMが無いので早急に導入を検討するべき
xxService Health Check
Application Performance Monitoring
x
Distribution Tracing
x
Middleware Monitoring
xx
Server Monitoringx
Infrastructure Monitoringx
Security Information and Event Management(SIEM)
Event Managementx
Log Analysis/Dashboardx
x
首先
那么，大家都在使用什么监控工具呢？是Zabbix吗？还是Prometheus？或者是Datadog呢？我认为也可能有人在使用Mackerel。
我认为还有很多人会使用New Relic、Dynatrace和Instana等APM工具。另外，还有一些人会使用OpenZipkin或Jaeger等分布式跟踪工具。或者还会将Kibana用作日志分析，并且可能还会将PagerDuty用于警报管理。
在中国，您如何区分使用这些工具？如果每个工具都只有一个功能，那就容易理解了。但是很多工具都有各种功能，会不会出现“您已经安装了类似的工具，对吧？”如果只有一个例如Prometheus，是否足够呢？还是不够呢？
在中文中，我认为监视工具是非常复杂的领域，且一个产品通常具有多个功能。因此，当要安装新的工具时，往往会询问与已安装的〇〇有何不同。
当然，在引入工具之前需要进行评估，但是在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
对于每个角色，可以根据其对容器的兼容性水平进行分类，但作为一个角色，我认为将其归类为这个程度就可以了。
对各个角色进行解释
数字体验管理
代表工具：
-
- マーケッティング由来: Adobe Analytics, Google Analytics.
- APM由来: Fireabase, Dynatrace UEM, New Relic, AppDynamics
总结：
-
- UXのモニタリングツール。マーケッティングツールを出自とするものとAPMを出自とするものがあるけど、ようはユーザの行動分析をするツール。User Experience Monitoringとも。
-
- たぶん導入にさいして出自の違う似た目的の機能の代表格なので一番導入が揉める
-
- APM由来のものはなんだかんだでビジネス情報の分析にはマーケッティング由来のものには劣る印象。ただレスポンスと滞在率やドロップ数の相関を出すのには向いてるかも。
-
- 逆にマーケッティング由来はレスポンスが分からない事も多いので当面は両方入れるのが吉かなぁ
- 即時性が要求されないので、ログ解析をして自前で作ってるところも多いと思う。
服务健康检查
代表工具：
- Zabbix, NetCool, Dynatrace, New Relic
概述:
-
- 外形監視またはヘルスチェック。サービスとして正常に動作している事を確認する。典型的なのは特定URL(/healthcheckとか)に投げたリクエストが正常に変えるのを確認する
-
- サーバが生きてるとかプロセスが生きてるとかではなくアプリケーションとして正常であることが大事
-
- healthcheckの実装がシンプル過ぎてhealthchekc以外は400とか500のゾンビを作らないように注意
-
- 高度なアプリケーション/ミドルウェアだとどの機能が動かないかも合わせて連携される。
-
- ほとんどのAPMや統合監視ツールの１機能として存在してるけど、単独で入れることも無くはないので分離
- コンテナの普及でプロセスが当たり前に死ぬようになり、ヒートマップのようなUIや個々のアプリの死は普段は見せないなど新しいUIが必要になってきた領域
应用性能监控（APM）
代表工具：
- Dynatrace, New Relic, DataDog, ENdoSnipe, Stackdriver APM
简介:
-
- アプリケーションの性能をモニタリング/分析するツール
-
- レスポンスの劣化の検知、原因の特定(Diagnosis)が主な機能。その特性上、分散トレーシングをサポートするものが多い
-
- メソッドレベルでどこが遅いかを検知できるのでこの手のツールの有無で障害時の対策の早さは格段と変わる
- サーバメトリクスとかは参考情報として取ってるだけで個別ではCPUとメモリくらいしかないことも多い
分销追踪
代表工具:
- Dynatrace, New Relic, DataDog, Stackdriver APM, Jaeger, Dapper, OpenTracing
简要描述、概述、概况
-
- 複数のアプリケーションをコンテキストにそってトラッキングするツール
-
- SOAやMSAでは複数のアプリケーションを必然またぐので原因分析のためにトラッキングが必須となり重要度が増してきた
-
- 汎用的なツールが出来るまではみんなログにトレースIDを書いたりタイムスタンプで絞り込んだり気合で頑張っていた
- APMとも関わり深くて開発が盛んな分野。OpenTracing, OpenCensusを統合して各種商用ツールがサポートするOpenTelemetryが今後のデファクトスタンダード予定
中间件监控
代表工具：
- Oracle Enterprise Manager, Cloudera Manager, Confluent Control Center, Prometheus
总结：
-
- DBやMQ、あるいは分散処理基盤といったミドルウェアのモニタリングに特化したツール。大抵そのミドルウェアのベンダーが出している
-
- 一般的なモニタリングツールを超えて特化した作りなのでデータの詳細度もUIの使いやすさも格段と優れてる場合が多い
- ただし、他のシステムと分断されてサイロ化したり、アラート機能が弱い事はあるので、Event Managementに使ってるツールに主要メトリクスは投げて問題時の分析ツールとして使うのが無難
服务器监控
代表工具：
- Zabbix, DataDog, Prometheus, Mackerel, Nagios, Dynatrace
总结：
-
- CPUやメモリ、Loadなど様々なサーバのメトリクスを収集して監視するツール
-
- LinuxサーバやWindowsサーバの監視はここ
-
- 昔からよく使われてるタイプのツール。モニタリングの基本。
- ただ、本質的にサービスレベル指標（SLI）では無いのでAIOpsとかの文脈では普段は気にしない事が推奨されてる値でもある
基础设施监控
- Zabbix, DataDog, Prometheus, Mackerel, Nagios
总而言之：
-
- ネットワーク機器やストレージ機器などの値をSNMPとかを使って監視する
-
- Server Monitoringと基本的には同じだがエージェントのインストールが可能か不可能かが境目。なのでアプライアンスも実質こちら。
- 共有リソースの可能性が高くNoisy Neighboursの影響を受けやすい重要な監視ポイント
安全信息和事件管理(SIEM)
代表工具：
- Splunk, Kibana SIEM, Azure Sentinel, McAfee SIEM,
总结:
-
- セキュリティログの収集・分析をするツール。「シーム」と発音する。
-
- 監査ログ(いつ、だれが、どんな操作をしたか)をPCからサーバ/運用ツール、バックオフィスツールの操作まで集め集約する
-
- 内側の情報だけでは無くネットワークパケットなどの監視もし侵入の分析にも使う。
-
- 分析した情報をレポート化しSOCチームやCIRTが分析/対応する。最近はAIとかで自動検知するものも多い
- ちゃんと入れとかないと個人情報を取り扱うタイプの会社だと国とかにめっちゃ怒られる
活动管理
代表工具：
- Zabbix, Prometheus, Stackdriver Error Reporting, PagerDuty
摘要：
-
- アラートをレポートする機能。ほぼ全ての監視ツールに基本的には付いている
-
- 複数の監視ツールを利用する時はそれぞれからアラートを出すと管理がキツイので、特定の監視ツールに集約してそこからアクションするのが基本
-
- 最も基本的なアラートはメールだが「メールはインシデントマネージメントツールではない」。可能ならJIRAやREDMINE, ServiceNowなどに飛ばそう
-
- 優先度の高いものはメールやChat、あるいは電話に流せる機能のものもある
-
- 賢いツールは単にイベントが発生したら即アラートを飛ばすのではなく、類似するアラートをまとめたりカスタムスクリプトでチェックをしたりAIで他のメトリクスとの相関をチェックしてアラートの数を減らしてくれるので本質的な問題に注力できる
- AIOpsの主戦場。Noisy Alert/オオカミ少年アラートの脱却は運用の最適化のための重要機能
日志分析/仪表盘
代表工具：
代表工具：
- ELK, Metabase, Redash, StackDriver + BigQuery, grafana, Splunk
概述:
-
- 各種ログを集めて分析して可視化するツール。基本的には収集/分析/可視化が別々のツールで組み合わせを変えることもできる
-
- 既存のツールでは出来ない分析を自前のダッシュボードに表示するのが主な使い方
-
- DEM/UEMとして使うことも多い。
-
- システムの監視用途だけではなくBIとしてビジネスサイドで同一基盤を利用することも多い
- ログが膨大な場合はKafkaやSparkなどストリーム処理を間に咬ませることもある
监测工具的投资组合示例
如果一个公司使用多个监控工具，可以表达如下：
xxService Health Check
Application Performance Monitoring
x
Distribution Tracing
x
Middleware Monitoring
xx
Server Monitoringx
Infrastructure Monitoringx
Security Information and Event Management(SIEM)
Event Managementx
Log Analysis/Dashboardx
x
所以，如果想要使用APM，就需要安装New Relic和其他想要的工具，如果该工具可以覆盖服务器监控，那么也可以部分参考Zabbix进行比较。
另外，由于缺乏服务健康状况检查和安全信息与事件管理系统（SIEM），所以可以理解有些公司会对这样的设备提出质疑：“这样的装备足够吗？”
此外，这只是用来检查投资组合并查找缺失或重复工具的表格，因此评估Dynatrace和Instana等作为APM的情况需要另外一个项目来进行。
概括一下
只是把它分成不同的类别，以供自己使用，但由于一些原因觉得这些分类可能对他人也有用，所以就公开了。当然，各个角色中的功能级别也是重要的，但整理出已经在运营组合中涵盖了哪些功能工具会更容易进行交流，因此我认为它可以作为一种沟通工具使用。
一般而言，覆盖广泛的工具价格昂贵，因此我们可以通过组合多个工具来以较低成本制作符合我们需求的易于使用的工具，或者选择商业集成监控工具来适应该框架。
那么，祝你愉快地进行黑客攻击！
