PrometheusとAWSのサービスを組み合わせてオブザーバビリティを実現

導入前の状況・課題

異常発生時に、事象や影響範囲の把握、原因の調査に時間がかかっていました。各種ログやAmazon CloudWatchなどのメトリクスを1つずつ確認する必要があり、迅速に解決することが難しい状況でした。

また、以下のような課題がありました。

1. URL単位でモニタリングできない
   CloudWatchで確認できるのは、ALBまたはターゲットグループ単位のメトリクスまでで、URL単位では確認できなかったです。
2. URL単位に確認したい場合、NginxのアクセスログをCloudWatch LogsやBigQueryで検索する必要がありました。
3. 検知できないエラーがあった サイト全体に影響を与えるようなエラーであれば、CloudWatchだけで十分検知できていましたが、特定のURLだけで少量発生したエラーやログも出力されていないようなエラーは検知できないことがありました。

目指していた状態

プロダクトのオブザーバビリティが確立されている状態。
異常発生時にどこで何が起きているかが手に取るように分かる状態。

• Amazon CloudWatch
• Datadog
• New Relic

導入の背景で書かせていただいた課題を迅速に解決できる点です。

• オブザーバビリティを実現するツールのデファクトスタンダードであること。
• GitHubで公開されている各種Exporterを使用することで、様々なメトリクスを簡単に収集できること。
• Exporterが公開されていない場合も、クライアントライブラリを使って簡単に自作できること。

導入によって上記の課題を解決することができました。

加えて、Prometheusを使用してURL毎にエラーやレイテンシを可視化することで、それまで見えていなかった問題が見えるようになり、UXの改善にも繋がりました。
また、前述のように、レイテンシが遅いURLトップ10を可視化することでエンジニア内で競うように改善が進んでいくという文化面での変化もありました。

やりたいことを実現するために独自のExporterを作成し、Prometheusにデータを流し込む必要がありました。

ただ、2週間ほどで後述のアーキテクチャ図の仕組みを構築することができたので、それほど大きな苦労ではありませんでした。

Prometheusを実行しているサーバーのディスクの使用率が100%になり、アラートが上がったことがあります。 マネージドサービスを使えば、そのような運用面もあまり気にしなくてよくなるので、今から使うならマネージドサービスを使うのがおすすめです。

Promethesから生まれたメトリクス形式は、現在ではOpenMetricsとして標準化され、その収集と可視化がオブザーバビリティ実現の必要条件になってきています。例えば、OpenMetricsは今ではDatadog、New Relic、Azmon CloudWatchなどの様々なサービスで扱うことができます。

また、各種メトリクスをOpenMetricsとして公開するフレームワークやライブラリも増えてきました。
興味のある方は活用を検討してみてください。