MicrometerからCloudWatchにメトリクスを送信する

2020/02/20

java 監視

t f B! P L

Spring Boot でプログラム内部のメトリクスを収集するときに使われるMicrometer。収集したメトリクスをどうやって活用するか(どのサービスで監視・グラフ化するか)考えた結果、AWS CloudWatchを使うことにした。

Prometheusは運用できない

監視といえば、Prometheus - Monitoring system & time series databaseがここ数年人気だ。

「差別化する必要がなければメジャーに乗っかれ」というポリシーで、Prometheusももちろん使ってみようとした。しかし、運用してくれるサービスが見当たらない。運用に関われるエンジニアが少ないので、監視関連に人的リソースを割くのは可能な限り避けたい。となると、残念ながらPrometheusは候補から外れる。普段であればMackerel(マカレル)を使うのだが、今回は1分よりも短い間隔でメトリクスを送信することも考えていたため、他の方法を検討することにした。

Mackerel(マカレル): 新世代のサーバー管理・監視サービス

はてなが開発した新世代のサーバー管理・監視サービスです。仮想サーバーなどクラウドサービスをMackerelで統合管理および監視ができます。フリートライアル実施中!

CloudWatch連携は可能なのか?

AWSで動いているプログラムのメトリクスの収集なので、CloudWatchを利用できないか検討するのが自然な流れだろう。ということでMicrometerのdocsを見てみたのだが、PrometheusはあってもCloudWatchはなかった。一方、micrometer/implementations at master · micrometer-metrics/micrometer · GitHubを覗いてみると、cloudwatchとcloudwatch2が存在しているものの、どう違うのかわからない。そもそも、docsに出てこない時点で注意が必要だ。

CloudWatch エージェントはStatsDプロトコルを使用できる

CloudWatchエージェントでは、StatsDプロトコルを用いてカスタムメトリクスを取得することができる。Micrometerのdocsを見ると、StatsDはサポートしているモニタリングシステムに含まれている。

micrometer+StatsD -> CloudWatch Agent -> CloudWatch

という構成で、Spring BootアプリケーションのメトリクスをCloudWatchに送信できることがわかった。
micrometer側(Spring Boot側)の設定は問題ないだろう。CloudWatchエージェントは自ホスト(localhost)で動かすので、自ホストにあるStatsDに向けてメトリクスを送信するようにすればOK。

となると、CloudWatchエージェントの設定をどうするか。
ググってみると、CloudWatchAgentのStatsDを試してみる - Qiitaという記事が見つかった。

CloudWatchAgentのStatsDを試してみる - Qiita

CloudWatchAgentを設定をしていると、statsDとかcollectdとか名前が出てきますが、どうやらOSSの数値レポーティングツールらしいです。 prometheusを主に使っているので困ったことがなくて所見ですが、今...

が、対話式の設定ツールでポチポチ設定するのが許されるのは、お試しのときだけ。設定は
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
に行う。 パラメータについては、StatsD を使用したカスタムメトリクスの取得 - Amazon CloudWatchを参照。説明が多いが、上記サンプルの項目を確認すれば十分だ。メトリクスの取得間隔とCloudWatchへの送信間隔の設定もある。

直接CloudWatchに送れるのは嬉しい

CloudWatchエージェントが必要とはいえ、他のサービスを経由せずにCloudWatchにメトリクスを送れるのは便利だ。イベントブリッジを使えば外部サービスからCloudWatchにイベントを送信することができるが、利用サービスが多い=障害ポイントが多い という認識なので、AWSに直接送れるというのはメリットだ。
また、CloudWatchに送れば、AutoScalingやLambdaの起動など、AWSの持っている仕組みをスムーズに使うことができる。CloudWatchはデータのグラフ化が弱いという印象だが、それも改善されるだろう。

CPU利用率やディスクの空き容量などのインフラ側のメトリクスはよく収集されるが、プログラム内部のメトリクス、例えば、外部API呼び出しの時間や受け付けたHTTPリクエストの数などは、あまり収集されていないという印象だ。Micrometerを使えば送信先のサービスはjarを入れ替えるだけで済むので、もっと内部のメトリクスを収集するような流れになってほしい。


楽天で探す
楽天市場
にほんブログ村 IT技術ブログへ

人気の投稿

ブログ アーカイブ

自己紹介

開発からSREにクラスチェンジしました。

アフィリエイト

  • 当ブログ「Hiroaki's blog」は、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、Amazonアソシエイト・プログラムの参加者です。
  • 当ブログでは、第三者配信による広告サービスを利用しています。このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 (氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。このプロセスの詳細やこのような情報が広告配信事業者に使用されないようにする方法については、ここをクリックしてください。
  • アクセストレードアフィリエイトプログラムに参加しています。
  • A8.netアフィリエイトプログラムに参加しています。
  • バリューコマースアフィリエイトプログラムに参加しています。
  • もしもアフィリエイトプログラムに参加しています。

プライバシーポリシー

当サイトにアクセスされる場合、IPアドレスなどの情報または閲覧状況に関するデータが機械的に生成され、場合によっては個人情報と関連付けられる可能性があります。プライバシー保護に関する適用法に準じて、これらの通信および閲覧に関するデータを収集、処理、および利用することがあります。
当サイトにアクセスされる場合、非個人情報(ブラウザの種類、OSの種類、ドメイン名、訪問数、平均滞在時間、ページ・ビューなど個人を特定できない情報)が自動収集される場合があります。当サイトのパフォーマンスやコンテンツを改善する目的で、これらの情報を利用する場合があります。
アフィリエイトでは成果を把握するためにcookie等を利用しています。それ以外の目的で使用されることはありません。詳しくは各社のページにて確認してください。
本サイトに掲載する情報に関しては、正しいものを提供することを務めていますが、掲載内容から、いかなる損失や損害などの被害が発生しても、当ブログでは責任を追いかねます。

QooQ