Weaveworks社とのインタビュー

Prometheusのユーザーへのインタビューシリーズを継続するにあたり、Weaveworks社のTom Wilkie氏が、同社がPrometheusをどのように選択し、現在どのようにそれを活用しているかについて語ります。

Weaveworks社について教えていただけますか？

Weaveworks は、オープンソースプロジェクトとSaaS（Software as a Service）を組み合わせてマイクロサービスを「運用可能」にするサービスである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の経験が豊富でした。また、SoundClouder出身者にはPrometheusの経験者もいました。我々はKubernetes上にサービスを構築しており、その動的にスケジュールされる性質と「適合」するものを探していました。そのため、Prometheusは当然の選択でした。我々は、PrometheusとKubernetesがなぜこれほど相性が良いのかというタイトルのブログ記事シリーズの最初の記事を執筆するほどです。

どのように移行しましたか？

Prometheusを使い始めた頃、KubernetesのサービスディスカバリはまだPRの段階であり、ドキュメントもほとんどありませんでした。我々はしばらくカスタムビルドを実行し、自分たちで解決していきました。最終的には、ロンドンのPrometheusミートアップで我々の経験について講演し、一連ののブログ記事を公開しました。

Prometheusの実行方法については、ほぼすべての異なるオプションを試しました。当初は、組み込み構成を持つ独自のコンテナイメージをビルドし、GrafanaとAlert Managerと共に単一のPodで実行していました。時系列データには、Pod内のエフェメラルストレージを使用していました。その後、ダッシュボードを変更するたびにPrometheus（および履歴）を再起動する必要がないように、これを異なるPodに分割しました。最近では、アップストリームイメージを使用し、Kubernetes config mapに構成を保存するように変更しました。これは、変更があったときにCIシステムによって更新されます。Prometheus Podに小さなサイドカーコンテナを使用して、設定ファイルを監視し、変更があったときにPrometheusに通知しています。これにより、Prometheusを頻繁に再起動する必要がなくなり、ストレージのために派手なことをする必要もなくなります。履歴を失うこともありません。

それでも、Prometheusの履歴を定期的に失うという問題は私たちを悩ませており、Kubernetesボリュームや定期的なS3バックアップなどの利用可能なソリューションにはそれぞれ欠点がありました。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で、これに関する講演を行う予定です。