ブログ

Prometheusの監視プラットフォームで考慮すべき6つのこと

Prometheusの監視プラットフォームで考慮すべき6つのこと

本文の内容は、2020年8月25日にLoris Degioanniが投稿したブログ(https://sysdig.com/blog/6-things-to-consider-in-a-prometheus-monitoring-platform/)を元に日本語に翻訳・再構成した内容となっております。

組織は、コンテナやマイクロサービスのエステートを監視するためにPrometheusを利用するようになってきていますが、大企業は壁にぶつかってしまうことがよくあります。ある程度のアプリケーションを超えたところで、スケーリングの課題に直面します。

コンテナが複雑にしていること

モノリシック環境の監視は、以前は比較的簡単でした。一定数の静的な物理サーバと仮想マシンがあり、監視すべきメトリクスの数も限られていました。今日では、コンテナとマイクロサービス・アーキテクチャへの移行により、追跡すべきエンティティの数は爆発的に増えています。

データセンターに置かれているサーバーがペットであり(これまで説明されてきたように)、クラウドインスタンスが家畜のようなものだとしたら(たくさん持っているから一つも気にしない)、コンテナはイナゴのようなものだと言えるでしょう。コンテナはたくさんあり、時にはマシンごとに数百個、常に新しいものが現れ、Kubernetesのようなオーケストレータと組み合わせて使用すると、その寿命は非常に短くなることがあります。そのため、それらを追跡することがはるかに難しくなり、注意していないと、多くの被害を引き起こす可能性があります。

環境の複雑さや分散が進むと、監視する必要のあるエンティティの数も増えます。さらに、何が起こっているのか、あるいはトラブルシューティングやインシデント対応の場合には何が起こっていたのかを正確に把握するために、より多くの属性を監視する必要があるかもしれません。後者は、問題の根本原因を理解しようとするときには、問題のリソースはすでに廃止されていることが多く、監視ソリューションはフォレンジックのために十分な履歴を保存する方法を提供しなければならないからです。

Prometheus

クラウド監視が必要な場合、チームはオープンソースのCNCFプロジェクトであるPrometheusを利用するケースが増えています。Prometheusは、クラウドネイティブ環境でメトリクスを収集して意味のあるものにするために、開発者が使用する監視ツールとして利用されるようになりました。Prometheusは、700社以上の企業から6,300人のコントリビューターが参加し、13,500回のコードコミットと7,200回のプルリクエストがある大規模なコミュニティによってサポートされています。

Kubernetes、Ngnix、MongoDB、Kafka、golangなどの一般的なクラウドネイティブアプリケーションスタックは、デフォルトでPrometheusのメトリクスを公開しています。Prometheus は、垂直方向にスケールする Go プログラムとして設計されています。例えば、単一のコンテナや単一のホストとしてデプロイするのが簡単です。つまり、最初のKubernetesクラスタの可視性を得るためにPrometheusを使い始めるのは非常に簡単です。しかし、それはまた、インフラストラクチャーが大きくなるにつれて、その限界にぶつかることを意味します。

スケールの問題

環境が大きくなればなるほど、追跡する必要のある時系列データの数は急増し、ある時点で、単一のPrometheusインスタンスでは追いつけなくなります。簡単なオプションとしては、企業全体でPrometheusサーバを複数台稼働させることが考えられますが、これにはいくつかの課題があります。例えば、何十台、何百台ものPrometheusサーバにまたがるデータを管理し、フェデレートすることは容易ではありません。同様に、企業のワークフロー、シングルサインオン、ロールベースのアクセス制御、SLAやコンプライアンスの遵守も簡単な問題ではありません。アプリケーションが成長するにつれ、開発者の作業を中断することなく、包括的な監視ソリューションを運用することは、大きな管理性と信頼性の問題となります。

これに対処するために、企業はいくつかのアプローチを採用してきました。

簡単な最初のステップは、各ネームスペースやクラスタごとに個別のPrometheusサーバを用意することです。このアプローチは、ある時点を超えて拡張するのは明らかに困難であり、それに加えて、切断されたデータのサイロが大量に発生するというデメリットがあります。ほとんどの問題は複数のサービス/チーム/クラスタにまたがるため、トラブルシューティングが面倒になります。各環境で同じメトリクスを見つけるのが難しいだけでなく、何が起こっているのかを理解するためにデータをつなぎ合わせなければなりません。

もう一つの一般的なアプローチは、CortexやThanostoなどのオープンソースのツールを使用して、複数のPrometheusサーバをフェデレートすることです。これらのツールは強力なツールで、集中的な方法でサーバに問い合わせを行い、データを収集し、単一のダッシュボードで共有することができます。しかし、他のデータ集約型分散システムと同様に、運用には相当なスキルとリソースが必要です。

考慮すべき6つの要素

Prometheusから始めて、全体的なビューを提供するための商用ソリューションを探している企業にとって、Prometheus上で標準化された開発作業(ダッシュボード、アラート、エクスポート、その他の作業)のすべてを失わないことが重要です。しかし、考慮すべきはそれだけではありません。あなたがこのルートを行く場合は、これらのコア基準のサポートを主張してください。

1.Prometheusのすべての機能をサポートする完全なインジェスト互換性

ベンダー/ツール/SaaSソリューションは、Kubernetesオンプレミスでもクラウドサービスでも、Prometheusメトリクスを生成できるあらゆるエンティティからデータを消費できる必要があります。Prometheus メトリクスを消費することは比較的些細なことですが、メトリクスをストレージにインジェストする際にラベルを付け直したり、環境に合わせてデータを拡張したりすることができるなど、些細なことも見逃さないでください。これらのことが積み重なることで、収集した大量のデータを利用できるようになり、大きな違いが生まれます。

2. PromQL との互換性

Prometheus Query Language は、Prometheusの開発者によって、Prometheusに保存されている情報を抽出するために考案されました。PromQLを使用すると、例えば特定のサービスや特定のユーザーに関するメトリクスを求めることができます。また、データを集約したり、セグメント化したりすることもできます。例えば、すべてのコンテナのCPU使用率をアプリごとに表示したり、Cassandraのデータのみを表示したりすることができます。また、Cassandraコンテナのデータのみを表示し、各クラスタの単一の値として表示することもできます。したがって、PromQLを完全にサポートしていない製品にPrometheusのメトリクスを取り込むことは、Prometheusを使用する目的をすべて打ち破ることになります。

3. ホットスワップ可能

Prometheusと真に互換性を持たせるためには、既存のダッシュボード、アラート、スクリプトと連携できるという点で、ホットスワップ可能なソリューションでなければなりません。例えば、Prometheus を使用している多くの企業は、ダッシュボードに Grafana を使用しています。このオープンソースツールは、クエリレベルを含めてPrometheusとうまく統合されており、さまざまな有用なチャートやダッシュボードを作成するために使用することができます。Prometheusとの互換性を謳っている商用製品は、Grafanaのようなツールと互換性があるはずです。Grafana で数値を表示できるだけでは不十分です。既存の Grafana ダッシュボードを変更せずにそのまま取り込み、商用ソリューションにインストールされたデータに再適用できる必要があります。

4. アクセス制御

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

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

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

既存のアラートとの互換性。最後に、Prometheusのスケーラビリティの問題に対処するための商用の回答を探している場合は、すべてのレベルのアラートをサポートしていることを確認してください。これを実現するための鍵は、Alert Managerの機能を完全にサポートすることであり、これには100%のインジェストとPromQLの互換性が必要です。

まとめ

これらの基準を満たす商用ツールを見つけた場合は、既存の Prometheus統合ツールとのスワップを最小限に抑え、企業が直面しているスケーラビリティの問題を回避することができるはずです。開発者が Prometheus を愛用しているのにはそれなりの理由がありますが、今すぐにデューデリジェンスを行うことで、開発者が愛用しているメトリクスを確実に使用できるようにすることができます。

ご質問・お問い合わせはこちら

top