コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム

本文の内容は、2021年11月18日にCarlos Arillaが投稿したブログ(https://sysdig.com/blog/challenges-prometheus-lts/）を元に日本語に翻訳・再構成した内容となっております。

この記事では、自身のPrometheus LTSソリューションを維持する際に直面する可能性のある3つの主な課題を取り上げます。

当初、Prometheusは長期的なメトリクスストレージではないと主張していましたが、期待された結果は、いずれ誰かがPrometheusメトリクスのためにその長期的なストレージ（LTS）を作ることでした。

現在、長期ストレージ（Prometheus LTS）を提供するオープンソースのプロジェクトがいくつかあります。これらのコミュニティプロジェクトは、他のプロジェクトよりも先行しています。Cortex、Thanos、M3です。


Prometheusを使い始めるのはかなり簡単です。Prometheusには、サービスディスカバリーのようないくつかのメカニズムがあり、ほとんど努力せずにすぐに使えるように設計されています。しかし、インフラの成長を計画しているのであれば、すぐにいくつかの課題に直面するでしょう。

課題1：Prometheus LTSのノウハウ

Prometheus をクラスターに設定し、アラートやルールの作成（または promcat.io からのリソースの追加）やメトリクスの視覚化を始めると、通常、クラウドネイティブなインフラは急速に成長します。

突然、異なるリージョンに複数のクラスターがあり、その上で異なるアプリケーションが実行されることがあります。そして、そこからPrometheusソリューションの課題が始まるのです。

Prometheusを管理するには、すぐに使える素材を使うだけではなく、カーディナリティ、パフォーマンス、PromQLの最適化などの詳細にも気を配る必要があります。

以下のような機能をうまくコントロールする必要があります：

• ラベルの変更、削除、追加などのリラベル
• ターゲットの設定
• さまざまなタイプの集計とロールアップ

さらに、集中型の長期ストレージに移行するためには、以下のようないくつかの分野で強力な知識が必要となります。

Prometheus LTS ソリューションのアーキテクチャー

Prometheus LTS の導入と保守は、簡単なことではありません。様々なソリューションは、運用の複雑さを軽減する上で大きな進歩を遂げていますが、それらを使い始めるためには、まだかなりの量の調査と学習が必要です。

監視構造のアーキテクチャー

メトリクスの情報を切り刻むことができる効率的なラベルを作成するためには、さまざまな戦略についての知識が必要です。

また、優れたアグリゲーション戦略、情報をセグメント化するためのラベルのセット、読み取りパスの効率を改善するためのレコーディングルールも必要です。また、インフラの設計に起因する、私たちが想像もつかないような特異な現象にも注目する必要があるでしょう。

このような知識は、アプリケーションを作成し、アプリケーションの監視やトラブルシューティングのためにこれらのメトリクスが提供する観察可能性を必要としている会社のチーム全体に普及していなければなりません。これには十分なトレーニングが必要で、誤用の可能性から監視プラットフォームに問題が生じるかもしれません。

課題2：Prometheus LTSの拡張

以前、Prometheus のスケーリングに関する課題について説明しました。

ソリューションの導入は手頃な価格でできるとはいえ、Prometheus LTSシステムを適切に管理するためには、いくつかの点に留意しなければなりません。最も重要なものの一つがスケールです。スケールは、さまざまな次元で重要な役割を果たします。

• カーディナリティ：システム内のメトリクスの数は、カスタムメトリクスやラベル、使用しているアプリの規模などによって、その時々で大きく変化します。プロビジョニングされたストレージのサイズを変更するか、オブジェクトストレージのようなスケーラブルなシステムを使用する準備をする必要があります（現在、ほとんどのPrometheus LTSはオブジェクトストレージをサポートしています）。
• Read path：ダッシュボードの数と、それらのダッシュボードを読み込むユーザーの数は、アプリをインストルメント化したり、DevOpsチームがPrometheusの使い方を紹介したりしているうちに増えていく可能性があります。アラートの数も増える可能性があります。システムの規模が大きくなると、レコーディングルールの使用やさまざまな最適化（クエリーキャッシング）が必要になります。
• クラスター内の収集：クラスターの成長に対応する必要があります。最初のうちは、クラスターごとに1台のPrometheusがあれば、すべてのメトリクスを収集するのに十分です。しかし、やがては、ノードごとに1つのメトリクスコレクターや他のシャーディング戦略など、異なる戦略に切り替える必要があるでしょう。

課題3：インフラの最適化（コスト）

Prometheus LTSを運用するには、メトリクスを収集、保存、提供できるようにするために、かなりの量のリソースが必要になります。

インフラのアーキテクチャにもよりますが、オンプレム、クラウド、ハイブリッドのリソースはほぼ無限のバリエーションがあります。コストをコントロールし、サービスを実行するためのリソースを適切に提供することが課題となります。

この時点で、クラウドプロバイダーの請求書が、あらゆるITインフラに関連する最も重要なコストの1つであることは誰もが知っています。課題1と課題2の結果は、インフラのコストとそれに伴う複雑さに直接影響を与えます。クラウドプロバイダーのコストを最適化するには多くの知識が必要ですが、この場合、選択したPrometheus LTSアプリケーションから得られる最適化の度合いに直接関係してきます。

まとめ

この記事では、Prometheus LTS ソリューションをオンプレミスで保守する際の、3つの主な課題をお読みいただきました。この記事では、最も怖いものの1つであるスケーリングについて深く掘り下げています。

また、30日間の無料トライアルが可能なマネージドPrometheusサービスについてもご紹介しています！

Sysdigに関するお問い合わせはこちらから