Diary of a Perpetual Student

Perpetual Student: A person who remains at university far beyond the normal period

mackerel-agentの起動条件

arthur-1 Mackerel Advent Calendar 2023ラソン19日目の記事です。

本日はMackerel Meetup #15です!私は司会進行を務めさせていただきます。当日の申し込みも可能ですので、ぜひお越しください。

mackerelio.connpass.com

Advent CalendarはMeetupの日に合わせた特別なネタを用意していないので、いつも通り書きたいことを書いていきます。

mackerel-agentサービスの起動

Linuxにmackerel-agentをインストールするスクリプトを実行すると、systemdのサービスとして追加されます。

サービスの定義もmackerel-agentのソースコードを見に行くと分かります。例えば、以下のファイルはDebian系のOSで使われるサービスの定義ファイルです。

packaging/deb-systemd/debian/mackerel-agent.service

[Unit]
Description=mackerel.io agent
Documentation=https://mackerel.io/
After=network-online.target nss-lookup.target
...

ここで、Afterの行に着目してください。network-online.targetが含まれていることから、ホストのネットワークが利用可能になるまで、このサービスは起動を待機します。同様に、nss-lookup.targetが含まれているので、DNSが利用可能になるまで待ちます。

mackerel-agentプロセス起動時の処理

なぜmackerel-agentのサービスにはこのような依存関係が必要なのでしょうか?その理由は、mackerel-agentを起動させた後に最初に行う処理が関係していると考えられます。

mackerel-agentは起動時に以下の処理を行います(実際にはもっと複雑なのでかなり簡略化しています):

  • host idファイルがすでに存在する
    • そのホストが現在もMackerelに登録されているかチェックするリクエストを飛ばす
  • host idファイルが存在しない
    • Mackerelにホストを新規登録するリクエストを飛ばす

このチェックが完了し、Mackerel上のホスト情報と結びつけることができてから、常駐ソフトウェアとしての監視のroutineが始まります。もしここでMackerelのAPIにアクセスできないなどの状況になっている場合、mackerel-agentは異常終了します。

ネットワークが利用可能でない状態でサービスが立ち上がってもここの処理で異常終了してしまうため、先ほどのようなサービスの定義になっているというわけです。

agentとしてこの仕様では困る

私は、mackerel-agentが監視エージェントであるからこそ、この仕様は良くないと思っています。

例えば、Mackerelは計画メンテナンスを行うことがあります。すでにmackerel-agentが起動していれば、監視結果を最大6時間分までバッファリングし、Mackerelのメンテナンスが明けてから再送することができます。しかし、メンテ開始時までに起動していない場合は起動時の処理で落ちてしまうので監視を行うことができません。Mackerelのメンテナンス中にスケールアウトするのは避けるべき、ということになります。

メトリックを投稿することとメトリックを取得することは独立した処理であり、メトリックを投稿することができなくてもメトリックは取得できていてほしいです。そういう思想でバッファリングしていると思うのですが、起動時にはそれができていない、ということになります。Receiver・Processor・Exporterとコンポーネントを分けてそれぞれを疎結合に扱おうというOpenTelemetry Collectorの仕組みには改めてよくできているなと思わされます。

もちろん、このような仕様にもメリットがあります。systemctl statusコマンドの結果を見るとmackerel-agentがきちんとメトリックを投稿する準備ができているかわかります。

MackerelのOSSをコミュニティで進化させていきたい

私はmackerel-agentを改修したいと思うものの、これは根本を作り替えてしまうような大工事になることが予想されます。MackerelがOpenTelemetryへと移行していく中、9年以上の歴史があるmackerel-agentの改修に自分がどれだけ手を掛けられるのか分かりませんが、2024年中に解決したい課題の1つとして個人的には捉えています。

mackerel-agentはOSSなので、ユーザーの皆さまからのcontributionも受け付けています。本件に限らず、困り事があればぜひissueやPull Requestを気軽に立ててみてください。基本的に英語でやり取りをしていますが、相手は私か私と同じような血の通った人間ですので、怖がることはないでしょう。

もしどのように改修するか相談したい場合は、Mackerel MeetupやMackerel Drink Upなどのイベントで、実際にOSSのメンテナンスをしている開発者と会って話せます。

チームで監視を育てていくように、コミュニティで監視ツールも育てていきましょう。