Prometheus監視プラットフォームを導入する際には、6つの要素を考慮する必要がありますが、どれも無視することはできません。

企業がコンテナを導入する場合、コンテナの監視も優先されます。多くの企業がコンテナとマイクロサービスを監視するために Prometheus を使用しています。これは通常、大規模企業にとってはより積極的なものとなるため、大規模に展開する際には拡張の課題に直面することになります。

コンテナは状況を複雑にする

かつては、企業内の物理サーバーと仮想マシンの数は固定されており、メトリックの数も限られていたため、環境全体の監視は比較的簡単でした。現在、コンテナとマイクロサービス アーキテクチャへの移行により、追跡するエンティティの数は爆発的に増加しています。

新しいマシンが追加されるにつれて、コンテナの数は増え続け、マシン 1 台あたり数百になることもあります。Kubernetes などのオーケストレーション ツールと併用すると、コンテナの存続期間が非常に短くなるため、追跡が難しくなり、注意しないと多くの問題が発生する可能性があります。

環境の複雑さと分散が増すにつれて、監視する必要があるエンティティの数も増加します。さらに、何が起こっているかを正確に把握したり、トラブルシューティングやインシデント対応の際に何が起こっているかを把握したりするために、さらに多くの属性を監視する必要がある場合もあります。こうした一時的な環境では、問題の根本原因を理解しようとする頃には、問題のあるリソースがすでに削除されていることが多く、トラブルシューティングが特に困難になります。つまり、監視ソリューションでは、フォレンジックを実施するために十分な履歴を保存する方法を提供する必要があります。

プロメテウス

クラウド監視に関しては、IT チームは Cloud Native Computing Foundation のオープンソース プロジェクトである Prometheus にますます注目するようになっています。 Prometheus は、クラウド ネイティブ環境でメトリックを収集して理解するために開発者が選択する監視ツールになりました。 700 社を超える企業貢献者による大規模なコミュニティによってサポートされています。

Kubernetes、Ngnix、MongoDB、Kafka、golang などの一般的なクラウドネイティブ アプリケーション スタックは、デフォルトで Prometheus メトリックを公開します。 Prometheus は、垂直にスケーラブルな Go プログラムとして設計されています。たとえば、単一のコンテナまたは単一のホストとして簡単にデプロイできます。つまり、Prometheus を使い始めて、Kubernetes クラスターに関する洞察を得るのは簡単です。しかし、これはまた、インフラストラクチャが拡大するにつれて、監視の規模も課題に直面することを意味します。

規模の問題

環境が拡大し、追跡する必要がある時系列データの量が爆発的に増加すると、ある時点で単一の Prometheus インスタンスでは対応できなくなります。最も簡単な方法は、企業全体で Prometheus サーバーのフリートを実行することですが、これにもいくつかの課題があります。たとえば、数十または数百の Prometheus サーバー間でデータを管理および統合するのは簡単ではありません。同様に、エンタープライズ ワークフロー、シングル サインオン、ロールベースのアクセス制御を決定し、SLA やコンプライアンスに準拠することも簡単な問題ではありません。アプリケーションが成長するにつれて、開発者の作業を中断せずに包括的な監視ソリューションを運用することが、管理性と信頼性の大きな問題になります。

この問題を解決するために、企業はいくつかの方法を採用しました。

簡単な最初のステップは、名前空間ごとまたはクラスターごとに個別の Prometheus サーバーを使用することです。このアプローチは、明らかに一定のレベルを超えて拡張することが困難であり、さらにそれを超えると、多数の切断されたデータ サイロが作成されるという欠点があります。ほとんどの問題は複数のサービス/チーム/クラスターにまたがるため、トラブルシューティングが面倒になります。すべての環境で同じメトリックを見つけることは難しいだけでなく、何が起こっているかを理解するためにデータを組み合わせる必要もあります。

もう 1 つの一般的なアプローチは、Cortex や thanos などのオープン ソース ツールを使用して複数の Prometheus サーバーを統合することです。これらは、集中的にサーバーをクエリし、データを収集し、単一のダッシュボードでデータを共有できる強力なツールです。ただし、他のデータ集約型分散システムと同様に、運用するには多大なスキルとリソースが必要です。

考慮すべき6つの要素

Prometheus から始めて、全体的な監視を提供する商用ソリューションを探している企業にとって、ダッシュボードやアラートなど、Prometheus で標準化するために行われたすべての開発作業を失わないことが重要です。ただし、考慮すべきことはこれだけではありません。次の要素が役立つ場合があります。

1. 互換性、すべてのPrometheus機能のサポート

選択するクラウド ベンダー、ツール、または SaaS ソリューションは、オンプレミスの Kubernetes であろうと、任意のクラウド サービスであろうと、Prometheus メトリックを生成するあらゆるものからデータを使用できる必要があります。 Prometheus のメトリックは比較的些細なものです。しかし、メトリックをストレージに抽出するときにラベルを付け直したり、データを拡張して環境に適したものにしたりできるといった小さな点も見逃さないでください。これらが積み重なって、収集された大量のデータの利用に大きな違いが生まれます。

2. PromQLの互換性

Prometheus クエリ言語は、Prometheus によって保存された情報を抽出するために使用されます。 PromQL は、特定のサービスや特定のユーザーなどのメトリックについて問い合わせることができます。また、データの集計やセグメント化も可能で、たとえば、アプリケーション ベースですべてのコンテナーの CPU 使用率を表示したり、Cassandra コンテナーのデータのみをクラスターごとに単一の値として表示したりできます。つまり、PromQL は Prometheus の真の価値を解き放ちます。したがって、PromQL を完全にサポートしていない製品に Prometheus メトリックを組み込むと、Prometheus を使用する目的が達成されなくなります。

3. ホットスワップ

真の Prometheus 互換を実現するには、ソリューションはホットプラグ可能で、既存のダッシュボード、アラート、スクリプトと連携できる必要があります。たとえば、Prometheus を使用する多くの企業は、ダッシュボードとして Grafana を使用しています。このオープンソース ツールは、クエリ レベルを含め Prometheus と適切に統合されており、さまざまな便利なグラフやダッシュボードを生成するために使用できます。したがって、Prometheus と互換性があると主張する商用製品は、Grafana などのツールとも互換性があるはずです。このソリューションにより Grafana で数値を表示できるようになると言うだけでは十分ではありません。既存の Grafana ダッシュボードをそのまま抽出し、商用ソリューションのデータに再適用できる必要があります。

4. アクセス制御

アクセス制御は、ツールを評価する際に考慮すべきもう 1 つのセキュリティ問題です。 LDAP、Google Oauth、SAML、OpenID などの業界標準プロトコルを使用してユーザー認証を保護することで、企業はサービスベースのアクセス制御を通じてリソースを分離し、保護することができます。

5. トラブルシューティング

Kubernetes は、コンテナ化されたアプリケーションとマイクロサービスの展開、スケーリング、管理を簡素化します。これはサービスの稼働維持に役立ちますが、パフォーマンスの低下、デプロイメントの失敗、接続エラーなどの根本的な問題を特定して解決するには、運用環境から詳細なインフラストラクチャ、アプリケーション、パフォーマンス データを収集して視覚化する機能が必要です。リアルタイムの情報とコンテキスト データの両方にアクセスできない場合、コンテキスト内でメトリックを相関させて問題をより迅速に解決することはほぼ不可能です。

6. 既存のアラームとの互換性

最後に、Prometheus のスケーラビリティの問題を解決するための商用ソリューションを探している場合は、あらゆるレベルのアラートをサポートしていることを確認してください。これを実現するための鍵は、アラート マネージャー機能の完全なサポートであり、そのためには PromQL との 100% の互換性が必要です。