Prometheusユーザーへのインタビューシリーズを続け、CanonicalはPrometheusへの移行について語ります。
自己紹介とCanonicalの事業内容について教えてください。
Canonical は、おそらくUbuntu Linuxのスポンサー企業として最もよく知られています。MAAS、Juju、OpenStackなど、他の多くのオープンソースプロジェクトも制作または貢献しており、これらの製品の商用サポートを提供しています。Ubuntuは、OpenStackデプロイメントの大部分を支えており、本番環境クラウドの55％、大規模クラウドデプロイメントの58％を占めています。
私のグループであるBootStackは、フルマネージドのプライベートクラウドサービスです。Canonicalのお客様向けにOpenStackクラウドを構築および運用しています。
Prometheus導入以前のモニタリング経験はどのようなものでしたか？
Nagios、Graphite/statsd、そして社内製のDjango アプリケーションを組み合わせて使用していました。これらは、社内および顧客のクラウド環境の両方で必要とする柔軟性とレポート機能を提供していませんでした。
なぜPrometheusを検討することにしたのですか？
InfluxDB やGraphiteの利用拡張など、いくつかの代替案を評価しましたが、Prometheusを初めて使用した際に、求めていたシンプルさと強力さを兼ね備えていることが証明されました。特に、ラベルの利便性、シンプルなHTTPプロトコル、そしてすぐに使える時系列アラートは高く評価しています。Prometheusによって、2つの異なるツール（アラートとトレンド分析）を1つに置き換えられる可能性は、特に魅力的です。
また、Googleに在籍していた頃のBorgmonの経験を持つスタッフが複数名おり、Prometheusへの関心がさらに高まりました。
どのように移行しましたか？
現在も移行プロセス中です。既存システムで使用しているカスタムチェックの数が多く、Prometheusで再実装する必要があるため、移行には時間がかかると予想されます。最も役立ったリソースは、prometheus.io サイトのドキュメントです。
エクスポーターの選択には時間がかかりました。当初はcollectd を選択しましたが、制限に遭遇しました。現在、openstack-exporter を開発していますが、エクスポーターをゼロから作成する方法の良い実例がないことに少し驚きました。
遭遇した課題としては、ダウンサンプリングの未対応、長期保存ソリューションの未提供（現状）、そしてデフォルトの2週間の保存期間に驚きました。現在Jujuとの連携はありませんが、開発中です！
切り替え後、どのような改善が見られましたか？
エクスポーターのコツをつかむと、非常に簡単に記述でき、非常に有用なメトリクスが得られることがわかりました。たとえば、クラウド環境向けのopenstack-exporterを開発しています。また、DevOps、WebOpsグループ、開発者から非常に迅速にチーム横断的な導入が見られました。まだアラートは実装していませんが、移行のこの段階に到達すれば、さらに多くのことが期待できます。
CanonicalとPrometheusの将来はどうなると思いますか？
Prometheusは、モニタリングとレポートインフラストラクチャの重要な部分を担い、多数の現在および将来のシステムにメトリクスの収集と保存を提供すると考えています。 Nagiosをアラートとして置き換える可能性もあると考えています。