カバレッジモデルを導入してよかったことと感じた課題

前回の記事で最後に、次はNPSについて書きたいと言っていたのですが、NPSをはじめる重要なきっかけとなったカバレッジモデルについて先に触れることにします。

カバレッジモデルとは？

カバレッジモデルは、青い本では、ハイタッチ、ロータッチ、テックタッチという3つのモデルに分けて触れられています。 顧客をいくつかのセグメンテーションに分け、CRE（特にカスタマーサクセス）としてどのようなものをユーザーに対して提供するか（内容や頻度）を戦略的に決めるためのモデルです。 Mackerel では、青い本を参考に、ざっくりと以下のように定義しています。

• ハイタッチ
  • 四半期〜半期に一度はお伺いしてコミュニケーションする
• ロータッチ
  • 一年に一度はお伺いしてコミュニケーションする
• テックタッチ
  • メールや電話、公式イベントなどでコミュニケーションする

上に行くほど、1つのユーザーへのコミュニケーションの頻度や深さが高まり、下に行くほど対象となるユーザー数が増えるというピラミッドの構造になっています。

なぜ導入したか

Mackerel の CRE チームはまだまだ小さいチームなので、残念ながら全てのユーザーにハイタッチを行うことはできません。 Mackerel は BtoB のサービスですが、サーバー台数をベースとした従量課金で少額でもはじめられるため、個人で使っていただいているユーザーもいます。ユーザーによって、1台から数千台と、利用状況はさまざまです。サーバーが1台の環境と、数千台の環境では、システムのアーキテクチャはもちろん、使う人の体制や使っている機能、監視に期待することなども大きく違います。 そういった背景から、すべてのユーザーがハイタッチを求めている、とは限らないだろう、という仮説もありました。

私たちには、ハイタッチないしはロータッチができるユーザーを選択していく必要がありました。 そこで、私は、顧客を売上や利用機能、過去のコミュニケーションの状況などを可能な限り洗い出して一定のルールに従ってセグメンテーションし、カバレッジモデルを導入することにチャレンジしました。 主に私はロータッチを担当し、そのユーザー群に対して、1年に1回は最低でもお会いすること、ということを目標に訪問を続けました。

カバレッジモデルを取り入れるよさ

カバレッジモデルを取り入れて一番変化したのは、ユーザーの訪問が、これまで、少なからず過去の経緯や担当者の感覚に頼って判断して行われていたものが、他の人にも説明しやすい仕方で（とはいえ、ゆるやかに）ルール化されて、一人でも判断して進められるようになったということでした。 また、そもそもこのカバレッジモデルを立てるために行った、ユーザー状況の精査ということによって、自分たちの顧客にはどういった人がいるのか、どういう課題を抱えているのか、ということを知ることができました。 精査する際は、以下のような項目を洗い出しましたが、かなり地道で時間のかかる作業でした。それでも、やってよかったと思っています。

• 顧客窓口
• 利用深度
• 運用・監視の課題
• 次のステップ --- など

カバレッジモデルを取り入れても解決できなかった課題

カバレッジモデルを取り入れることで、悩まずにユーザーを訪問できるようになりました。ただ、このあたりから私の中で、いくつかの新しい課題が芽生えはじめました。 それは、こちらからアポイントメントをとって訪問するタイミングが、ユーザーにとってほんとうにうれしいタイミングとは限らないのではないか？という疑問です。 というのも、訪問していろいろとヒアリングしていると、以下のようなことをおっしゃるユーザーの方もおられました。

• 困っていたことがあったけど忘れてしまった
• 困っていたけど、なんとか自分で解決した（ほかのツールで解決した）
• 今後頼るかもしれないが、今はまだ困っていることはない --- など

これらのコメントをもらう度、わたしの中には以下のようなことが浮かんでいました。

• 訪問するタイミングが遅いのではないか？
• もっとユーザーが求めるタイミングでコミュニケーションできたほうが、有意義なのでは？

訪問のような濃い、かつお互いのコスト（時間）がかかるようなコミュニケーションをしているのに、ポイントをはずしているのではもったいない、という気持ちになりました。

NPSへのモチベーションの高まり

こういうことがあって、私の中で、NPSを取得することへのモチベーションがじわじわと上がっていきました。つまり、ユーザーの状況を正しく理解して、ちょうどよい、痒いところに手が届くタイミングで訪問したい、という気持ちが高まったのです。NPSが顧客の状況を正しく知るための、一つの指標になりうると考えはじめました。

実際には、Mackerel のユーザーの状況を正しくつぶさに知るための指標は、これ以外にも多くあります。じゃあなぜNPSからはじめたの？ということろをお話したいのですが、今日はこの辺りまで。次の記事に続きます。

カスタマーサクセスのKPIについて考えはじめたころに参考にしたもの

前回ブログの続きです。カスタマーサクセスの仕事について考えていこう！となったとき、ちょうど発売されたのがこの本でした。

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

見てみると、発売されたのが 2018年6月 とのことなのでちょうどわたしが入社してから3ヶ月たったころのことだったので、これはうおお、みたいな感じで購入して読みました。 もともと取り組んでいた人からすると原文を読んでいて、やっと日本語訳されたか、という感じなのかもしれない。

Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue

カスタマーサクセスの本は、ちょうど私が感じていた以下のような課題についてけっこう答えを書いてくれているように思います。

• カスタマーサクセスが仕事として責任をもつことは何なのか？
• 他のカスタマーサクセスではどういったことをやっているのか？

カスタマーサクセスが持ちうるKPIが何なのか、というのはこの本がわかりやすかったという記憶は実はあまりなく、ネットで「カスタマーサクセス KPI」とかで調べた記事を読み漁っていました。あと当時感じていたこととしては、結局カスタマーサクセスの指標を調べようとして見ていたものはSaaSのKPIでもあるんですよね。 HiCustomerさんの記事や、前田ヒロさんの記事には特にお世話になりました。

media.hicustomer.jp

hiromaeda.com

今、前どんな記事見てたかな、と思いながら同じキーワードで検索してみたら良さそうな記事が1年前よりめちゃくちゃ増えている印象があって驚きました。自分が興味がある分野について世間も関心が高いというのは大変ありがたい。 というわけで、新しく見つけたこちらの記事が網羅的でとてもわかりやすいと思ったので、リンクを貼らせていただきます。

koni.hateblo.jp

これらを見ながら当時、私が注目した、取ってみたいと思ったKPIは以下のようなものです。

MRR Churn Rate

当月失ったMRR(月次収益) / 先月末時点でのMRR(月次収益)

一般的に、顧客数でChurnを測るCustomer Churn Rateと月次収益で測る MRR Churn Rate があります。両方見るのが本来的にはよいそうですが、Mackerelの売上は顧客数ではなく、顧客がMackerelに登録するサーバー数などに紐づいて増加するので、その要素も含んだ月次収益をまずは見始めるのがよいと思いました。

Negative Churn

Net MRR Churn Rate がマイナスである状態 （当月失ったMRR ー アップセル分のMRR ー 休眠顧客からの復活MRR） / 先月末時点でのMRR

既存ユーザーのアップセルだけで収益アップできている状態であれば値がマイナスになる。算数が苦手な私には直感的には理解しにくい値。アップセルの売上を目標にすると、特定顧客へのアプローチ(商談)によるものだけが対象になりがちですが、CREが実施している既存ユーザーに向けたイベント開催や、ドキュメントの作成、リリースブログの更新など広くマスにアプローチする活動も影響している Negative Churn をCREが見る指標とする方がより今の活動に即していると思いました。今どう思っているかはさておき。

顧客満足度

これも、当時のMackerelチームではみるすべがありませんでした。どうやって顧客満足度を集計するか、ということについてはその後検討されて、NPSを取ろう、ということになります。CREのそもそものミッションである顧客の信頼性を高めるということのダイレクトな指標になると思いました。

こんなことを 2018年8月頃 考えていて社内にフィードバックしていたようなので、じりじりとではありますが、着実に前に進んでいるな、と振り返って思います。

この後、実際に私が取り組んだのは、まずはKPIを整理して見られるようにしようということでした。 MRR Churn Rate、Negative Churn はすでにある値を成形するだけで見られたのですぐにやりました。 顧客満足度についてはNPSを取る準備からはじめました。

実は、カスタマーサクセスの文脈で、けっこう重要視される継続率やLTV(顧客障害価値)については当時触れていません。 というのも、Mackerelというサービスの特性上難易度が高い部分があるからです。 これについてはこれからちょっとずつちゃんとやりたいと思っている部分だし、どういう難しさがあるのか、ということもどこかでまとめてみたいです。

次は、たぶんNPSについての記事を書くかなあという気持ちです。

Mackerel CRE の仕事の4軸と私がカスタマーサクセスに重心をおくに至った経緯について

はてなに入って1年がすぎました。 最近、ここ1年くらいでやってきたことをきちんと記録としてアウトプットしておきたいな、というモチベーションが出てきたので、つらつらとブログに残していこうと思っています。 徒然なるままにまとめているので、情報が足りないところやはしょられているところが出てきてしまいそうな気がしますが、質問などはSNSなどから直接いただけたらうれしいです。

はてなのCREでは、カスタマーサクセス担当というような雰囲気で仕事をしている私ですが、ここではそこに至った経緯のようなところを簡単にまとめてみました。

Mackerel のCREでは今、自分たちの仕事を4つの軸で表現しています。 ちなみに、これはあくまで"今"そうなっているだけなので、これからチームやプロダクトの状況によっては変わっていくことももちろんありえます。

• カスタマーサクセス
• テクニカルサポート
• テクニカルアシスト
• テクニカルコミュニケーション

2018年3月に入社したとき、Mackerel チームではちょうどsoudaiさんという偉大なCREが退職されて、a-knowさんというこれまた偉大なCREが開発チームやその他の職種の人と協力しながらほぼ一人でその業務を担っていました。

当時JOINしたての私には、その姿は脅威的で（今でもそれは変わらないけど）、営業同行などのいわゆるテクニカルセールスの分野から、展示会出展の準備のようなマーケティング分野、日々のテクニカルサポート業務、告知ブログ（ニュースレター）の更新、エバンジェリスト活動などなどあらゆる業務を目にも留まらぬスピードでこなしておられました。当時の私からするとCREという職種がいろいろな分野にひらけた魅力的なものあると感じると同時に、まだすべてをこなすほどの力がない自分がどういう軸で仕事を選びとっていけばよいのか困惑したのも本当です。

そういう悩みをa-knowさんに打ち明けたところ、a-knowさんはa-knowさんで、CREという新しい仕事を社内外に向けどう打ち出して認知してもらうか、というようなところを課題としてもっておられたので、a-knowさんの懐の広さによって受け入れてもらって、隔週で「CREについて考える会」というのを二人で開催することに至りました。

「CREについて考える会」はその名の通り基本的にはフリーディスカッションをしながら、次回に向けてアウトプットの宿題を設けたり、持ち寄ったアウトプットをその場で組み替えたり整理したりを繰り返しました。半年くらいは続けたと思います。

そこで様々なディスカッションを経て、生まれたのがこの4軸なのです。

ここでは、この4軸がそれぞれどのような仕事なのかまで詳しく触れないですが、ひとつ大事なことをお伝えしておくと、私はこの4軸はCREの仕事の中にあるミッション・ビジョン・バリューの一部ようなもので、目の前の取り掛かろうとしていることがCREの仕事か？自分のやるべきことか？を判断するときの軸だと思っているということです。もともとつくりはじめたモチベーションもそういうところでした。そういう意味では今はすごく私を支えてくれている4軸です。

仕事を完全にきれいに分類するための便利な切り口というわけでもないし、CREの中の役職や肩書きというわけでは、少なくとも今はまだなっていないです。今後CREが爆増するようなうれしいことが起きたときには、これらをもとにサブ的な肩書きをつけたりすることもあるかもしれませんが、まだそのような体制にはなっていません。

developer.hatenastaff.com

Mackerel CREチームの KPI from Misa Miura

www.slideshare.net

この4軸が腹落ちしたころ、私はその他の業務とのうまくバランスをとりつつ、実は入社前から一番興味のあった「カスタマーサクセス」に自分の重心を置くことを決めました。

よっしゃカスタマーサクセスやっていくぞ、とこころに決めたわたしの次なる課題はカスタマーサクセス業務をどのように作っていき、どのように評価したり分析したりするのか、というところになるのですが、そろそろ京都に着きそうなので（今は京都出張の新幹線の中）また次のブログにまとめたいです。

Mackerel アドベントカレンダー（全部CRE）やってみた

この記事は、Mackerel アドベントカレンダー（全部CRE）の24日目の記事です。

クリスマスイブですね。

さて、Mackerel CREチームでは、この度全部CREでアドベントカレンダーをやってまいりました。

ブログという形で、日々文章を書いてアップし続けた経験ははじめてです。 最後は、アドベントカレンダーをやってみた感想をつらつら書いて終わりたいと思います。

まずはやってみる

はじめにid:a-knowさんに「今年も全部CREやろうと思うんだけどどう？」と言われたときは、いやー無理だろうと思いました。 Mackerelのアドベントカレンダーといえば、毎年すごいエンジニアの人が手を変え品を変え、面白い記事をアップしているものだし、前年のid:Soudaiにいたっては、毎日Mackerelのプラグインについて解説を書くというとんでもない所業をしでかされていた後だったので。 でも無理と思うようなこともできたらいいなと思うことはまずはYESと言ってみる、というスタイルで暮らしているところがあるので、今回もまずはトライしてみたという次第です。

実際にお題を考えたり、ブログを書き貯めたりすることはけっこう大変でしたが、最初に思考停止してYESと言ったおかげで、この体験をやってみることができてかつ最後までこれたのでよかったです。

2日に1回ブログ投稿する

高頻度のブログ更新のためにやったことはこんな感じ。

お題は先に決める

2日に1回ブログを投稿するために、まずは目次を書き出しました。 その日その日にお題を決めていくのは、難しいと持ったので、はじめにあたりをつけておく作業です。 自分が普段こういうものまとめたいなーとか、自分のなかで一度きちんと整理したいなーとか思っていたことを書き出しました。 それが、精査されて、アドベントカレンダーの記事になっています。

• 2日目 サービスとロール
• 4日目 サービスとロールが効いてくるところ
• 6日目 メトリックの種類
• 8日目 監視ルールとチェックプラグイン
• 10日目 通知チャンネルと通知グループ
• 12日目 トライアルプランで試してほしいこと
• 14日目 カスタマイズしたグラフをつくってみよう
• 16日目 オーガニゼーションあれこれ
• 18日目 API と mkrコマンド を使ってみる
• 20日目 アラートグループを設定してみる
• 22日目 CREになって考えていることや読んでいる本など。

自分が今かけるものを書く、すごい記事を目指さない

途中までは、ばくぜんとすごい記事を書かなければ、と思っていました。ところが、すごい記事とはいったい…となってぜんぜんネタが思いつきません。思いついてもそれやるには結構準備や勉強が必要で、そもそも間に合わないのではと思うものばかり。投稿日が近づいた頃、やっと、自分が今かけるものを書こう！憧れるクオリティをめざすまえにやり遂げねば！と開き直ることにしました。ここにたどり着けてよかったです。

探せばヘルプに書いてあるようなこともあるし、誰かがもっとうまくまとめていることもあるかもしれないけど、そういうことじゃないんじゃないかと。 CREは実際に対面でことばでMackerelのあれこれについて説明することが多いです。どこかに書いてあったら説明できるかということそうではないし、自分の言葉でまとめることに意味があると思いました。

毎日ちょっとずつ満遍なく書く

目次が決まってからは、一個ずつ仕上げるのではなく、全部の記事を毎日ちょっとずつ満遍なく書いていきました。

最終的には今自分が本当に書きたい、あったら便利なお題にできたので、比較的に筆が進んで、あとは週末にコツコツ書き貯めたりしてなんとか2日に1回投稿することができました。 この一連の記事、自分ではけっこう満足しています。

毎日のご飯のように書く

先日、Mackerelとはまったく別件で、自炊する話についてブログを書きました。

自炊にはまりながら、料理の本を読んでいました。

面倒くさい日も、おいしく食べたい! 仕事のあとの、パパッとごはん

この本の第１章にあたるところの最初のタイトルが秀逸です。

夕飯作りの「敗北宣言」をする

手の込んだものを作ることは大変だけどおいしいご飯は食べたい。そういう夜は、敗北宣言をして、ちょっとしたメソッドにしたがって手間のかからないご飯をつくっておいしく食べるというのがこの本のコンセプトです。私のアドベントカレンダーへのマインドに近いので、おもしろいです。

これ以外にも、うんうん頷きながら読めるフレーズがいくつも登場します。自分に刺さったエッセンスを書いておきます。本文そのままではなく、私の解釈です。

• 構成するもの少なくてもいい
• こうしとけば絶対においしい、という型をつくる
• レパートリーは少なくてよい
• 余計なことをしない

こったものでおもてなしするわけでなく、自分にとって絶対おいしいものを続けられる範囲でつくろう、というマインドがまさに今の自分にぴったりでした。 こういうことって、いろんなことに応用が聞く、なにかを続けるコツなのかもしれないな、と思いました。

というわけで、自分の晩ご飯のようにアドベントカレンダーを書いてしまいました。

最後に

ブログっていいですね。 みんが見られるところに、自分のための記事を書いていることによって、よい効能がいろいろありました。

• 自分の関心ごとがわかる、人に伝わる
• 物事への自分の理解度がわかる、人に伝わる
• 自分の周囲の人との共通言語がうまれる

いちばん新鮮だったのは、はじめてお会いするお客様に、その日の打ち合わせで時間内にどこを重点的にご紹介したらよいか、という質問に「今日集めたメンバーはブログの記事に書いておられたようなことまではなんとなく理解しているメンバーです」と言ってもらえたことです。 こんなふうに社外の人と、ブログの内容をベースに話ができるようになるのか、と目から鱗でした。

直接Mackerelには関係ない感じでラストの記事を書いてしまいました。 自分の晩ご飯のような記事を読んでくださったみなさま、最後までお付き合いいただきありがとうございました。

CREになって考えていることや読んでいる本など。

この記事は、Mackerel アドベントカレンダー（全部CRE）の22日目の記事です。

いよいよネタも尽きてきたので、今日は本当にライトなネタです。

先日、MackerelプロダクトオーナーのSongmuさんがex-KAYAC Advent Calendar 2018に向けてこんな記事を書かれていました。

blog.song.mu

その中で、MackerelのMVVについて触れられています。 そのまま引用します。

• ミッション
  • 「クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」
• ビジョン
  • DevOps中核サービスのデファクトとして進化しつづける
  • サービス監視・運用の価値を高め、面白くする
  • 顧客のサービス成長を加速させる
• バリューズ
  • Infrastructure as Codeを体現する
  • devops文化を根付かせる
  • ドッグフーディング
  • エンジニアをワクワクさせる
  • OSSエコシステムと共生する

このビジョンのおもしろいところ、というか個人的に興味が惹かれているところは、Mackerelが冠としては「サーバー監視ツール」でありながら、バリューの中には「devops」というカルチャーについてのエッセンスが含まれていることです。

このことが気になってしょうがないので、最近はそればっかり考えているような気がします。 あまりさっと本質にたどり着ける器用な人間ではないので、いろいろな本や社内外の事例などをみたり、先輩に教えを請いながら右往左往して少しずつ頭の中に絵が描かれていっているという具合です。

ちょっと調べてアウトプットして、数日後何かを学んで見直すと、全然わかってないじゃん！というのを繰り返す日々。こういうのは楽しい。

Mackerleで、devopsを根付かせるっていったい何をどうやったらいいんだろう？というのはMackerelチームにいながらもいつも考えている課題です。

これを考えていくためには、いろいろ勉強する必要があるなあと感じています。

とはいえ、まずはdevopsそのものから。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps教科書

ツールについて、カルチャーについて、いろいろな切り口があります。 先日Mackerel Drinkupを開催した際には、参加者の方と「devopsは変更に関する意思決定を早く、効果的にする手法」ということではないか、というは会話したりしていました。よりよい変更であること、それがはやくできる、ということはdevopsにとって重要なキーワードになりそうです。すごく印象に残りました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE本は今運用ということについて考えるときに非常に学びの多い書籍です。 信頼性を高めるのではなく、コントロールする、という考え方が新鮮です。devopsということとSREということがどういった関わりをもつか、ということについてはまだまだ私の中で整理ができていないですが、「SREはdevopsを実現する具体的な手法のひとつ」とおっしゃられていた人もいるので、どちらも合わせて勉強していきたい概念です。

最近、私はMackerelでの運用設計のベストプラクティスをどうやってつくったらどうかということについてもずっと考えていて、そのための、特にモニタリングとインシデント対応については以下の本を参考にしています。

Webエンジニアが知っておきたいインフラの基本

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

どちらも私の前職の先輩方々の教えです。

そして、いよいよ発売される以下の本も非常に楽しみにしています。

入門 監視 ―モダンなモニタリングのためのデザインパターン

CREをしていて思うのは、本当にMackerelのユーザにはいろいろな人や企業がおられるな、ということです。

オンプレを運用されているところもあれば、クラウドに移行中のところもあり、クラウドを使いこなし、次はマイクロサービスをうまく運用していくことに目を向けられているところもあります。

devopsの文化に関するところついても、1つのチームで開発からインフラまですべてを見ているところもあれば、開発チームとインフラチームが別個に動いているところ、SREsがいるところ、それぞれの形態のチームが混在しているところ。様々です。

運用設計といっても、何がベストプラクティスになるのかは、こういったシステムや組織の状況によってきっと異なると思っています。

それぞれのユーザの方がどんなフェーズにおられて、今後どういう組織や運用を目指されているのか。 どんな段階を経て、その目指す姿に近づいていくのか。Mackerelというツールやチームがその変化に対していったいどんなお手伝いができるのかというのが、気になってしょうがいない今日この頃です。しかしまずは勉強ですね。

まだこのあたりのことについてきちんと自分なりのアウトプットできるところまで整理できていないので、来年またアウトプットできたらいいなと思います。

ネタがつきたといいながら、結果、来年の抱負のようなエントリーになったなあ。

アラートグループを設定してみる

この記事は、Mackerel アドベントカレンダー（全部CRE）の20日目の記事です。

みなさんはアラートグループは利用したことはありますか？ 今日はアラートグループの設定方法や通知方法についてまとめてみます。

アラートグループとは

アラートグループとは、サービスやロールごとに同じ時間帯に発生したアラートをグループとしてまとめる機能です。

ユースケース

たとえばゲームシステムなどwebサーバーを何台も横並びにして負荷分散しているような環境をイメージしてください。 webという同じロールに200台などのサーバーが登録されています。かつそのwebサーバー群は同じデータベースサーバーに接続にいっているとします。 そのような状況で、データベースサーバーに障害が発生したとしたら、200台からデータベースへの接続エラーのアラートが一斉に送信されてしまいます。

アラートが大量に発生してしまうと以下のような弊害があります。

• 大量のアラートを確認するために時間を割いてしまう
• データベース接続エラー以外の重要なアラートが埋もれてしまう

また、このようなことが頻発すると、アラートを見ると人がアラートに慣れてしまって、重要性だという感覚が鈍ってしまう、という弊害もあります。

このような大量アラートをうまく管理するための機能としてアラートグループが開発されました。

思わぬ効能

アラートグループはこのように、同じロールに大量のサーバーが登録されているようなケースを想定して開発されました。では、ロールに登録されているサーバーが少ない場合や、そもそもサービスに登録されているサーバーが少ないような環境では意味をなさないか、というとそうでもありません。 各サーバーが共有するネットワークやストレージなどに障害があった際や、データベースサーバーに限らずDNSサーバーやログサーバーなど各サーバーが共有する機能に障害がおこったときも200台とはいわずとも、たくさんのアラートが発報されます。 または、サーバーの処理量が増加して、リソース監視の閾値ギリギリをふらつくような事象がおきたときに、同時にアプリケーションログにエラーが出力されているような場合もあるかもしれません。 このような時にも、アラートグループは同時間帯に起きたアラートの可読性がよいので便利です。

アラートグループの設定方法

アラートグループは、アラート一覧画面から設定します。 右上の[アラートグループ設定]をクリックします。

アラートグループ設定画面が表示されます。 右上の[新規アラートグループ設定を作成]をクリックします。

新規アラートグループ設定を作成画面が表示されます。

アラートグループはサービス、ロール単位で設定することができます。

アラートグループの通知設定

アラートグループの通知設定は通知チャンネルに設定できます。 通知チャンネルの編集画面を開くと、[通知するイベント]としてアラートグループを選択することができます。 デフォルトではオフになっています。

この設定を変更すれば、運用の仕方に合わせて通知方法を選択することができます。

• 通常の個別のアラートとアラートグループを両方通知する
• 個別のアラートの通知をオフし、アラートグループのみを通知する
• アラートグループは通知せず、GUIから参照するだけ
• アラートグループ用の通知チャンネルを別途追加して、アラートグループだけ専用の通知先に分けて通知する

などなど

まずはアラートグループを有効にして様子を見ながら通知をどうするか、適切なものを選んでいくとよいと思います。

可読性のよいGUI

これはイメージですが、このような形で表示されます。 CPU使用率の中に一見だけアクセスログのエラーが混ざっているのもひと目でわかりやすくなっています。

アラートグループをうまく使いこなして、大掛かりな障害にもスムーズに対応できるとよいですね。

API と mkrコマンド を使ってみる

この記事は、Mackerel アドベントカレンダー（全部CRE）の18日目の記事です。

Mackerelでは複数のインターフェースを用意しています。 いちばんよく見るGUIの他に、別のアプリケーションなどからMackerelを操作可能にするAPI、そして、APIをより簡単に利用することができる、mkr コマンドです。

APIを叩いてみる

APIには、幅広くMackerelの操作をするためのものが揃っています。

• サービス
• ホスト
• ホストメトリック
• サービスメトリック
• チェック監視
• メタデータ
• 監視設定
• 通知チャンネル
• 通知グループ
• アラート
• ダッシュボード
• グラフアノテーション
• ユーザ
• 招待
• オーガニゼーション

APIはcurlでも実行してみることができるので、どんな情報が取得・更新できるのか、使い心地をぜひ試してみてください。 試しに、ホストAPIを使って、指定したサービスとロールに所属するホストの一覧を取得してみます。

curl -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" -X GET https://api.mackerelio.com/api/v0/hosts?service=sample-service\&role=sample-role

APIを叩くスクリプトや、アプリケーションを書くと、いろいろなことを自動化できそうでわくわくしますね。

ドキュメトにもっと詳しいことが載っています。

mackerel.io

mkrコマンドを使ってみる

APIを活用するには、何かしらスクリプトや簡単なコードを書く必要がある場合がありますが、そういったことをしなくても、APIを簡単に実行できるインターフェースが mkr コマンドです。

コマンド	できること
status	ホストの情報を取得します
hosts	ホストの一覧を取得します
create	新規ホストを作成します
update	ホストのステータスやロールを変更します
throw	ホストメトリックまたはサービスメトリックを投稿します
metrics	メトリックの値を取得します
fetch	最新のメトリックの値を取得します
retire	ホストを退役させます
services	サービスの一覧を取得します
monitors	監視ルールの操作を行います
alerts	アラートの一覧を取得、クローズします
dashboards	ダッシュボードの操作を行います
annotations	グラフアノテーションの操作を行います
org	オーガニゼーションの一覧を取得します
plugin	プラグインの管理をします
help, h	ヘルプを表示します

mkr コマンドを使って同じようにホストの一覧を取得する方法をまとめてみます。

今回は、ローカルのmacOSに mkr コマンドをインストールしていきます。インストールには brew を使います。

まずは、brew tap コマンドでリポジトリを追加します。

$ brew tap mackerelio/mackerel-agent

mkr コマンドをインストールします。

$ brew install mkr

mkr コマンドで利用するAPIキーを環境変数で指定します。

$ export MACKEREL_APIKEY=YOUR_API_KEY

mkr コマンドで、先ほどと同じようにサービスとロールを指定してホストの一覧を取得するとこのような感じです。 パッとホストIDの一覧や、ホスト名などを拾ってきたい場合には便利です。

$ mkr hosts -s sample-service -r sample-role
[
    {
        "id": "HOST_ID",
        "name": "sample-host",
        "status": "working",
        "roleFullnames": [
            "sample-service:sample-role"
        ],
        "isRetired": false,
        "createdAt": "2018-04-09T13:08:55+09:00",
        "ipAddresses": {
            "eth0": "IP_ADDRESS"
        }
    }
]

mkr コマンドで監視ルールを変更してみる

mkr コマンドのイチオシ機能は、監視ルールを手元で管理することができる monitors オプションです。 使い方はこんな感じです。

まずは、monitors オプションの中身を見てみましょう。 このように、監視ルールの設定をjson形式で見ることができるのが、このオプションです。

$ mkr monitors
[
    {
        "id": "MONITOR_ID",
        "name": "CPU %",
        "type": "host",
        "metric": "cpu%",
        "operator": ">",
        "warning": 80,
        "critical": 90,
        "duration": 1,
        "maxCheckAttempts": 1,
        "scopes": [
            "sample-service: sample-role"
        ]
    },

(省略)

画面で該当箇所を見るとこんな感じです。

このjsonは手元にファイルとしてダウンロードしてくることができます。 それが monitors pull オプションです。

$ mkr monitors pull
      info Monitor rules are saved to 'monitors.json' (6 rules).

ls をしてみると、monitors.json というファイル名でダウンロードされていることがわかります。

$ ls monitors.json 
monitors.json

jsonファイルはそのまま手元で編集することができます。vi コマンドでファイルを編集してみましょう。 今回は、warningの閾値を80%から85%に緩和してみます。

$ vi monitors.json

さらに monitors diff オプションを使うと、変更箇所の差分を見ることができます。 warningの閾値が80%から85%になっていることがわかりやすく表示されています。

$ mkr monitors diff
Summary: 1 modify, 0 append, 0 remove

 {
   "critical": 90,
   "duration": 1,
   "maxCheckAttempts": 1,
   "metric": "cpu%",
   "name": "CPU %",
   "operator": ">",
   "scopes": [
     "sample-service: sample-role"
   ],
   "type": "host",
-  "warning": 80
+  "warning": 85
 },

このままでは、単に手元のjsonファイルが変更されているだけなので、これをMackerel本体に同期します。 monitors push オプションを利用します。

$ mkr monitors push
      info Update a rule.
{
  "id": "3fRyxz3Nez3",
  "name": "CPU %",
  "type": "host",
  "metric": "cpu%",
  "operator": ">",
  "warning": 85,
  "critical": 90,
  "duration": 1,
  "maxCheckAttempts": 1,
  "scopes": [
    "sample-service: sample-role"
  ]
},

アップデートが成功したメッセージが出力され、実際に画面を見ると、閾値が変更されていることがわかります。

このようにして、手元で監視ルールの書き換え、反映を行うことができます。 また、この monitors.json ファイルを git などに置いておけば、バージョン管理をすることもできます。 その他のCIツールなどと連携して、git で変更がコミットされたら、mkr monitors push をキックするなどのような仕組みもつくれます。

mkrコマンドでは他にもさまざまな操作ができます。詳しくはこちらもヘルプをどうぞ。

mackerel.io

API や mkrコマンド を活用して、普段の作業を自動化してみてはいかがでしょう。