tukaのブログ

気が向いた時に何か書きます

CREとしてちょっと痒いところを解消するツールを作ったお話

Mackerelチーム CRE(Customer Reliability Engineer)の id:tukaelu です。
この記事は Mackerel Advent Calendar 2023 の24日目の記事です。

MackerelのCREチームには「カスタマーサクセス」と「テクニカルサポート」の2つの役割があり、それぞれ専任のメンバーが所属しています。

いずれの役割においても、ユーザーから「これを実現するにはどうすればいいか」「こういった機能が欲しい」と言った質問やご意見・ご要望を貰うことが多いです。

CREはMackerelの中の人でありつつ、ユーザーの一人でもあります。「これがあったらいいな」「実現するとラクになるな」と思うものをプロダクトや公式のOSSにフィードバックしたり、個人のOSSとして公開しています。

直近だとアドベントカレンダー14日目で、同僚の id:kmuto が sabanote というツールを作って紹介していました。

kmuto.hatenablog.com

稚拙ながら自分もいくつか作った「まごの手」のようなツールがあるので、今回はそれらをご紹介します。

メトリックを簡単にCSV出力する「sabadashi」

Mackerelは監視対象のホストのメトリックを最小1分の粒度で保存していて、最大で過去460日間までさかのぼって閲覧(取得)ができます。
例えば1年前の同時期との状況比較を行うにも十分な期間だとは思いますが、バックアップとしてメトリックデータを残しておいて460日以降も負荷状況を確認したり、手元で独自に集計・分析したいというユースケースでCSV出力したいというお問い合わせやご要望をいただきます。

実は(?)メトリックデータは、Mackerel APIでJSON形式で取得ができます。

ホストのメトリックの値の取得 - Mackerel API ドキュメント (v0)

またAPIとのやり取りをラップしたCLIツールの mkr には gojq が組み込まれているので、オプションを使うことでCSV出力することはできるのですが、次のような点がユーザー視点で見ると一つのハードルになっているのではないかと考えました。

  • メトリックの系列ごとにAPIリクエストが必要
    • すべてのメトリック名を事前に知っておく必要がある
  • メトリックの粒度を意識すると、取得期間を意識して複数回APIリクエストを行う必要がある
    • このとき、取得期間の指定がUnixtimeになるのであまり直感的ではない
  • JSONからCSVへの変換が必要
    • jqでシュッとできるが若干の知識が必要

これらを意識せず、メトリックをCSVとして手元にダウンロードするツールとして sabadashi というCLIを作りました。

github.com

sabadashiはごく単純なツールで、ホストのメトリック名の一覧APIからメトリック名を割り出して、from/toで指定したYYYYMMDD形式の期間のデータをメトリックごとにCSVファイルに出力してくれます。
実際に実行するとこのような感じです。

$ sabadashi host --id <ホストID> --from 20230101 --to 20231224
🐟 Donwload host metrics (create 65 file(s))  34% [=======>            ]  [15s:29s]

プログレスバーが100%になるとダウンロード完了です。コマンドを実行した直下に<ホストID>/<from>_<to>でディレクトリが作成されて、メトリックごとにCSVファイルとして保存されているので、あとはよしなにできます。

$ tree <ホストID>
<ホストID>
└── 20230101_20231224
    ├── cpu.guest.percentage.csv
    ├── cpu.idle.percentage.csv
    ├── cpu.iowait.percentage.csv
    ├── cpu.irq.percentage.csv
    ├── cpu.nice.percentage.csv
    ├── cpu.softirq.percentage.csv
    ├── cpu.steal.percentage.csv
    :

ちなみにサービスメトリックの出力にも対応しています。
メトリックを手元にバックアップしたいといったニーズをお持ちでしたら、READMEを参考にぜひご活用ください!

カスタムメトリックの途切れを検知する「ikesu」

通常、システムメトリック*1が途切れると死活監視でアラートが発報します。サービスメトリックも監視ルールのオプションで途切れを監視できますが、カスタムメトリックについては途切れを監視する機能がありません。そのため、メトリックプラグインやクラウドインテグレーションによって投稿されたカスタムメトリックの途絶を検知できないという課題があり、こちらも要望を多く貰っていました。

この課題に対して id:kmuto が実験的なプロダクトとして mackerelio-labscheck-mackerel-metric というチェックプラグインを公開しました。その過程などは以下の記事で紹介されています。

developer.hatenastaff.com

時を同じくして、同じ課題に対してチェックプラグインとして個別に設定するのではなく、Mackerelのサービス・ロールでホストをまとめて管理するプラクティスに沿っていれば、まとめてチェックできるCLIがあると便利だと考え「ikesu」というツールを作りました。

github.com

サブコマンドのcheckでYAMLに定義したルールに従ってチェックできます。設定など詳細についてはREADMEに詳しく書いてあるのでご確認ください!

例えば、サービスdemo配下のvmというロールに属している mackerel-agent (provider=agent)で登録されたホストのカスタムメトリックcustom.foo.barが30分以上途絶している場合に、アラート通知するルールは以下のようになります。

---
check:
  - name: org:tukaelu
    service: demo
    roles:
      - vm
    interrupted_interval: 30m
    providers:
      - agent
    inspection_metrics:
      agent:
        - "custom.foo.bar"

実行するとこんな感じで標準出力にログがでます。

$ ikesu check --conf check.yaml

{"time":"2023-12-23T08:38:29.695526+09:00","level":"INFO","msg":"Run command","version":"v0.0.9 (rev.7fd4a3f)"}
{"time":"2023-12-23T08:38:29.695718+09:00","level":"INFO","msg":"CheckRule","name":"org:tukaelu"}
{"time":"2023-12-23T08:38:29.801593+09:00","level":"INFO","msg":"Retrieved target hosts.","service":"demo","roles":["vm"],"count":1}
{"time":"2023-12-23T08:38:29.801624+09:00","level":"INFO","msg":"Determine the provider of the host.","host":"XXXXXXXXXXX","provider":"agent"}
{"time":"2023-12-23T09:18:37.496561+09:00","level":"INFO","msg":"FetchHostMetricValues returns metric not found","hostId":"XXXXXXXXXXX","metricName":"custom.foo.bar","from":1703288917,"to":1703290717}
{"time":"2023-12-23T08:38:29.848636+09:00","level":"INFO","msg":"Starting to report the check monitoring results.","reports":1}

上記のケースはmetric not foundとあるようにメトリック途絶を検知していて、次のようなアラートが発報されます。

メトリックが途絶えているとこのようなアラートが発報します。

cronなどから定期的に実行するように設定するだけで、複数のホストをまとめてチェックできるので便利かと思います。
また一部のクラウドインテグレーションで登録されるホストでは、inspection_metricsで指定するメトリック名が自動的に決定されるようになっています。 *2*3
なお--show-providerオプションを実行すると、どのメトリックを自動的にチェックするか確認できます。

$ ikesu check --show-provider

Integration: aws
-----------------------------------
provider: alb                      , metric: custom.alb.request.count
provider: apigateway               , metric: custom.apigateway.requests.count
provider: aws/billing              , metric:
provider: aws/codebuild            , metric: custom.codebuild.builds.count
 :

ベータ版のためまだまだ改良余地はあるのですが、まとめてカスタムメトリックの途切れ監視をしたい場合は簡単に実現できると思うので、ぜひご活用ください!

また、今後もサブコマンドを追加予定ですのでお楽しみに…!

まとめ

今年要望をいただいた中から作った、Mackerelのちょっと痒いを解消するツールをご紹介しました。Issueなどでコメントいただけたら改善を進めるので、ぜひご意見・ご要望などいただければと思います!

余談ですが、sabadashi / ikesu のどちらのロゴもDTPデザイナーをしている妻に発注したのですが、ツールの役割を表現して描いてもらったのでその辺も注目していただけると嬉しいです!*4

Mackerel(鯖)からメトリック(出汁)を抽出しているイメージ

いけす(サービス/ロール)の周りを船に乗った人が監視しているイメージ

さて、2023年のMackerelアドベントカレンダーも明日で最終日。
明日は id:wtatsuru さんによる「2023年Mackerelのリリース100連発」です!

*1:mackerel-agentから投稿される標準的なメトリックです。

*2:固定値です。ただし確実にメトリックが投稿されている保証はないので、明示的に inspection_metrics を指定することをオススメします。

*3:固定でチェックしないものはメトリック名が空欄になっています。

*4:イメージを伝えたらシュッと描いてくれるので非常に助かり🙏