こんにちは。Mackerel CREの 
id:do-su-0805 です。
はてなには2018年の9月にPlatform SREとして入社し、社内基盤や、社内のさまざまなサービスの運用を見たり作ったりしてきました。今年の5月からMackerel CREに異動し、主にテクニカルサポートとしてお客様からのお問い合わせに対応したり、ドキュメントを拡充したりしながら、よりMackerelを活用いただけることを目標に勤しんでいます。
さて、Mackerel Meetup #14 Tokyo開催までの期間で「Mackerel Meetup復活記念連載」と題して、Mackerelの新機能紹介などのブログ連載を実施しています。
今回は、Platform SREとしてMackerelを利用したサービス運用をしてきたり、Mackerel CREとしてテクニカルサポートを対応したりする中で見えてきた、知っているとMackerelをより活用いただけるTipsを6点、ご紹介いたします。
機能編
ミュートとダウンタイムの違いと、アラートグループを併用した際の挙動
Mackerelでは、ホストを対象とする監視において、対象となるホストのステータスによって監視や通知の実施を制御できます。また、監視ルールによる監視そのものや、監視ルールによるアラートの通知を停止する機能として、ダウンタイムとミュートが存在します。
下記に概念図を示します。ダウンタイムは「監視の停止」に該当し、監視自体を停止するため、通知も行われません。これに対し、ミュートは「通知の停止」に該当し、監視の結果通知のみを停止するため、Mackerelとしてはアラート状態となります（WebコンソールやAPIでアラートを確認できます）。
続いて、アラートグループについてのご紹介です。アラートグループは、サービスやロール、監視ルールを条件として、アラートをまとめることができる機能です。
例えば、複数のWebサーバから1つのデータベースに接続しており、データベースへの疎通の監視を行っている場合、その疎通に障害が発生すると、Webサーバ全台からアラートが発報してしまいます。このようなアラートをアラートグループにまとめることで、メールやslackといった通知チャンネルから個々のアラート通知が大量に届くのを抑制できます。
アラートグループは、対象となる監視ルールあるいはホスト群におけるアラートの発生状況をもとに通知を行います。そのため、アラートグループからの通知を抑制しようとする際、対象ホストをstandbyにしたり、監視ルールに対するミュートを設定したりしても、アラート自体は発報するため、アラートグループからの通知を抑制することができません。
アラートグループからの通知を抑制したい場合は、対象となるホストをmaintenanceやpoweroffにしていただくか、監視ルールのダウンタイムを設定することで、アラートが発報しなくなり、アラートグループから通知されなくなります。
不要なメトリックの投稿の抑制
Mackerelでは、登録されたホストに対して投稿されたメトリックの数による従量課金が発生します。スタンダードホストでは200メトリックごとに1ホストとして、マイクロホストでは30メトリックごとに1ホストとして、それぞれ計算されます。
そのため、内容が重複するメトリックや、お使いの環境では固定値で投稿されることがわかっているメトリックを投稿しないようにすることで、費用を抑制できる場合があります。
システムメトリックでは、disk・filesystem・interfaceの3つのメトリックにおいて、mackerel-agent.confにignore設定を追加することで、該当するディスクデバイスやインターフェースに関連するメトリックが投稿対象から除かれます。
システムメトリックにおけるignore設定については、mackerel-agent仕様 - Mackerel ヘルプ内の各項目をご覧ください（diskメトリックについては後日掲載予定です。MackerelのWebコンソールのサイドメニューが日本語化されました ほか - Mackerel お知らせ #mackerelioをご確認ください） 。
カスタムメトリックでは、configの[plugin.metrics.{name}]セクション内にinclude_patternとexclude_patternを設定することで制御できます。
include_patternではマッチしたメトリックを投稿、exclude_patternではマッチしないメトリックを投稿します。
include_patternおよびexclude_patternについては、以下ドキュメントをご覧ください。
グラフボード機能
連載前回で紹介したように、Mackerelには便利なダッシュボード機能があります。Markdownによる解説や現在時刻のメトリックの値を表示したり、式グラフといったさまざまなグラフを出したりして、特定の関心に対する情報をまとめることができます。
実はサービス画面にも、グラフ機能に特化した「グラフボード」という機能があります。
サービス画面を開き、「ロール」「サービスメトリック」と表示されている横の+をクリックすることで、グラフボードを作成できます。グラフボードには「ロールグラフ」「サービスメトリックグラフ」「式グラフ」の3種類を好きな順番に配置することが可能です。
ダッシュボードを作るまでもないけれども式グラフをちょっと見てみたいというときや、「全容はダッシュボード、詳細はサービス画面で見る」という運用にはマッチするのではないでしょうか。
グラフボードについては、グラフボードを利用する - Mackerel ヘルプ をご覧ください。
グラフ定義の差分値とgo-mackerel-pluginにおけるdiffの違い
Mackerelでのグラフの描画は、「グラフ定義」と呼ばれる設定に基づいて表示名や単位を制御しています。
この設定の中に「差分値」という設定があり、有効にするとMackerelが保有している前回のメトリックとの差分がグラフとして描画されるようになります。
グラフ定義についてはグラフの表示内容を変更するをご覧ください。
一方、カスタムメトリックプラグイン作成用のライブラリであるgo-mackerel-pluginにて、グラフ定義を作成するために利用するMetrics構造体の中にもDiffという変数がありますが、こちらはちょっと挙動が異なります。
Diffがtrueの場合には、mackerel-agentがプラグインを実行して取得できたメトリックの値と、mackerel-agentが保持している前回のメトリックとの差分値を計算した上で投稿するようになります。そのため、Mackerelとしては元々のメトリックを持っていない状態となります。また、差分を計算して投稿しているため、Diff設定はグラフ定義における「差分値」設定とは関係がないことにも注意が必要です。
go-mackerel-pluginについてはgo-mackerel-pluginを利用してカスタムメトリックプラグインを作成する - Mackerel ヘルプをご覧ください。
プラグインご利用の際に、期待したメトリック値と大きく異なる結果になったときには、表示されているグラフに紐づくグラフ定義を確認したり、プラグインのMetricsの定義の実装を調査したりすることで、意図した投稿内容かどうかの判断ができます。また、プラグインを作成される際には、Diffを使うことで、差分値を計算した上で投稿する機能もご活用いただけるでしょう。
運用編
AWSインテグレーションによるALB連携時のalb_XXXメトリックとtarget_XXXメトリック
AWSインテグレーションを利用し、ALBを連携した際のメトリックに関する注意点です。
レスポンスコードに関するメトリックとして、alb.httpcode_count.alb_{4,5}XX（以下alb_XXX）と、alb.httpcode_count.target_{2,3,4,5}XX（以下target_XXX）が存在します。
詳しい内容はAWSのドキュメント(Application Load Balancer の CloudWatch メトリクス - Elastic Load Balancing)をご確認いただけたらと思いますが、簡易的な解説として、alb_XXXは「ALB自身が(基本的にTargetの応答に関係なく)応答したHTTPステータス」であり、target_XXXは「ターゲットが応答し、ALBがそのまま応答したHTTPステータス」となります。
よくあるケースとして、ターゲットからの5XX応答を確認したいのにalb_5xxを監視してしまったり、ALB全体が応答した5XXの数の割合をSLIとして使おうとするときにalb_5xxを足し忘れてしまったり、といったことがあります。
取り間違えず、適切なメトリックを用いるようお気をつけください。
プラグインのタイムアウトとmackerel-container-agentでのゾンビ処理
mackerel-agentならびにmackerel-container-agentがプラグインを実行するとき、timeout_seconds秒（デフォルト30秒）の間に実行が完了しなかった場合はタイムアウトと判定し、プラグインに対して終了処理をかけるようになっています。具体的にはUnix環境ではシグナルSIGTERMを送り、10秒後までに終了しなかったらさらにSIGKILLを送ることでプラグインを強制終了させます。
タイムアウトまでの秒数のtimeout_secondsは、mackerel-agent.confの設定で変更可能です（SIGKILLが送られるまでの秒数である10秒は変更できません）。
メトリックプラグインでは1分ごとに実行されることから、60秒以上実行されていても意味はないため、60秒未満までが現実的な延長可能時間です。チェックプラグインでは、チェック監視の設定間隔であるcheck_intervalに合わせて柔軟に設定することが可能です。
以上がプラグイン実行のタイムアウト時の挙動になるのですが、mackerel-container-agentにおいては、実行したプラグインがタイムアウトして強制終了させられると、ゾンビプロセスとしてコンテナ内に滞留します。これは「PID1問題」と呼ばれる事象であり、mackerel-container-agentがゾンビ回収機能を持ち合わせていないために発生します。
対策としては、お使いの環境で、docker --init相当の設定を入れる、init相当のものをPID1として実行するようにイメージを作成する、といった方法でゾンビプロセスが回収されるようになります。Amazon ECSの場合は、initProcessEnabledというパラメータをtrueにすることで、docker --initと同等の処理がECS上で実行されます。
timeout_secondsやcheck_intervalについては、ホストのカスタムメトリックを投稿する - Mackerel ヘルプやチェック監視項目を追加する - Mackerel ヘルプをご覧ください。
まとめ
駆け足でしたが、Mackerelをより活用するために知っていただきたいTipsを6点、ご紹介させていただきました。
Mackerelにもさまざまな機能が増えたり、多種多様な環境にてご利用いただく中で、細かい部分がお伝えきれてなかったり、たどりつきにくい状況になっているかもしれません。今後も皆様のお声を参考に、仕組みやドキュメントなどを改善し、使いやすいMackerelを目指してまいります。
[PR] Mackerel Meetup #14 Tokyo を開催します
Mackerel Meetup #14 Tokyoを2023年7月11日（火）に開催します。Mackerelの開発状況の共有や情報交換を行うオフラインイベントが4年ぶりに帰ってきました！ Mackerelユーザーによるご講演もあります。ぜひご参加ください。
会場にてお待ちしておりますので、ぜひ実際に利用されている皆様のお声をお聞かせください！
