故障を減らすということには、故障が起こらないよう通常の予防をしっかり行うことと、故障が発生した場合に損失をできるだけ早く止めて故障期間を短縮することの2つの意味があります。監視の一般的な役割は、障害の発見と位置特定を支援することですが、これら 2 つのリンクは障害の継続時間を短縮するために重要です。
運用保守担当者と研究開発担当者は、安定性を重視する典型的な人物ですが、重視する点は異なります。一般に、運用保守担当者は社内の全事業の運用保守を担当し、研究開発担当者は自らの事業分野の研究開発業務のみを担当するため、障害発生時には運用保守担当者が責任を負うことになります。担当者は、問題の根本原因を迅速に特定し、損失を時間内に阻止することを望んでいます。研究開発担当者らも「無実を証明したい」としている。目的を問わず監視は欠かせないツールです。
ビジネス プログラムの公開方法も複数あり、有名な埋め込みツールとしては StatsD や Prometheus があります。もちろん、一部の言語には、Java エコシステムの Micrometer など、その言語に適した使いやすい埋め込みツールがあります。通常、ビジネス プログラムには、インデックス監視に加えて、リンク追跡フレームワーク (Zipkin、Jaeger、Skywalking など) の導入など、より豊富な監視方法があります。もちろん、すべてのソフトウェアでログを使用して正常性状態を明らかにできますが、この方法は最も高価であり、データは構造化されていないため、トラブルシューティングには適していますが、指標データのソースとしては適していません。
指標モニタリングは数値しか処理できませんが、履歴データの保存コストが低く、リアルタイム性が高く、生態系が巨大であるため、可観測性の分野で最も重要な柱です。
もう 1 つの重要な可観測性の柱はログ記録です。ログからは、ソフトウェアの動作やビジネスの運営を理解するために重要な多くの情報が得られます。たとえば、オペレーティング システム ログ、アクセス レイヤ ログ、サービス実行ログはすべて重要なデータ ソースです。
可観測性の最後の柱はリンク トレースです。マイクロサービスの普及により、元の単一のアプリケーションが多数の小さなサービスに分割され、サービス間の呼び出し関係が複雑になり、どのモジュールが問題を引き起こしているかをトラブルシューティングすることは実際には非常に困難です。
リンク トラッキングの考え方は、上流モジュールと下流モジュールをリクエストと直列に接続し、各リクエストのリクエスト ID としてランダムな文字列を生成することです。サービス同士が呼び出す際にレイヤーごとにIDが引き継がれ、各レイヤーにどれくらいの時間がかかったか、正常に処理されたかなどを収集してリクエストIDに付加することができます。後で問題を追跡するときに、リクエスト ID を使用して一連の情報をすべて抽出できます。
Zabbix は、デバイス、ネットワーク、ミドルウェアの監視に優れたエンタープライズ レベルのオープン ソース ソリューションです。ここ数年の監視システムは主に機器やミドルウェアの監視に使われているため、中国ではZabbixが広く使われています。
Zabbixの利点
- さまざまなデバイスとの互換性が高く、AgentdはWindowsやLinuxだけでなくAixでも動作します。
- 構造がシンプルで、時系列データの保存にデータベースを使用するため、保守が容易で、バックアップやダンプも比較的簡単です。
- コミュニティは巨大で、情報もたくさんあります。Zabbix は長い間開発されており、インターネット上で多数のリソースを見つけることができるため、2012 年にオープンソース化されました。
Zabbixの欠点
- データベースをストレージとして使用すると、水平方向に拡張できず、容量も限られます。収集頻度が高い場合 (10 秒に 1 回など)、上限で約 600 台のデバイスを監視でき、データベースは SSD や NVMe ディスクなどの非常にハイエンドのマシンに展開する必要があります。
- Zabbix の資産指向の管理ロジックは、監視指標のデータ構造が比較的固定的であり、柔軟なラベル設計がなく、クラウド ネイティブ アーキテクチャの下で動的で変化しやすい環境に直面すると、無力に見えます。
Open-Falcon は、RRDtool に基づいて分散タイミング ストレージ コンポーネント Graph を作成しました。このアプローチにより、複数のマシンをクラスターに形成でき、大量のデータの処理能力が大幅に向上します。転送を担当する以前のコンポーネントは Transfer です。Transfer は監視データの一意の ID を取得し、その ID をハッシュして監視データと Graph インスタンスの間の対応関係を生成します。これが Open-Falcon アーキテクチャのコア シャーディング ロジックです. .
オープンファルコンのメリット
- 大規模な監視シナリオを処理でき、Zabbix よりもはるかに大きな容量を備えています。デバイスおよびミドルウェア レベルでの監視だけでなく、アプリケーション レベルでも監視を処理できます。最終的には、Xiaomi の内部パフォーマンス カウンターと 3 セットの Zabbix を置き換えることになりました。
- コンポーネントは比較的緩やかに分割されており、ほとんどが Go 言語で開発されており、Web パーツは Python で二次開発が容易です。
オープンファルコンのデメリット
- 生態系は十分に大きくなく、Xiaomi が支配しています。多くの企業が二次開発を行っていますが、コミュニティに還元していません。貢献者もいますが、その数は比較的少ないです。
- オープンソースソフトウェアのガバナンス体制が十分ではなく、シャオミ社の中核開発者が離職し、プロジェクトが停滞したため、シャオミ社は今後のガバナンスに投資せず、財団主催のプロジェクトに比べて活力に欠けていた。
Prometheus は Kubernetes のために生まれました。Kubernetes の直接サポートを提供し、さまざまなサービス検出メカニズムを提供し、Kubernetes の監視を大幅に簡素化します。
Kubernetes 環境では、ポッドの作成と破棄が非常に頻繁に行われ、監視指標のライフサイクルが大幅に短縮されるため、Zabbix のような資産指向の監視システムでは対応できなくなります。さらに、ほとんどのクラウドネイティブ環境は、マイクロサービスの増加により、サービスの数が増加し、インジケーターの数も爆発的に増加しており、時系列データ ストレージに対する非常に高い要件が求められています。
プロメテウスの利点
- Kubernetes を非常によくサポートしており、現在、Prometheus が Kubernetes 監視の標準構成となっています。
- エコロジーは巨大で、さまざまなエクスポーターがあり、さまざまなタイミング ライブラリがバックエンド ストレージとしてサポートされており、ビジネス コードの埋め込み用にさまざまな言語をサポートする SDK もあります。
プロメテウスのデメリット
- アラーム戦略は設定ファイルの修正が必要となるなど、使い勝手が悪く調整が面倒です。もちろん、IaC の導入が進んでいる企業は、このほうが良いと考えていますが、現在の国内環境ではそこまではできず、誰もが依然として Web インターフェイスを使用して監視データを表示し、アラーム ルールを管理することを好みます。
- 輸出業者は不均等であり、通常、1 つの監視対象に対して 1 つの輸出業者が存在し、管理コストが比較的高くなります。
- 容量の問題のため、Prometheus はデフォルトで単一マシンのタイミング ライブラリのみを提供しており、クラスター ソリューションは他のタイミング ライブラリに依存する必要があります。
Nightingale は開発者が集団であるため Open-Falcon の続編と見ることもできますが、この 2 つのソフトウェアの位置づけは全く異なります。車輪の再発明であるため、ナイチンゲールのアプローチは、Prometheus とうまく統合して、より完全なソリューションを作成することです。現在のアーキテクチャでは、主に Prometheus をタイミング ライブラリおよびナイチンゲールのデータ ソースと見なしています。Prometheus を使用しなくても問題ありません。たとえば、VictoriaMetrics をタイミング ライブラリとして使用することも多くの企業で選択されています。
ナイチンゲールの利点
- UI、権限管理、製品機能が比較的充実しており、全社レベルでの統一監視製品として全チームで利用可能です。Prometheus は通常、各チームで使用され、より便利です。企業が同じ Prometheus システムを使用して監視要件を解決する場合、面倒で上で述べた調整の問題が発生しやすくなりますが、Nightingale は調整において比較的うまく機能します。
- 互換性がありオープンな設計で、Categraf、Telegraf、Grafana-Agent、Datadog-Agent およびその他のコレクターとのドッキング、および Prometheus エコシステムのさまざまなエクスポーターとのドッキングをサポートしています。タイミング ライブラリは、Prometheus、VictoriaMetrics、M3DB、Thanos などとのドッキングをサポートしています。 。
ナイチンゲールのデメリット
- コンピュータ室のネットワーク断片化の問題を考慮して、アラームエンジンはモジュールを個別に取り外して各コンピュータ室に配備していますが、多くの中小企業ではそのような複雑なアーキテクチャは必要なく、導入とメンテナンスがより面倒です。 。
- アラーム イベントの送信には、集約とノイズ リダクションの収束ロジックが欠如しています。公式の説明では、将来的には、Nightingale、Zabbix、Prometheus などの複数のデータ ソースからのアラーム イベントをサポートする別のイベント センター製品が開発される予定ですが、まだ開発されていません。まだリリースされました。
各ソリューションにはそれぞれ長所と短所があります。主な要件が機器の監視である場合は、Zabbix を使用することをお勧めします。主な要件が Kubernetes の監視である場合は、Prometheus + Grafana を選択できます。両方を考慮したい場合は、Prometheus + Grafana を選択できます。従来の機器やミドルウェアの監視シナリオだけでなく、Kubernetes も考慮して企業レベルのソリューションを構築する必要があるため、Nightingale の使用をお勧めします。
この記事は、 Geek Timeの「運用保守監視システム実践ノート」から7月のDay27の学習メモです、お勧めの講座です。