Diary of a Perpetual Student

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

監視ルールに名前空間を作る

テクノロジー Mackerel

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

MackerelチームではMackerelを使ってMackerelを監視しています。今日は、MackerelチームのちょっとしたMackerel運用テクニックをご紹介します。

数が多くなってきた監視ルールを整頓したい

監視が育っていくにつれ、監視ルールは純増していくことが多いでしょう。監視の数が増えてアラート通知が増えていくと、人々は通知を無視するようになってしまいます。不要な監視ルールの棚卸しをすることで、年末気持ちよく休暇を過ごすことができるでしょう。

個人的にMackerelのリソースの中で、よく触れる機会が多いにも関わらず検索性があまり高くないものがまさに監視ルールだと思っています。アラートやホストと異なり、監視ルール一覧では現在文字列検索しかできません。

1会社1organizationという運用形態を取る場合、自分が携わるサービス以外の監視ルールも共存することになります。自分のチームに関わる監視ルールの一覧を出せないと、棚卸しに苦労することになるでしょう。

また、特定の監視ルールは通知先を変える、といった設定をする時に、監視ルールの名前のリストを見て複数選択しなければなりません。

監視ルールはそれぞれ緊急度が違う

システムの可用性に100%関係し、かつ人間の対応が必要な監視ルールだけを設定するなら、発生したアラートは全て対応すべきもの、となりますが、実際にはそうではない監視ルールも設定することになるでしょう。キャパシティプランニングの参考にしたい、異常が起こっても自動で修復されるので対応が不要、緊急ではないもののいつかはやっておきたい、閾値を適当に決めたばかりでまずは様子を見たいなど、色々な理由があると思います。

すなわち、それぞれの監視ルールには、監視ステータスであるCritical、Warningだけでは表しきれない優先度（緊急度）の差があると考えます。

監視ルールごと通知チャンネルを変える（例えば、緊急で対応しなければならない監視のSlack通知ではメンションがつく）ことで表現することも可能ですが、やはり前述したように監視ルールの名前だけを見て通知チャンネルの設定をする難しさがつきまといます。

そこで、命名規則を導入する

監視ルールをグルーピングし、またその知識をチームで共有するために、Mackerelチームでは監視ルールに命名規則を設けています。

まず、先頭に優先度を表す文字列（Alert, Infoなど）を付与することで、対応が必要か・それが緊急かどうかがわかるようにしています。アラート通知に含まれる監視ルール名の先頭を一目見るだけで、アラート対応の優先度がわかる、というねらいです。

次に監視対象のサービス・ロールを表す文字列をつけ、サービスやロールごと監視ルールをグルーピングできるようにしています。最後に、監視を区別するための監視名をつけています。

これらのセクションの区切り文字もなんとなくではなく統一することで、プログラムが解析しやすい構造化文字列となり、Mackerel APIやMackerel Terraform Providerを用いた便利ツールを作る際に役立ちます。

社内でのSREingの標準化の一環

この監視ルールの命名規則は、はてな社内でチームを横断して社内技術を標準化することを目指したSRE標準化委員会で決定されたものになります。この取り組みの一環については、ちょうど最近興味深い座談会記事が公開されましたので、ぜひこちらもご覧ください。

hatena.co.jp

これを機能にする、というアイデアもある

現在命名規則を導入しているのは、監視名で頑張るworkaroundがなければ不便ということであり、すなわちなんらかの便利機能をMackerel公式として用意すべきではないか、と考えています。

僕個人の考えでは、大手パブリッククラウドのように、タグという概念を導入して汎用的にグルーピング機能を用意するのが良いのではないかと思います。例えば、監視ルールを指定して通知チャンネルを設定するときに、監視ルールを1つずつ指定するのではなく、特定のタグが付いているものをまとめて選べるとどうでしょうか。サービスやロールがより一般化されたようなイメージです。

一方で、監視の優先度などきちんと名前をつけてモデリングすることにより、ユーザーがより直感的に扱えるデザインに仕上げることもできるでしょう。例えば、Infoレベルの監視ルール・アラートという概念があり、CriticalやWarningより目立たない色で通知が来れば、監視ルール名に頼らなくてもただ様子を見たいだけのアラートであるということが直感的にわかると思います。

よろしければユーザーのみなさまにも、監視の運用ルールについてぜひお話を聞かせてください。

開発体験向上に拘る理由とMackerel Drink Upの野望

テクノロジー Mackerel

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

私は普段の開発の片手間に、CIやテストの改善を通して開発体験を向上させる活動をしています。

blog.arthur1.dev

また、普段のコーディングにおいても美しい設計を考え続けています。コードや仕様が難しいから開発者が改修するのを躊躇してしまう状態に陥りたくないからです。

これらの話題は直接的には我々開発者の利益となるものですが、周りめぐってユーザーの皆さまにより良い価値を届けることに繋がるのは想像に難くないでしょう。エンジニアが快適に開発ができる環境は素早いモノ作りを支援するのです。

話はガラッと変わりますが、Mackerel Meetupの復活を皮切りに、Mackerelのユーザーと我々開発者が会って話せるオフラインイベントを定期的に開催しています。中でもMackerel Drink Upは毎月1回のペースで開催しており、私もお休みをいただいている日でなければ会場のはてなオフィスに出向いて、ユーザーの皆さまと交流させていただいています。

2023年11月1日に開催されたMackerel Drink Up #14では、こんな一幕がありました：

id:arthur-1 がユーザーの要望をその場でライブコーディングして実装するイベントがありました。

mackerel.io

ユーザーの困りごとをヒアリングし、「Mackerelの現状のデザインの兼ね合いで今すぐの完璧な改善は難しいものの、この程度であればすぐできますよ」と返答しました。その後コーディングを行い、開発環境のWebアプリケーションを見せてこんな感じでどうかと伺いました。やはり構想だけでなく動くものが目の前にあると反応も変わってきます。

これはエンジニアとしてMackerelのイベントに参加する以上、いつかやってやるぞと思っていたことでした。この野望を抱いたきっかけのツイートがあるのでご紹介します：

ユーザーの要望を聞いて素早くアイデアをカタチにしていくのに、もちろん自分自身のエンジニアとしてのスキルを高めていくのも大事なことだと思います。しかし、これをチームで再現性のある形でできたらどんなに良いでしょう。

開発体験の向上は手段の1つで、他にも色々な要素が関わってきます。例えば、今年はMackerelのSREによってリリースフローが改善され毎日少ない手間でリリースできるようになりました。Mackerelのアプリケーションエンジニアとして、素早い価値提供のために自分ができることを引き続き考えて実践していきます。

Mackerelのメモ機能、活用してますか？

テクノロジー Mackerel

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

Mackerelにはいろんなところにメモがある

Mackerel上に存在する様々なリソースにはメモが設定できるようになっています。思いついたものをざっと挙げるだけでこんなにあります：

  • サービスのメモ
  • ロールのメモ
  • 監視ルールのメモ
  • アラートのメモ
  • アラート手動クローズ時のメモ（クローズ理由）
  • カスタムダッシュボードのメモ
  • APIキーのメモ
  • クラウドインテグレーション設定のメモ

これらのほとんどが汎用的なメモ機能として用意されており、ユーザーが自由に目的を定めて使うことができます。

しかし、典型的でかつ有用な活用方法があれば、それを意識してデザインや仕様を特化させ、各種メモをより便利な機能にすることができると考えています。場合によってはアラートクローズ理由のメモのように、単純なメモを超えて目的をはっきりさせた機能として切り出す選択肢もあるでしょう。

ということで、今回は自分が考えている各種メモの活用方法についてご紹介します。

監視ルールのメモ

監視ルールにはメモを設定することができ、このメモはアラート画面やアラート通知などで表示されます。

監視ルールのメモは、アラートが発生した時の対応手順や参照すべきドキュメントへのリンクを貼っておく場所として有用です。アラートが発生して通知が来ているのに気づいたけど、いざ対応しようとしてもどうしたら良いかわからない、という経験はありませんか？playbook や runbookのリンクを貼ることで、アラート通知を目にした人が迷わず初期対応にあたることができます。

また、そもそもアラートは何らかのアクションを取る必要ある緊急事態にのみ発報されるのが理想的だと考えています。なぜなら、不要なアラート通知が何度もやってきていると通知を無視する習慣ができてしまい、結果的に対応すべきアラートを見逃してしまう可能性があるからです。対応は不要だけどイベントとして知っておきたいので監視ルールや通知を設定する場合には、対応不要な旨を監視ルールのメモに書いておくと良いでしょう。

監視ルール一覧でもメモは表示されるので、定期的にメモが書いていない監視ルールを見つけて棚卸しするのもチームで監視を育てる手段として有用かと思います。

アラートのメモ

アラートのメモは、アラート対応にまつわる様々な情報を書いておくのに便利な場所です。ただ、アラートの対応となるとメモ機能では文字数が足りない・多人数で同時に編集できない、など不便と感じる点もあるでしょう。その場合には、別途Google DocumentやScrapboxなどのページへのリンクを貼ると良いでしょう。

Mackerel APIでも読み書きができるので、EventBridgeチャンネルなどを用いた連携により、自動で関連するログを持ってきてアラートのメモに書き込む便利ツールを作ることもできます。実際に面白法人カヤック様がprepalertというツールを開発して運用しており、Mackerel Meetup #14 Tokyoなどで事例を共有いただきました。

techblog.kayac.com

これはアイデアですが、GitHubのPull Requestテンプレートのように、監視ルールに設定を加えて、発報されるアラートのメモのテンプレートが設定される機能ができると面白いのではないかなと思います。以下のような文章が発報されるアラートのメモに自動で入っているイメージですね。

担当者: (ここを埋める)
障害対応ログURL: (ここも埋める)

APIキーのメモ

再びカヤック様のブログを参照しますが、秘密情報を管理する際には出どころを記録しておきましょうという話題があります。

techblog.kayac.com

自分はさらに、単方向のリンクではなく相互にリンクできるよう、シークレットストア→各サービスの秘密情報だけでなく、各サービスの秘密情報→シークレットストアと辿れるように各サービスに記録すべきだと考えています。このルールを徹底すれば、秘密情報をローテートする際の影響調査がぐんと楽になるでしょう。

MackerelのAPIキーにはメモが書けるので、どのホストで使われているか、どのシークレットストアに登録されているかなどの情報を記録することができます。

いかがでしたか？

冒頭に述べた通り、メモの具体的な活用事例を集めることで、メモ機能のデザイン改善のアイデアが生まれることを狙っています。

実際に以下のリリースノートにて、アラートメモの活用方法に関するフィードバックを受けて、メモに含まれるURLをクリック可能にした事例が掲載されています：

mackerel.io

Mackerelユーザーの皆さまにもMackerel MeetupやDrink Up、あるいはMackerel Advent Calendarで、メモの活用例を共有いただけますと幸いです。

監視ツールのカウンタへの向き合い方

テクノロジー Mackerel

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

カウンタ

監視で参照したい値の種類の1つにカウンタがあります。カウンタとは時間が経過するごとに累積して単調増加していく数量のことです。基本的には増加していくだけなのですが、特定のタイミングでカウンタがリセットされることもあります。

一番わかりやすい例はuptimeでしょう。サーバが起動してからの経過時間は単調増加していき、再起動するとカウンタが0に戻ります。

カウンタはその性質から、プログラム上ではunsigned integerとして表現されることが多いです。マイナスになることがないので、unsignedにすることでより大きな値を扱うことができます。

OpenTelemetry Metrics APIで実装されたメトリックの種別の1つとしても「Counter」が存在します。

カウンタの差分

カウンタそのものをメトリックとして監視サービスに投稿することもありますが、そのままでは扱いづらいこともあります。例えば、カウンタそのものを閾値を設定して監視する際には閾値を定期的に変えなければなりません。過去のグラフと現在のグラフを見比べるときも、絶対値が変わっているのでグラフの伸縮率なども違ってしまい比較しづらいこともあるでしょう。

そもそも、我々の興味の対象はカウンタそのものの値よりも、各時点でのカウンタの増加率だったり、他のカウンタの値と比較した割合であることがしばしばあります。

例えば、mackerel-agentがLinux OSからCPU使用率を取得するときに参照しているのは/proc/statという仮想ファイルなのですが、このファイルに直接CPU使用率が書かれているわけではありません。以下のように各種別（user, system, iowaitなど）ごとのCPU時間がカウンタ（すなわち、サーバが起動してからの累積のCPU時間）として記録されており、ここからCPU使用率を計算しています。

$ cat /proc/stat | grep cpu0
cpu0 82712 2186 88894 36369261 35961 0 20988 53626 0 0
$ cat /proc/stat | grep cpu0
cpu9 82720 2186 88904 36372456 35962 0 20989 53629 0 0

1分間隔を空けて2回実行することで、この1分間にどれだけCPU時間を消費したかがわかります。最新値から1分前の値との差分を取れば良いわけです。さらに1分間のトータル（user+nice+system+idle）のCPU時間を計算した上で割り算してあげると、各種別ごとのCPU使用率が得られます。

カウンタの差分はオーバーフローし得る

さて、単調増加するカウンタの差分は必ず正の値になりそうですが、そうもいかないことがあります。なぜならカウンタはリセットされることがあるからです。

カウンタがリセットされると0に戻り、その後測定するタイミングで0ではないにしろ前回の計測値よりは小さい値になっています。つまり、以下のような引き算が行われます。

var previous uint64 = 123456
var current uint64 = 30
diff := current - previous
fmt.Printf("%d - %d = %d\n", current, previous, diff)
// 30 - 123456 = 18446744073709428190

カウンタはunsigned intなので単純に引き算するとその結果もunsignedになるわけですが、カウンタがリセットされた場合には負のオーバーフローが発生してものすごく大きな値になってしまいます。

カウンタのリセットを検知していい感じにする

そこで、リセットされ得るカウンタの差分を取る際には、リセットされた（すなわち、現在値のほうが前回の値より小さい）時に0との差を差分とすると良いでしょう。

Prometheusのrate、irate関数などはこのような方針で実装されており、カウンタがリセットされてもオーバーフローしたり負の値になったりしません。

この手法では多少の誤差は許容することになりますが、この程度の誤差よりも計算結果がオーバーフローするデメリットの方がはるかに大きいです。閾値監視している時にあり得ないほどの大きな値として計測されアラートが発報されてしまいますし、平均値監視をするときも外れ値として大きく影響することになります。また、グラフも以下のようにオーバーフローした値が目立ち、他の変化が追いづらくなってしまうでしょう。

今年出したMackerelのOSSへのPRを見る

自分が今年MackerelのOSSに出したPRを振り返ると、カウンタのオーバーフローに関するものが2つもありました。

github.com

github.com

以上、監視ツールの中身がわかる話として楽しんでいただけたら幸いです。

mackerunn: runnで実行したシナリオ監視の結果をMackerelに投稿するツール

テクノロジー Mackerel

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

シナリオ監視したい！

Mackerelユーザーの皆様から、外形監視機能でシナリオ監視を行いたいと要望をいただくことがあります。ここで言うシナリオ監視とは、ユーザーが実際にサービスを利用するときと同様に、いくつかのURLへのアクセスや要素のクリックなどの一連の操作が成功するかどうかを定期的にチェックすることを指します。

例えば、

  • ログインページを表示する
  • フォームにログイン情報を入力する
  • ボタンを押すとログインされ、ホーム画面が表示される

といったシーケンスを外部から実行する、といった具合です。よりユーザと同じ目線でサービスが利用可能であるかどうかを知ることができます。

今回は、この機能をMackerelに導入するとどう嬉しいのかを体感するために、プロトタイプを作ってみました。

mackerunn = Mackerel + runn

その名も「mackerunn」です。

github.com

runnというシナリオテストツールでテストを実行し、その結果をサービスメトリックやチェック監視としてMackerelに送信するツールです。

runnのプロファイルから取得したelapsed timeやテスト結果をサービスメトリックに

シナリオ監視に失敗した場合にはチェック監視のアラートが発報される

runnは「ランエヌ」と読むそうですが、mackerunnは「マッカラン*1」と呼んでください。

mackerunnの使い方

残念ながらまだビルド済みバイナリを配布していないので、使ってみたい方はリポジトリをcloneして各自でビルドしてください。（余裕ができたらバイナリ配布予定です。）Go 1.21.3以上でビルドできます。

とりあえず一発動かしてみたいとき

$ git clone https://github.com/Arthur1/mackerunn.git
$ cd mackerunn/
$ export MACKERUNN_MACKEREL_APIKEY="your_api_key"
$ go run ./cmd/mackerunn -runbook testdata/test.yml -service test -hostID 12345ABCD
2023/11/23 16:13:23 succeeded

実行時には3つのオプションと1つの環境変数が必要です。

  • -runbook: runnのrunbook yamlの場所（サンプルとしてtestdata/test.ymlを用意してます）
  • -service: Mackerelのサービス名。サービスメトリックを投稿するために必要
  • -hostID: MackerelのホストID。チェック監視を行うために必要。どのホストに紐づけても良いですが、mackerunnを実行するホストのIDを指定しておくと良いでしょう
  • MACKERUNN_MACKEREL_APIKEY: MackerelのAPIキー

runnのrunbookは以下のようなyamlです。詳しくはrunnのドキュメントを参照してください。

desc: hogehoge
runners:
  req: https://blog.arthur1.dev
steps:
  test1:
    req:
      '/':
        get:
          body: null
    test: current.res.status == 200
  test2:
    req:
      '/test':
        get:
          body: null
    test: current.res.status == 404
  test3:
    req:
      '/':
        get:
          body: null
    test: current.res.status == 200

常駐させて定期的に監視させたいとき

cmd/mackerunnの代わりにcmd/mackerunndを実行すると、常駐アプリケーションとして動かせます。実際に運用する時にはこれをsystemdのサービスに登録することになるでしょう。オプションはmackerunnと同じです。

$ export MACKERUNN_MACKEREL_APIKEY="your_api_key"
$ go run ./cmd/mackerunnd -runbook testdata/test.yml -service test -hostID 12345ABCD
2023/11/23 16:13:23 succeeded
2023/11/23 16:14:23 succeeded
2023/11/23 16:15:23 succeeded
2023/11/23 16:16:23 succeeded
2023/11/23 16:17:23 succeeded

ぜひ使ってみて感想を教えてください。SNSでも良いですし12月にはMackerel Meetup #15 Tokyoもございます！荒削りなのでcontributeも大歓迎です。

*1:https://www.suntory.co.jp/whisky/macallan/about/

arthur-1 Mackerel Advent Calendar マラソン開会宣言

テクノロジー Mackerel

一人Mackerel Advent Calendarマラソンやります

Mackerel Advent Calendar 2022の運営をしていたid:arthur-1です。

今年2023年は運営を他の人に任せる代わりに25日分を一人で埋めてみようと思います。

まだ25ネタ思いついてないのでぜひ応援してください。Advent Calendarの枠もまだ余っているのでこちらも何卒よろしくお願いします。

qiita.com

きっかけ

きっかけは今年の3月まで遡ります。YAPC::Kyoto 2023にて、こんな一幕が：

喧嘩は買っていくスタイルなので、やります。

どんなことを書くか

主に以下のような内容で色々な記事を書いていきます：

今年リリースした新機能の紹介

ベタすぎて誰かと被ってしまいそうですが、自分なりに今年のリリース機能を紹介します。

開発の様子

Mackerelは開発者に会えるサービスであることを目指しています。

mackerel.io

中の人に物理的に会うというのも一つですが、広義にはオンラインでもブログなどのアウトプットから中の人の人柄や開発への思いが伝われば良いと思っています。

ということで、プロダクトそのものではなく開発の裏側や扱う技術の話についても書いていきます。

サーバー・システム監視一般の話題

Mackerelを超えた一般的なサーバー監視に関する話を書きます。OpenTelemetryやPrometheusの話を書くかもしれません。

Mackerelの活用TIPS

Mackerel開発チームはMackerelの監視にMackerelを用いています。我々の運用から得た、Mackerelをもっと便利に使うための活用TIPSをご紹介します。

Mackerelをより良くするアイデアやそのプロトタイプ

私は社内のグループウェアにMackerelの新機能や改善案をエントリにしてよく書いています。自分の中で温めていたネタや、社内にだけ公開していたアイデアを今回は公開ブログに書いていきます。

書いたものが将来実装されるとは限りませんが、可能な場合にはプロトタイプを用意してユーザーが試せるようにする予定です。

1日目はサラッと開会宣言をしたところでおしまいです。

明日は結構自信のあるネタなのでぜひ読んでください。

11月は技術書典かSalesforce World Tour Tokyoでお会いしましょう

日記 テクノロジー

id:arthur-1 に会える11月のイベント予告です。

技術書典15

2023/11/12（日）にオフライン開催される技術書典15に「はてな技術書典部」として出展しています。私はこちらのブースで当日頒布スタッフをしております。

techbookfest.org

自分は思い立ったら即このブログに書いてしまっているので、既出ネタかとびきり大きいネタしか用意できず、執筆には参加しておりません。しかし、どうやら他のスタッフが自分について触れているとかいないとか……

当日会場にてお待ちしております！電子版もございますので、こちらもぜひお読みください。

Salesforce World Tour Tokyo

2023/11/28（火）〜29（水）に開催されるSalesforce World Tour Tokyoのシアターセッションにて、私が登壇することになりました！

https://event.salesforce-japan.com/wttnov23/catalog

（個別ページのパーマリンクがないので、左上の検索窓で「1-TFT4」と入力してから虫眼鏡マークを押してみてください。）

「感謝を伝え合う社内Slackアプリ『はてなピアスター』の取り組み」と題しまして、第2回Slack活用アワードで優勝したこの取り組みについてお話しします。以前Hatena Developer Blogにてご報告させていたきましたが、今回はどのようにSlackアプリを作ったのかという開発手順についても詳しくご紹介する予定です。

developer.hatenastaff.com

Day 1の11/28にザ・プリンス パークタワー東京でお会いしましょう。

そして、最後に会えないけどイベント予告です。

Mackerel Drink Up #13

Mackerel Drink Up #13 Tokyo を2023/11/21（火）に開催します。AWSインテグレーションについて知りたい人、機能要望をしたい人など、ぜひはてな東京オフィスにお集まりください。

mackerelio.connpass.com

今回は日程の都合で私は不在ですが、前回の熱気が最高だったので今回も楽しく有意義な場になると良いなと思っています。