オブザーバビリティを実現するために――メトリクスの実用例を紹介
このように便利で使いやすいツールであるメトリクスだが、限界もある。第一は非常に高いカーディナリティのデータには向かないこと。requeset.countをユーザーごとに見るのはその一例だ。「どういうユーザーがどのぐらいのリクエストを出しているか見るために、ディメンションを安易に追加してしまうと、カーディナリティが爆増してしまい、クエリも時間がかかるようになる」（大谷氏）
メトリクスの実用例として、StatsDの活用が挙げられる。StatsDは2011年ぐらいからブログなどでも紹介されている、UDP/TCPで送信されるカウンターやタイマーなどのメトリクスを受け付け、Graphiteなどのバックエンドの時系列データベースなどに送信するサービスである。
インターフェースはシンプルなので、「いろいろな言語のクライアントに実装やインテグレーションされている。かなり歴史あるツールだが、現在もさまざまな現場で活躍しているのではないか」と大谷氏は言う。
StatsDはGraphiteやOpenTelemetry Collector、Prometheusとも容易に連携できる。例えばOpenTelemetry Collectorであれば、2行ほど追加するだけで、メトリクスがレポートできるようになる。「詳しく知りたい方は、『入門OpenTelemetry Collector』で検索すると私の過去コンテンツが読めると思う」と大谷氏。
また、SaaSによっては「利用料金が跳ね上がることもあるので、注意が必要」と大谷氏は警鐘を鳴らす。第二に、状況の把握には限界があること。例えばCPU使用率が上がったことは分かるが、その理由についてはメトリクスだけで把握することは難しい。だが、ログやトレースなど、他のテレメトリデータを合わせて利用することで、その限界を低減できる。
OpenTelemetry Collectorではなく、Prometheusを使っている人も増えている。そんな人にオススメなのが、Prometheus＋OpenMetricsという組み合わせ。Prometheusはメトリクスを扱う、オープンソースのシステム監視・アラームツールキットである。「特徴はpull型アーキテクチャであること」と大谷氏。
HTTPでリクエストを受け付けるexporterを監視対象に備えることで、エンドポイントにリクエストを出してその内容をよい加減で集計して、アラートを出したりダッシュボードに表示したりする。
「Kubernetesとの親和性がかなり高く、各種ツールとの連携も豊富。Prometheusの環境を整備すれば、ほぼメトリクスに関してはカバーできる。そんなエコシステムになっている」（大谷氏）
前述したように、Prometheusはexporterで監視対象からメトリクスを集約する。そのPrometheusのエクスポートの仕組みを切り出して、整理するためのプロジェクトがOpenMetricsである。「エンドポイントの仕様の整理をはじめ、メトリクス名やデータモデルの整理もしてくれる」（大谷氏）
Prometheusを使って何ができるのか。その例として大谷氏が示したのが、Spring Bootのサンプルアプリケーション「Spring PetClinic Sample Application」。これをそのまま動かすと、各サービスはMicrometerでメトリクスを計測され、micrometer-registry-prometheusでエクスポーズ、Prometheusがスクレイプし、Garafanaで可視化できる。「Prometheusの中身はシンプルだが、パワフルで拡張性が高い形で動かすことができる」（大谷氏）
さらにOpenTelemetryとPrometheus環境と組み合わせて使うことも簡単にできることもデモを通じて紹介。「opentelemetry-demo-webstore」を使えば、OpenTelemetry Collectorを通じて、PrometheusやJaegerで管理できる環境が比較的すぐに立ち上げられる。また、OpenTelemetry Collectorを少し変更するだけで、Splunk Observabilityをはじめ、任意のバックエンドにメトリクスをエクスポートできるようになる。「少しの変更で、Prometheusを使っている環境からバックエンドを切り替えることができる。それがOpenTelemetryを活用する面白さ」と大谷氏は語る。
最後に大谷氏は「メトリクスは古典的なツールだが、改めてそれがどんなツールなのか、それを理解した上で別のツールとどのように使い分けていけばいいのか、それらの点を意識して便利に使ってほしい」と語り、セッションを締めた。
