Prometheusユーザーへのインタビューシリーズを続け、ComposeはGraphiteとInfluxDBからPrometheusへのモニタリングの道のりについて語ります。
あなた自身とComposeの事業内容について教えてください。
Composeは、世界中の開発者に本番環境に対応したデータベースクラスタをサービスとして提供しています。 アプリ開発者は、数回クリックするだけで、数分以内にマルチホスト、高可用性、自動バックアップ、安全なデータベースを準備できます。 これらのデータベースデプロイメントは、需要の増加に合わせて自動的にスケールアップされるため、開発者はデータベースの運用ではなく、優れたアプリの構築に時間を費やすことができます。
私たちは、AWS、Google Cloud Platform、SoftLayerのそれぞれで、少なくとも2つのリージョンにわたって数十のホストクラスタを保有しています。 各クラスタは、サポートされている場合はアベイラビリティーゾーンにまたがり、独自のプライベートネットワーク内に約1000の高可用性データベースデプロイメントをホストしています。 さらに多くのリージョンとプロバイダーが準備中です。
Prometheus導入以前のモニタリング体験はどのようなものでしたか？
Prometheus以前は、さまざまなメトリクスシステムを試しました。 最初に試したシステムはGraphiteで、最初はかなりうまく機能しましたが、保存する必要のある膨大な数のメトリクスと、Whisperファイルがディスクに保存およびアクセスされる方法が組み合わさって、システムがすぐに過負荷になりました。 Graphiteは比較的簡単に水平方向にスケーリングできることはわかっていましたが、高価なクラスタになっていたでしょう。 InfluxDBはより有望に見えたため、初期バージョンを試用し始め、しばらくの間はうまく機能しているようでした。 Graphiteとはお別れです。
InfluxDBの初期バージョンには、データ破損が時折発生するという問題がありました。 定期的にすべてのメトリクスをパージする必要がありました。 通常、私たちにとって壊滅的な損失ではありませんでしたが、イライラさせられました。 実現しなかった機能の継続的な約束は、率直に言って私たちを疲れさせました。
なぜPrometheusを検討することにしたのですか？
他のオプションよりも優れた効率性とシンプルな運用を兼ね備えているように見えました。
プルベースのメトリクス収集は最初は戸惑いましたが、すぐに利点に気づきました。 当初は、各ホストに数百のコンテナとその独自のメトリクスがある環境では、スケールするには重すぎるように思えましたが、Telegrafと組み合わせることで、各ホストがすべてのコンテナのメトリクス（および全体的なリソースメトリクス）を単一のPrometheusスクレイプターゲットを介してエクスポートするように設定できます。
どのように移行しましたか？
私たちはChefを使用しているので、大きなEBSボリュームを持つ大規模なインスタンスを立ち上げ、Prometheus用のコミュニティChefクックブックを利用しました。
ホストにPrometheusをセットアップし、Chef APIを使用してすべてのホストをクエリし、Prometheusターゲット設定ファイルを書き出す小さなRubyスクリプトを作成しました。 このファイルを`file_sd_config`で使用して、Chefに登録されるとすぐにすべてのホストが検出され、スクレイプされるようにします。 Prometheusのオープンなエコシステムのおかげで、Telegrafをシンプルな設定ですぐに使用して、ホストレベルのメトリクスを直接エクスポートできました。
単一のPrometheusがどこまでスケールするのかをテストし、それが停止するのを待っていました。 しかし、停止しませんでした！ 実際、新しいインフラストラクチャ全体で約450台のホストのホストレベルのメトリクスを15秒ごとにスクレイプするという負荷を、非常に少ないリソース使用量で処理しました。
各ホストには多くのコンテナがあるため、すべてのメモリ使用量メトリクスも追加するとPrometheusのシャード化を開始する必要があると予想していましたが、Prometheusは問題なく動作し続け、リソースを飽和させることもありませんでした。 現在、450台のホスト上の約40,000のコンテナについて、15秒ごとに400,000を超える個別のメトリクスを、1TBのストレージを備えた単一のm4.xlarge Prometheusインスタンスで監視しています。 このホストのホストダッシュボードを以下に示します。 1TB gp2 SSD EBSボリュームのディスクIOが最終的には制限要因になる可能性があります。 当初の推測は今のところ過剰にプロビジョニングされていますが、収集されるメトリクスと監視対象のホスト/コンテナの両方で急速に成長しています。
この時点で、テスト用に立ち上げたPrometheusサーバーは、以前と同じジョブを実行していたInfluxDBクラスタよりもはるかに信頼性が高かったため、単一障害点にならないように基本的な作業を行いました。 同じターゲットをすべてスクレイプする別の同一ノードを追加し、keepalived + DNS更新を使用したシンプルなフェイルオーバースキームを追加しました。 これは以前のシステムよりも可用性が高くなったため、顧客向けグラフをPrometheusを使用するように切り替え、古いシステムを廃止しました。
切り替え後、どのような改善が見られましたか？
以前のモニタリング設定は信頼性が低く、管理が困難でした。 Prometheusを使用することで、多くのメトリクスのグラフ化に適したシステムが実現し、チームメンバーは以前使用していたメトリクスシステムに触れることに警戒するのではなく、新しい使用方法に突然興奮しています。
クラスタも、2つの同一ノードだけでよりシンプルになりました。 成長するにつれて、より多くのPrometheusホストに作業をシャード化する必要があることはわかっており、これを行うためのいくつかの方法を検討しています。
ComposeとPrometheusの将来についてどう思いますか？
現在、以前のシステムで収集していたメトリクス（顧客コンテナの基本的なメモリ使用量と、独自の運用のためのホストレベルのリソース使用量）のみを複製しています。 次の論理的なステップは、データベースチームがDBコンテナ内からローカルのTelegrafインスタンスにメトリクスをプッシュできるようにすることで、スクレイプするターゲットの数を増やすことなくデータベースレベルの統計も記録できるようになります。
また、可視性を高めるためにPrometheusに導入したいシステムが他にもいくつかあります。 アプリをMesosで実行しており、基本的なDockerコンテナメトリクスは既に統合されていますが、これは以前よりも優れていますが、Mesosクラスタのインフラストラクチャコンポーネントの多くを中央のPrometheusに記録して、ロードバランサーからアプリメトリクスまですべてのサポートシステムの状態を示す一元化されたダッシュボードを作成できるようにしたいと考えています。
最終的にはPrometheusをシャード化する必要があります。 さまざまな理由から、顧客のデプロイメントは既に多くの小さなクラスタに分割されているため、1つの論理的なオプションは、単一のグローバルPrometheusサーバーではなく、クラスタごとに小さなPrometheusサーバー（または冗長性のためにペア）に移行することです。
ほとんどのレポートニーズでは、これは大きな問題ではありません。通常、同じダッシュボードで異なるクラスタのホスト/コンテナを必要としないためですが、保持期間がはるかに長く、各クラスタのPrometheusからのダウンサンプリングおよび集約されたメトリクスの数が少ない小さなグローバルクラスタを記録ルールを使用して保持する可能性があります。