Prometheusユーザーへのインタビューシリーズを続け、WeaveworksのTom Wilkie氏がPrometheusを選択した経緯と、現在どのようにPrometheusを活用しているかについて語ります。
Weaveworksについて教えてください。
Weaveworksは、オープンソースプロジェクトとSaaSを組み合わせたWeave Cloudを提供し、マイクロサービスの運用を支援しています。
Weave Cloudは以下で構成されています。
- Weave Scopeによる可視化
- Weave Fluxによる継続的デプロイ
- コンテナSDNであるWeave Netによるネットワーキング
- オープンソースの分散型Prometheus-as-a-ServiceであるWeave Cortexによるモニタリング
Weave Cloudは60日間無料でお試しいただけます。製品の最新情報については、ブログ、Twitter、またはSlack（招待）をご覧ください。
Prometheus導入前のモニタリング環境はどのようなものでしたか？
Weave Cloudはゼロからの実装であり、以前のモニタリングシステムはありませんでした。チームメンバーは以前、MuninやNagiosといった一般的なツールを使用していました。Weave Cloudは、Scopeのマルチテナントホスティングバージョンとしてスタートしました。ScopeにはCPUやメモリ使用量などの基本的なモニタリング機能が含まれているため、それを使用していたと言えるかもしれません。しかし、Scope自体を監視する必要がありました...
Prometheusを検討することにしたのはなぜですか？
Google SRE出身のメンバーが多数在籍しており、Borgmonの経験が豊富でした。また、SoundCloud出身のメンバーはPrometheusの経験がありました。私たちはKubernetes上にサービスを構築し、その動的なスケジューリングの性質に「適合」するものを探していました。そのため、Prometheusは当然の選択でした。私たちはブログ記事シリーズも書いており、PrometheusとKubernetesがなぜうまく連携するのかが最初の投稿です。
どのように移行しましたか？
Prometheusを使い始めた頃、Kubernetesのサービスディスカバリはまだプルリクエストの段階で、ドキュメントもほとんどありませんでした。しばらくの間、カスタムビルドを実行し、試行錯誤しながら独自に解決策を見つけました。最終的に、ロンドンPrometheusミートアップで私たちの経験について講演し、一連のブログ記事を公開しました。
Prometheusを実行するためのあらゆるオプションを試しました。最初は、設定を埋め込んだ独自のコンテナイメージを構築し、GrafanaとAlert Managerと一緒に単一のPodですべて実行しました。時系列データには、一時的なPod内ストレージを使用しました。その後、ダッシュボードを変更するたびにPrometheusを再起動（そして履歴を失う）する必要がないように、これを異なるPodに分割しました。最近では、アップストリームイメージを使用し、設定をKubernetesコンフィグマップに保存するように移行しました。これは、設定を変更するたびにCIシステムによって更新されます。Prometheus Podの小さなサイドカーコンテナを使用して、設定ファイルを監視し、変更があった場合はPrometheusにpingを送信します。そのため、Prometheusを頻繁に再起動する必要がなく、ストレージに特別なことをする必要もなく、履歴を失うこともありません。
それでもPrometheusの履歴を定期的に失うという問題は私たちを悩ませ続け、Kubernetesボリュームや定期的なS3バックアップなどの利用可能なソリューションはすべて欠点がありました。Prometheusを使用してScopeサービスを監視した素晴らしい経験と相まって、これはクラウドネイティブの分散型Prometheus、つまり履歴を失うことなくアップグレード、シャッフル、ホスト障害を乗り越えることができるPrometheusを構築する動機となりました。こうしてWeave Cortexが誕生しました。
切り替え後、どのような改善が見られましたか？
Cortexはさておき、HA Alert Managerの導入は特に喜ばしいものでした。それは主に、ゴシップと調整レイヤーであるWeave Meshを使用した最初のWeaveworks以外のプロジェクトの1つだったからです。
また、Fabianによるバージョン2のKubernetesサービスディスカバリの変更にも特に熱心でした。これは、同じPodの複数のポートをスクレイピングする必要があったConsul Podの監視で発生していた深刻な問題を解決しました。
そして、リモート書き込み機能（私自身が取り組んだもの）について触れないわけにはいきません。これにより、PrometheusはWeave Cortex自体の重要なコンポーネントとなり、ターゲットをスクレイピングしてサンプルを送信します。
WeaveworksとPrometheusの将来についてどのように考えていますか？
私にとっての当面の将来は、WeaveworksのPrometheus as a ServiceであるWeave Cortexです。社内では広く活用しており、かなり良好なクエリパフォーマンスを実現し始めています。現在、実際のユーザーがいる本番環境で稼働しており、まもなくアラートのサポートを導入し、アップストリームPrometheusとの機能パリティを実現する予定です。そこから、年央の一般提供に向けて、ベータプログラムによる安定化に入ります。
Cortexの一部として、PromQLのオートコンプリートとJupyter風のノートブックを備えた、インテリジェントなPrometheus式ブラウザを開発しました。より多くの人々にこれを使ってもらい、最終的にはオープンソース化することを楽しみにしています。
Lokiという小さなサイドプロジェクトもあります。これは、PrometheusのサービスディスカバリとスクレイピングをOpenTracingにもたらし、分散トレーシングを簡単かつ堅牢なものにします。3月末にベルリンで開催されるKubeCon/CNCFConでこれについて講演します。