2023年に買ってよかったもの
年の瀬ということで、個人的に今年買って良かったモノたちを。
- 象印 オーブンレンジ EVERINO
- リカバリーウェア BAKUNE 上下セット
- ブレインスリープピロー
- アシダ音響 音楽用ヘッドホン ST-90-05-H/K
- パールライス 宮城県産 白米 だて正夢 5kg
象印 オーブンレンジ EVERINO
14年くらい使っていたSHARPのオーブンレンジが壊れてしまったので買い替えた。
庫内の高さがあまりない点（絶妙に低く感じる）が若干気になるけど、高機能なわりにフロントのUIがシンプルなところが気に入っている。
うきレジという付属のボウルを浮かせて調理する機能をまだ試せていないんだけど、先日グラタンを作った際にレンジとグリルを切り換えていい感じに調理してくれるレジグリ機能のおかげで短時間で調理ができて、料理体験の向上を感じた。
最近あまり料理をしなくなってしまったので、これを気に色々作ってみるかという気持ちになっている。やったるで。
リカバリーウェア BAKUNE 上下セット
諸事情で重めの睡眠障害と診断されてしまい、4月ころから眠るために試行錯誤をしていたのだけど、購入するか悩んでいたところ、そんなことを知らない妻から誕生日にプレゼントで貰ったリカバリーウェアがかなり良かった。
それまではUNIQLOのスウェットとか無印のパジャマを着用していたけど、リカバリーウェアに変えてからは恐らくプラシーボ効果も多少ありつつ、寝たときのつっぱり感がなくなったのと、やんわりと温かさを感じて心地よく眠れている。
こんなん何着あってもいいのだけど、お高くて気軽に買えないのが悩ましい。
ブレインスリープピロー
![[BRAIN SLEEP] ブレインスリープ ピロー (7グラデーション)](https://m.media-amazon.com/images/I/41-vjGB+Z1L._SL500_.jpg "[BRAIN SLEEP] ブレインスリープ ピロー (7グラデーション)")
こちらも不眠対策で購入。
それまではニトリで購入したホテル仕様（？）の枕を使っていたけど、首筋付近に感じるムレ感が気になって眠れないことが多かったので、お高いけど騙されたと思って買ってみたところ入眠時間がかなり早くなった。
枕をブレインスリープピローに変えてからは、横向きで寝ても耳が潰されている感がだいぶ軽減してかなり快適になった。値段がお高いのと枕は好みがあるので気軽に薦めづらいけど、悩んでいる方には個人的にオススメしたい。薬を飲んでいるのもあるけど、枕とウェアの効果にも助けられている。
アシダ音響 音楽用ヘッドホン ST-90-05-H/K
仕事中にイヤホンをすることが多かったせいか耳垂れが酷くなってしまい購入した。
Bluetoothの骨伝導イヤホンも使っていたのだけど、充電切れだったり相手側設備によっては中々聞き取りづらいケースが気になってしまい、これまでは締めつけ感が嫌でヘッドホンは敬遠していたけど、これはそれをあまり感じずに過ごせると評判だったので買ってみたら本当に良かった。
「mimimamo」というヘッドホンカバーもあわせて購入したのだけど、こちらもいい感じだった！
パールライス 宮城県産 白米 だて正夢 5kg
ずっとアイリスの無洗米を買っていたのだけど、手間はあるけどやはり普通のお米は美味しい。 いろいろ試した中で、だて正夢が美味しすぎて今年はこれを定期便している。
来年もたくさんお買い物できますように…🫠
CREとしてちょっと痒いところを解消するツールを作ったお話
Mackerelチーム CRE（Customer Reliability Engineer）の 
id:tukaelu です。
この記事は Mackerel Advent Calendar 2023 の24日目の記事です。
MackerelのCREチームには「カスタマーサクセス」と「テクニカルサポート」の2つの役割があり、それぞれ専任のメンバーが所属しています。
いずれの役割においても、ユーザーから「これを実現するにはどうすればいいか」「こういった機能が欲しい」と言った質問やご意見・ご要望を貰うことが多いです。
CREはMackerelの中の人でありつつ、ユーザーの一人でもあります。「これがあったらいいな」「実現するとラクになるな」と思うものをプロダクトや公式のOSSにフィードバックしたり、個人のOSSとして公開しています。
直近だとアドベントカレンダー14日目で、同僚の 
id:kmuto が sabanote というツールを作って紹介していました。
稚拙ながら自分もいくつか作った「まごの手」のようなツールがあるので、今回はそれらをご紹介します。
メトリックを簡単に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を作りました。
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-labs に check-mackerel-metric というチェックプラグインを公開しました。その過程などは以下の記事で紹介されています。
時を同じくして、同じ課題に対してチェックプラグインとして個別に設定するのではなく、Mackerelのサービス・ロールでホストをまとめて管理するプラクティスに沿っていれば、まとめてチェックできるCLIがあると便利だと考え「ikesu」というツールを作りました。
サブコマンドの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
さて、2023年のMackerelアドベントカレンダーも明日で最終日。
明日は 
id:wtatsuru さんによる「2023年Mackerelのリリース100連発」です！
（近況）少し重めの睡眠障害に悩まされております
ここ最近、原発性不眠症と診断され、だいたい毎日フラフラ*1しています。
初聞の際は「原発性」という響きに怖さを感じたのですが、いくつかある睡眠障害の症状のうち、以下の抜粋のような「寝ても眠れていない不眠症」と診断されてしまいました。
睡眠障害の代表といえる症状で、充分に眠る時間が確保できていても眠れない状態で、充分に眠る時間が取れない睡眠不足とは区別されます。 夜の寝つきが悪く、眠ろうとするとかえって目が冴えたり、途中で目がさめてしまう、普段より朝早く目が覚めるなどの症状が続くものです。*2
元から寝付きが悪い、中途覚醒する、早く起きてしまうということは長らくありはしたものの、特に日常に支障はなく生活していたのですが、それに大きな支障を与える「寝ても眠れていない」状態が加わりました。
医者から「若干重症だね」と言われてしまい現在治療中で、家族や同僚にととにかく周囲にご迷惑かけっぱなしで本当に申し訳ない。
詳細は割愛するけど、昨年たまたま通った別のクリニックで処方され続けた薬が原因で心身不調となり長らくダウンしていた*3のですが、その薬の影響により脳の興奮度合いが強くなってしまい、仮に睡眠導入剤などで寝付くことができても*4眠っている状態にはならず、毎日完徹しているような状態*5で疲れがまったく取れないとのことでした。
確かに酷い時は過去に経験した過労と同じ感じがしています。
何か環境を変えると突如良くなったり、そう上手くも行かないかもしれないので着実に治していくしかないのですが、一日も早くもとのように元気になってパフォーマンス取り戻していきたいです。
最近では新型コロナに続きインフルエンザも流行していたり、皆様もご自愛ください。
CloudWatch Logsのフィルター構文が正規表現に対応したのでcheck-aws-cloudwatch-logsプラグインで試してみた
2023年9月6日の What's New with AWS で、CloudWatch Logsのフィルターパターンの正規表現への対応が発表されました。
MackerelでもCloudWatch Logsの監視はcheck-aws-cloudwatch-logsプラグインを用いてできるのですが、正規表現の対応はCloudWatch LogsのAPI側のアップデートになるので、check-aws-cloudwatch-logsはそのままに条件指定だけ正規表現に変更して動作するか試してみました。
続きを読むMackerelのカスタムダッシュボードにアラートの一覧を表示する
このエントリはMackerel Advent Calendar 2022の24日目の記事です。
本エントリでは、MackerelのAPIを使ってカスタムダッシュボードに欲しいけど『ない』機能を補う代替機能のアイデアを紹介したいと思います。
TL;DR
カスタムダッシュボードのご紹介
Mackerelには、監視の運用に合わせたオリジナルのダッシュボードが実装できるカスタムダッシュボードがあります。
カスタムダッシュボードには以下の4種類のウィジェットが用意されているので、これらを組み合わせることでより自由度の高いダッシュボードを構成できます。
- グラフウィジェット
- 各種グラフが表示できる
- 数値ウィジェット
- 各種メトリックの最新の値を数値で表示できる
- Markdownウィジェット
- Markdown形式で自由に内容を記述できる
- アラートステータスウィジェット
- 特定のロールに所属している全てのホストのアラートステータスを表示できる
この4つのウィジェットだけでもダッシュボードを構成するのに充分ですが、ここにはないウィジェットで、次のようなウィジェットのご要望をよくいただきます。
どちらも2022年時点では対応していないのですが、アラートの一覧についてはMarkdownウィジェットで代用できそうなので、実装してみることにしました。
実装していく
この記事では主にLinux環境で動かすことを想定して、bashで実装します。他の環境、言語でももちろん実装できるので参考になればと思います。
必要なもの
bashやcurl以外に以下を事前にインストールしてください。
mkrのインストールはヘルプの手順が参考になります。
ダッシュボードを取得する
アラート一覧を表示したいダッシュボードを取得します。
あらかじめダッシュボードには、アラート一覧用のMarkdownウィジェットを登録しておいてください。
ダッシュボードの取得は、ダッシュボード取得API、mkrのどちらでもできます。
mkr dashboards pull
mkrの場合、カレントディレクトリにdashboards-<ダッシュボードID>.jsonが保存されます。ただ今回はローカルにファイルを残したくなかったので、curlでAPIを叩くようにします。
curl \
-X GET \
-s https://api.mackerelio.com/api/v0/dashboards/${DASHBOARD_ID} \
-H "Content-Type: application/json" \
-H "X-Api-Key: ${API_KEY}" \
-f
ダッシュボードの構成に合わせて、次のようなJSONがレスポンスされます。
{ "id": "xxxxxxxxxxx", "title": "毎日見たいダッシュボード", "urlPath": "xxxxxxxxxxx", "createdAt": 1234567890, "updatedAt": 1234567890, "memo": "", "widgets": [ { "type": "markdown", "title": "直近のアラート", "layout": { "x": 0, "y": 0, "width": 12, "height": 6 }, "metric": null, "graph": null, "range": null, "markdown": "ここにアラートの一覧を表示する。" }, { "type": "markdown", "title": "別のMarkdownウィジェット", "layout": { "x": 12, "y": 0, "width": 12, "height": 6 }, "metric": null, "graph": null, "range": null, "markdown": "こっちは更新されたくない。" } ] }
このダッシュボードには2つのMarkdownウィジェットが登録されていて、今回は「直近のアラート」というタイトルがつけられた方のウィジェットに対してアラート一覧を反映します。
ちなみにダッシュボードにはユニークに払い出されたIDを持ちますが、ウィジェットにはIDが払い出されません。そのため、ウィジェットのtitleをキーとして使用します。
アラートの一覧を取得する
現在オープンしているアクティブなアラートを取得します。
アラートの取得はアラート取得APIからできますが、 mkr を使うと次のような感じでいい感じにフォーマットされた内容が取得できます。
mkr alerts list
4Hrxxxxxx79 2022-12-07 03:10:32 CRITICAL 死活監視 IP-xxxxxxxx working [Service:Role] 4HrxxxxxxX3 2022-12-07 02:55:24 WARNING Service - Windows - CPU % cpu% 0.00 > 70.00 IP-xxxxxxxx working [Service:Role] 4HaxxxxxxSm 2022-12-01 14:47:30 CRITICAL Event Log CRITICAL: 0 warnings, 1 criticals. EC2AMAZ-xxxxxxx working [Service:Role]
アラートID、発生日時、アラートレベル、メッセージなどが含まれるので、今回はこれをそのまま使用します。
この結果をもとに、次のようにMarkdownでリスト化して各アイテムにアラートへのリンクを貼ることで、ダッシュボードからアラートを開けるので便利になりそうです。
- [アラートの情報](アラートへのリンク) - [アラートの情報](アラートへのリンク) :
mkr alerts listの結果のうち、アラートIDはリンクに、それ以外をアラート情報として一覧に表示する形式にしたいですが、awkを使うことで簡単に整形できます。
mkr alerts list | awk '{m="";for(i=2;i<=NF;i++) m=m $i " "; print "- [" m "](https://mackerel.io/orgs/オーガニゼーション名/alerts/" $1 ")"}'
- [2022-12-07 03:10:32 CRITICAL 死活監視 IP-xxxxxxxx working [Service:Role] ](https://mackerel.io/orgs/xxx/alerts/4Hrxxxxxx79) - [2022-12-07 02:55:24 WARNING Service - Windows - CPU % cpu% 0.00 > 70.00 IP-xxxxxxxx working [Service:Role] ](https://mackerel.io/orgs/xxx/alerts/4HrxxxxxxX3) - [2022-12-01 14:47:30 CRITICAL Event Log CRITICAL: 0 warnings, 1 criticals. EC2AMAZ-xxxxxxx working [Service:Role] ](https://mackerel.io/orgs/xxx/alerts/4HaxxxxxxSm)
この結果をMarkdownウィジェットに反映していきましょう！
ダッシュボードを更新する
取得したダッシュボードのJSONのうち、以下の条件にあてはまる要素の内容を生成したアラート一覧の内容で書き換えます。
typeがmarkdowntitleが直近のアラート
ここで役に立つのがjqです。次のように|=で代入することで内容を書き換えることができます。
jq '(.widgets[] | select(.type == "markdown" and .title == "直近のアラート") | .markdown) |= "整形されたアラート一覧のMarkdown"'`
これをダッシュボード更新APIから定期的に更新することで、カスタムダッシュボードにアラート一覧を表示できます。
完成したスクリプト
これらを組み合わせたBashスクリプトが次のようになります。
#!/bin/bash
API_KEY=APIキー
ORG_NAME=オーガニゼーション名
DASHBOARD_ID=ダッシュボードID
WIDGETS_TITLE=直近のアラート
result=0
# ダッシュボードの取得
DASHBOARD_JSON=$( \
curl \
-X GET \
-s https://api.mackerelio.com/api/v0/dashboards/${DASHBOARD_ID} \
-H "Content-Type: application/json" \
-H "X-Api-Key: ${API_KEY}" \
-f \
) || result=$?
if [ "$result" -ne 0 ]; then
echo "failed to retrieve dashboard."
exit 1
fi
# アラート一覧の取得
ALERT_LIST=$( \
mkr alerts list | \
awk \
-v ORG_NAME=${ORG_NAME} \
'{m="";for(i=2;i<=NF;i++) m=m $i " "; print "- [" m "](https://mackerel.io/orgs/" ORG_NAME "/alerts/" $1 ")"}' \
) || result=$?
if [ "$result" -ne 0 ]; then
echo "failed to retrieve the alert list."
exit 1
fi
# アラート一覧のMarkdownウィジェットを修正
MODIFIED_JSON=$( \
echo $DASHBOARD_JSON | \
jq -c \
--arg ALERT_LIST "$ALERT_LIST" \
--arg WIDGETS_TITLE "$WIDGETS_TITLE" \
'(.widgets[] | select(.type == "markdown" and .title == $WIDGETS_TITLE) | .markdown) |= $ALERT_LIST' \
) || result=$?
if [ "$result" -ne 0 ]; then
echo "failed to correct dashboard."
exit 1
fi
# ダッシュボードの更新
curl \
-X PUT \
-s https://api.mackerelio.com/api/v0/dashboards/${DASHBOARD_ID} \
-H "Content-Type: application/json" \
-H "X-Api-Key: ${API_KEY}" \
-d "${MODIFIED_JSON}" \
-f \
> /dev/null 2>&1 \
|| result=$?
if [ "$result" -ne 0 ]; then
echo "failed to update dashboard."
exit 1
fi
API_KEY, ORG_NAME, DASHBOARD_ID, WIDGETS_TITLE は環境に応じて設定してください。
これをcronで定期的に実行することで、最新のアラート一覧をこんな感じでダッシュボード上に反映できるようになるはずです！
まとめ
いかがでしたでしょうか。
今回は主にLinux環境を想定してシェルで実装していますが、Windows環境だとPowerShellで実装したり、AWS Lambdaなどサーバーレスな環境でも実装することができると思います。
アイデア次第で色々と拡張できるので、ぜひ色々と試してみてください！
明日はアドベントカレンダー最終日、id:wtatsuruさんです！お楽しみに！
Mackerelのアラート通知を制御する方法のご紹介
これは Mackerel Advent Calendar 2021 の21日目の記事です。
昨日は 
id:a-know さんによる Autify → Mackerel 連携 - 継続的なE2Eテストを監視する という記事でした。
今日は監視する上での悩みのポイントのひとつでもあり、最近よくお問い合わせをいただくアラート通知の制御方法について紹介したいと思います！
大量に発生するアラートの通知をまとめる
システムを運用していると、大小にかかわらず障害はつき物で、その障害に関するアラート通知を受け取ることがあると思います。
障害の原因や規模は様々ですが、広範囲になるほどその通知の量も増えていきます。
- インフラ基盤の障害
- 単一障害点の影響を受けて、サービスを提供できずに発生する障害
- 例えばデータベースサーバーの障害に引きずられて、アプリケーションサーバーなどが障害となるようなケース
- などなど…
2つ目のケースを例にすると、アプリケーションのログをERRORやFATALなどのログレベルで監視することはよくあると思いますが、数十〜数百台のサーバーにこのような監視ルールが適用されていると、データベースの障害によってそれらのホストから一斉にデータベースへの接続エラーが発生する（恐らくそのような場合のログレベルはFATALなどである）ことが予想されますよね。
こういった大量に発生するアラートを削減する機能として、アラートグループがあります。
上記のヘルプページの通りグルーピングする対象を絞り込むことができますが、いきなり細かく設定するのではなく、まずはサービスで纏めて様子を見てから適切な粒度に分割して設定することをオススメします！
またアラートグループを設定する場合は、通知チャンネルでアラートグループ通知の設定を有効にする必要があるのでお忘れなく！！
事前に認識しているアラートの発生や通知を抑止する
「毎朝、午前4時のバックアップ処理で負荷が高くなって発生するアラート通知が煩わしい」といったケースはよくありますよね。
既知でかつそのアラートの発生が許容できる場合、Mackerelではダウンタイム機能を使うことで、サービス/ロールや監視ルールなどの条件に該当するアラートを曜日や時間帯などを指定して、その発生自体を抑止することが出来ます。
上記の通りアラートそのものの発生を抑止してしまうため、アラートは発生させて通知だけを抑える事が出来ません。
そのような場合は、ホストのステータスをコントロールすることで制御できます。
ホストのステータスにはworking、standby、maintenance、poweroffの4つのステータスがあり、standbyにすることで監視は実行（アラートが発生）するが、通知は行わないという動作になります。
この設定はホストごとにする必要があるので対象ホスト数が多いと設定が大変ですが、CLIツールの mkr を使うことで以下のようなワンライナーのシェルを実行するだけで一括して変更できます。
## サービスが "Service"、ロールが "Role" で、ステータスが "working" のホストを一括で "maintenance" に変更する mkr update --status "maintenance" $(mkr hosts --service "Service" --role "Role" --status "working" | jq -r '.[].id') ## ステータスを "maintenance" から "working" に戻す mkr update --status "working" $(mkr hosts --service "Service" --role "Role" --status "maintenance" | jq -r '.[].id')
このようにUI上で提供されていない操作も、mkrやAPIを使うことで柔軟に対応できるので、ぜひ運用に取り入れてみてください！
特定の監視ルールに関する通知を任意の通知チャンネルで通知する
監視運用を始めると、アラート通知を行うターゲット（人やチーム）を適切な単位に分けたくなることがあります。
- アプリケーションエラーに関するアラートは開発エンジニアに通知
- 一部の監視運用をMSPなどに委託している場合、そのアラートに関する通知はMSPのみに通知
- などなど…
Mackerelでは通知先（メールやSlackなど）を通知チャンネルで、発報されるアラートと通知チャンネルとの紐付けを通知グループで設定できます。
例えば、バッチ処理のログを監視するルールlog_worker_warnとlog_worker_errorの通知を、エンジニアのSlackチャンネルに対して通知したい場合は、通知グループを以下のように設定すると実現できます。
この時、選択した監視ルールの左側にチェックをつけることで、その監視ルールのアラートは他の通知チャンネルには送らないといった制御もできます。 （複数の通知グループでこの設定をした場合は、そのグループ全てに送られます）
すごく簡単ですよね！
通知を細かく制御したい場合は、ぜひこの設定をお試しください！
まとめ
今回はアラート通知に関する制御の方法を3つほどご紹介いたしました！
ただし今回ご紹介した方法の一部には、適切なサービスとロールの設定が必要なものもあります。Mackerelの「サービス」と「ロール」については、こちらで詳しく紹介していますので、ぜひ参考にしてください！
明日は 
id:masarasi さんです！お楽しみに！
