Canonical インタビュー

Prometheus ユーザーへのインタビューシリーズを継続して、Canonical がどのように Prometheus への移行を進めているかについて語ってくれました。

自己紹介と Canonical がどのような会社か教えていただけますか？

Canonical は、おそらく Ubuntu Linux をスポンサーしている会社として最もよく知られています。また、MAAS、Juju、OpenStack を含む数多くの他のオープンソースプロジェクトを生成または貢献しており、これらの製品の商用サポートを提供しています。Ubuntu は、本番環境のクラウドの 55%、大規模クラウドデプロイメントの 58% の OpenStack デプロイメントの大多数を支えています。

私のグループである BootStack は、弊社の完全マネージドプライベートクラウドサービスです。Canonical の顧客のために OpenStack クラウドを構築・運用しています。

Prometheus導入前のモニタリング経験について教えてください。

私たちは、Nagios、Graphite/statsd、そして社内のDjango アプリケーションの組み合わせを使用していました。これらは、社内および顧客のクラウド環境の両方で必要とされる柔軟性とレポート機能のレベルを提供してくれませんでした。

Prometheusを検討することにした理由は何ですか？

いくつかの代替案を評価しました。InfluxDB や Graphite の使用を拡張することも含めていましたが、Prometheus との最初の経験から、探していたシンプルさとパワーの組み合わせを持っていることが証明されました。特に、ラベルの利便性、シンプルな HTTP プロトコル、そして標準装備の時系列アラートを高く評価しています。Prometheus が 2 つの異なるツール（アラートとトレンド）を 1 つに置き換える可能性は特に魅力的です。

また、弊社のスタッフの何人かは、Google 在籍時に Borgmon を使用した経験があり、これが弊社の関心をさらに高めました。

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

移行プロセスはまだ進行中ですが、既存システムで使用しているカスタムチェックの数が多いため、Prometheus で再実装する必要があり、時間がかかると予想しています。最も役立ったリソースは、prometheus.io サイトのドキュメントでした。

Exporter の選択にしばらく時間がかかりました。当初はcollectd を使用しましたが、これには限界がありました。現在、openstack-exporter を作成していますが、Exporter をゼロから作成する方法の良い、動作する例が見つからなかったことに少し驚きました。

直面した課題の一部は次のとおりです：ダウンサンプリングのサポートがない、長期ストレージソリューションがない（まだ）、そしてデフォルトの 2 週間の保持期間に驚きました。現時点では Juju との連携はありませんが、取り組んでいます！

切り替え以降、どのような改善が見られましたか？

Exporter の使い方を理解してからは、非常に簡単に書けることがわかり、非常に有用なメトリクスが得られました。例えば、クラウド環境向けの openstack-exporter を開発しています。また、DevOps、WebOps グループ、開発者から非常に迅速なチーム間での採用が見られました。まだアラートは設定していませんが、移行のこの段階に進むと、さらに多くのことが期待できるでしょう。

Canonical と Prometheus の将来について、どのようにお考えですか？

Prometheus は、現在のそして将来の多数のシステムのメトリクス収集とストレージを提供する、弊社の監視およびレポートインフラストラクチャの重要な部分になると予想しています。アラートに関しては、Nagios を置き換える可能性があると考えています。