バッサリ辛口！新サービスKompira AlertHub MSPから見た本音

バッサリ辛口！新サービスKompira AlertHub
MSPから見た本音

株式会社クイックガード　代表取締役栗原　邦彦氏

初めましてクイックカードの栗原と申します。

今回Kompira ミーティングでお話をするのは初めてですので、知らない方の方が多いと思いますが、弊社クイックガードはサーバの構築や監視、もしくはネットワークの構築など、いわゆるMSP事業者としてインフラの構築設計に携わっている会社です。
今回三角社長からの依頼で2020年10月にリリースされたKompira AlertHubというサービスについて、実際の検証を交えながらお話しをさせていただきます。宜しくお願い致します。

簡単に自己紹介をさせていただきますと、私は株式会社クイックガードの代表取締役をしている栗原と申します。大学を中退してから18年間、MSP業界でサーバやネットワークの構築監視に携わってきました。
クイックガード自体もまだまだ若い会社で、2016年3月に起業してから今年で5年目となります。後発組のMSPのため、我々は二つの軸、スピードと柔軟性という軸を持って活動しております。

今回の登壇依頼経緯は、三角社長と食事をする機会がありまして、10月にリリースしたKompira AlertHubについて、エンジニア視点でKompiraミーティングでお話ししてもらえませんかとご相談を受けました。
エンジニア視点だと辛口になるかもしれないですよ、と申し上げましたが、全然問題ないですとのことでしたので、今回お話しをさせていただくことになりました。

セッションの目的

セッションの目的を絞って、大きく二軸で検証と説明をします。

Kompira AlertHubのプレスリリースに書いてある、「誰でも簡単に」「監視システムからの不要なアラートを自動フィルターする」ということについて、本当に誰でも簡単にできるのか、本当にアラートのフィルタリングとして使えるのか、この2点を軸としてお話しをさせていただきます。

今回の講演の内容としては大きく五つに分かれております。
一つ目が、Kompira AlertHubとは何か、ということです。まだKompira AlertHubを見たことも聞いたこともないという方が多いと思いますので、それが何かというところと、２）ダッシュボードの説明、３）他サービスとの連携、４）実践検証の部分と、５）今後の改良に期待したい部分という、五つをお話しさせていただきます。

Kompira AlertHubとは

ではKompira AlertHubとは何か、というところですが、運用に関わっている方々はZabbixやNagios、mackerel、Datadogといった、いわゆる監視ツールを必ず使われてるかと思いますが、Kompira AlertHubは結果を複合して判断するフィルターのような役割をするサービスです。

実際はこの受信スロットというところにインプットが二つありましてEmailとWebhook、アウトプットとしてEmail・Webhook・Pigeonの三つが組み込まれております。
ルールやトリガーや深刻度というものが中央にありますが、もともとZabbixで使われている名称ですので、Zabbixを使われている方はすっと入ってくるのではないかなと思います。

ルールの部分が、メールの件数やカウント、条件を定義するところです。それに対してトリガーの方でアクションと紐付けする動きを取りまして、実際に出力されるという形になっています。

実際にKompira AlertHubで実現可能な集約例ということで、この八つがウェブサイトに出ていますが、それぞれZabbixなどの監視ツール単独でできることもあります。例えば左上の夜間の時間指定でのメール送信不要・電話の切替え・メール送信、これらは監視ツール単独でも可能ですが、複合的に一つのツールにまとめるという点において運用コストの削減に焦点を当てたサービスとなっております。

ダッシュボードの説明　―スコープ―

ダッシュボードの説明は、大きく四つです。スコープ・受信スロット・ルール・アクションに分かれています。登録する順番が重要で、受信スロットと言われるインプットを最初に設定をしなければなりません。この受信スロットを作った後に紐づくところでスコープ、ルール、アクションという順番に作っていきます。

実際にスコープの画面では、ステータスで正常・警戒・障害という大きく三つに変化するようになっており、このステータスは右側にある深刻度という値で変化するようになっています。
深刻度は0から1000まで設定できますので、この0から1000までの数字の中で何回発生したか等のコントロールが可能です。

ルールから直接アクションの呼び出しができないため、スコープ経由でアクションが呼び出されるという方式です。

スコープの設定はシンプルですが、5分以内にメール受信5回あれば警戒、10回あれば障害というステータスに変える設定と、右側はこの時間帯だけはカウントをしない、例えば今回ですと営業時間の8時から18時半の間はカウントするという動作をしない、という設定を入れています。
例では曜日が入っていますが、祝祭日があるとコントロールが少し難しくなるかなと感じています。

こちらはステータスを変化させるところ、いわゆるトリガーの設定です。6個の選択肢の中から選んで入力をしていきます。右側は600秒というところで、約10分の間にステータス深刻度を「1」あげるアクションが10回あった場合に障害メールを送るというアクションに紐づける設定となっております。

受信スロットでは、一番最初に作るWebhook、もしくはメールで受け取るということで、ここの入り口を複数個作れるようになっているため、システム別やサービス別で複数発行して運用してもらえればと思います。

こちらはルールの設定です。ここは処理フロー五つの選択形式から選ぶので、実際に自分が設定したい内容に近いものを選んでいきます。
この処理フローは１点だけ問題があり、後ほど辛口コメントでもお話ししますが、処理フローの部分が全て and 条件になっており or の条件設定をする場合はルール自体を二つに分けなければいけない形になっているため、注意が必要です。

今回この設定ではメールを受信した時にメールタイトルに「errorエラー」というのが含まれていれば、下のイベントに深刻度を「1」増やすという設定になっています。

ダッシュボードの説明―アクション―

次はダッシュボードのアクションの部分です。こちらが実際に監視結果をメールで送信したり電話をかけたりする部分になります。
Pigeonの設定を最初に入れておくことによりKompira のPigeonと連携して簡単に電話をかけることができます。
実際にメールを送信する画面が下に載っています。To・Cc・Bccが選択できる点は良いところです。
お客様に直接メールを送信して、自分たちもBccに宛先指定できるので便利だと思います。
本文のところに日本語で送るメールの文が書いてありますが、このような形で変数を使って宛先・差出人・タイトルなどの情報を得て、メールの内容に変数で入れることも可能です。

ダッシュボードの説明―障害判定―

こちらは障害判定の画面です。至ってシンプルでイベントとアクションが履歴で追えるようになっていますので、分かりやすいかと思います。
また、API のトークンも簡単に発行することができます。

他サービスとの連携―Slack―

他サービスとの連携の部分ですが、よくエンジニアが使うのは Slack や、Zabbixなどの連携かと思います。今回Slackの方はOutgoing Webhookの設定をしておくことで、受信した監視メールをそのままSlackに流したり、その辺をコントロールするものになっております。
右側に監視メールをそのまま載せる記述を簡単な形式で書いてありますが、 JSON 形式での記述ができるため、この辺りは楽にコントロールできます。ただJSONですので、コメントが付けられないというのが個人的に残念な感じかなというところです。

他サービスとの連携―Mackerel－

Mackerelの方もJSON形式でアラートが飛ばせるようになっておりますので、ヘルプページを参考にして、連携を行ってください。
右側にアラートの実際に送られてくるメトリックを載せていますが、色々な情報を細かくコントロールできるように送られてくるので、この辺りで制御ができればというところです。

他サービスとの連携―メール－

実際にメールの方で連携する場合には、このような形で記述をしますが、メールも JSON形式に変換されて送られてきます。
少し注意が必要なのは、設定が書いてある箇所にmassege.を頭に付けないと、それを読み込んでくれないところです。ここは注意が必要です。
以上ここまでKompira AlertHubのダッシュボードや機能の説明をしてきました。

次に監視などで実際に使えそうな設定を検証した結果について、説明をしていきます。

実践検証

大きく三つの検証をしました。
一つ目は、大量の監視メールを受けている方々がいらっしゃると思いますが、それについて特定のメッセージ、リアルタイムに対応したいものだけをだけを、社内で使っているSlackなどに通知すること。
二つ目はログ監視メール、アプリケーションログなどでログ監視している方々がいらっしゃると思いますが、復旧通知が二通飛んでくることになるので、復旧通知の方を受け取らないようにするケース。
三つ目は、実際Slackで＠チャンネルで誰かにメッセージを送った際に、一定時間応答がない人に電話連絡をする。

この三つを検証しました。

大量の監視メールを受けて、特定のメッセージについてSlackに通知する

大量の監視メールを受けて、特定のメッセージについてSlackに通知するという部分ですが、事前の予兆検知も含めると、やはりメールを送っておこうかという方も結構多いと思います。

そうなると、やはりシステムやサービスは時間とともに膨らんでいくものですので、膨らんでいった受信メールをビジネスメールと切り分けして、リアルタイムに気づくようにするというのは中々シビアなことだと思います。

その中でSlackやChatWorkなど、社内で使っているコミュニケーションツールへ通知することにより、いちいち画面を切り替えなくても、すぐに気づけるようにするという点でなかなか実践的で良い検証ではないかなと思っています。

我々のある社内システムで、毎日おおよそ50～100件ぐらいメールを受け取っているものがあるのですが、そこにメールのフィルタリングを入れてみました。
本当にリアルタイムに対応しなければいけないものが、1日1～2件飛んでくるので、それがSlackに実際に飛んでくるかどうか、というのを検証した内容になっています。
左側のルールのところにアラートの送信元と、複数の件名、テストやバッチ処理の結果などをはじくような条件を設定しています。
先ほども申し上げましたようにor の条件はルールを分けないと設定できないようになっています。andの条件を幾つもかけた上で、Slackに投稿する内容はメールの件名・本文・差出人です。それに対して、実際にSlackに通知された情報は右側になっており、この結果Slackへリアルタイムに必要な情報が無事投稿されました。

今度はログ監視メールの通知を不要にする部分。ここは結構シンプルです。我々はZabbixではなくMackerelを使わせていただきました。
Mackerelから送られてきたアラートの内容、その中から今回はステータスがcriticalとなってますが、それがOKになって飛んできますので、「OKを含まなかった場合通知」という処理フローを入れることで、アラート自体は飛んできます。

ただOKが含んでいた場合は飛ばないということを実験して、動作確認も取れました。message.を付けなければいけないところは、注意が必要です。

今次にSlackで＠チャンネルをした際に、一定時間応答がない人に電話連絡をする、というところです。
実際この＠チャンネルはアラート、監視メールと複合的な設定を入れて、Slack側に監視メールでリアルタイムに必要な情報を＠チャンネルで投稿するようにしています。
それに対して一定時間応答がない、運用している人たちが誰もそれをリアルタイムで見ていないという場合に、緊急を促すために電話をする、という二段構えができるというところです。今回はこのメンションの目のマークですね、トリガーに設定をして検証を取りました。目以外をメンションするとアクションしたことにならないので、電話が来てしまいます。
下にメンションのルールを入れていますが、一つだけクセがあり、ルールやスコープ、アクションというのは、Pigeon側の電話番号の設定を含め、必ずSlackのチャンネルに参加している人数分の設定が必要です。この点は少々手間かと思います。
右側にABCとルールがそれぞれ入っていますが、ルールで言うと3人で実験する形を取りました。
ABCそれぞれにメンションの通知のオンとオフ、それぞれ二つ登録しないと、1分間の対応で遅れてメンションを付けてきて人たちはそれを認識できない、つまりメンションしているのに電話がかかってきてしまうということが起きるため、メンションのオンとオフという二つの設定を入れることがポイントです。

スコープの方は、状態を変化させるためだけなので、それぞれ人数分で済んでいます。
このメンションの設定、ルールが入って、スコープの設定をしてアクションに紐付けるという形です。
電話をかけてPigeon側の方でそれぞれガイダンスの文章を読ませているという設定になります。
連携することによって入力する手間が意外とあるのですが、実際に動作確認して検証は取れているので、手間を抜きにすると、機能としてはかなり色々なことができるようになっています。

実践検証―まとめ―

本当に誰でも簡単にできるのかという部分と、本当にアラートフィルタリングとして使えるのかというところで言うと、残念ながら誰でも簡単には設定できない、ということです。
理由は設定マニュアルが少ないので、手探りで設定することになるという点が一番大きいと思っています。
（※現在はクイックガード様と共同で制作したマニュアルを公開中です。https://blog.cloud.kompira.jp/manual）
設定画面に入力している文字は簡単には入れられないようになっていています。これは後ほど説明させていただきます。

そして本当にアラートのフィルタリングとして使えるのかという点ですが、この辺においてはかなり柔軟に設定でき、既存のPigeonと連携することで運用工数削減は、使い方次第でかなり効果が期待できるのではないかなと思っています。

辛口コメントとして、実際にどんな点が簡単に設定できないのか、工数がかかっているのかというところをお話しします。

今後の改良機期待したい部分　―ルールのUIについて―

今後の対応に期待したい部分ということで、やはりUIです。
ルールのUIは、上下の並び替えやグルーピング・サービス・システム別のタグ付けというのができません。
また既存のルールからのコピーができない、テンプレートの作成や保存ができないなどの、UI上の問題があります。
日ごろ運用をやっていらっしゃる方々は分かると思いますが、監視設定と言うのはどこの設定でも同じようなものがどんどん作られていくので、この部分のUIのコントロールがしっかりできるようにならないと、中規模くらいまでは良くても、大規模になると使っていくのは厳しいかなと思います。
またルール表示名は30文字以内なので、もう少し多くなるように改良を期待しています。

次にスコープの部分です。先ほどステータスをコントロールする「深刻度」があるというお話しをしましたが、画面上でゼロにすることができません。
ゼロにしたい場合、ゼロにするアクションは自分で作らなければいけないため、こちらもぜひ改良して欲しいなと思います。
（フィックスポイント注：手動で深刻度をゼロにする機能を追加いたしました。）

次にKompira Cloud APIについてです。Kompira Cloud APIは充実しているものの、例えば下のアクションの部分「アクションID」を確認して、右側の画面でどんな情報が送られてくるかが確認できるようになっているのですが、そのまま入れてもWeb上でエラーになって確認ができない状態になっています。
実際に確認すると、“Token”という言葉が抜けているためにエラーになっていて、補った形でコマンドを打たないといけません。JSON形式で飛んでくるWebhookの状況を確認できないという問題は、早めに修正をして欲しい部分です。

そして運用として一番大変だなと思ったのは、先ほどの処理フローのところにmassege.を付けて入れると言っていた部分の、Webhookの情報を確認する部分です。
”Token”というWeb上から確認はできるのですが、実際のところ”Token”という言葉が抜けているので確認ができません。

確認ができる方法は何かと言いますと、大きく二つあります。
Slackやメールなどで自分宛にメッセージの内容を送信してしまう方法と、APIを使用して自分でCurlコマンドで確かめる方法です。

Slackやメールなどで自分宛にメッセージ全体の内容を送信する

一つ目のSlackやメールなどで、自分宛にメッセージ全体の内容を送信する方法についてです。
画面左側ですが、結構シンプルな構文になっています。
メッセージ内容全体を送るには取得するルール・アクション・スコープを１個ずつ取得するためだけのものを作らなければいけません。これは画面右側でOutgoingのWebhookで設定したチャンネルで、実際にメンションを付けて投稿した画面です。今回作成したルールがアクションと紐づいて、メッセージが自分宛に送信されます。
このような感じで全ての情報がSlackに送られてきますので、ここから自分がルールの処理フローに入れるもののメソッド、いわゆるメトリックを、どこからどう取ってくるかというのを探します。

Slackやメールなどで自分宛にメッセージ全体の内容を送信する

今回はテキストデータの中からメンションを探しているのですが、メンションと言うのはプロフィールで言うところのメンバーIDの情報として送られているので、Messageのところからコンテンツ、データからさらに深掘りして、テキストでユーザーが送られているので、それを含んでいた場合ということで、初めてそこで処理フローに入れる内容が分かるということになります。

APIを使用してコマンドで確かめる

次にAPIを使用してコマンドで確かめるという方法ですが、イベントの部分ですね。
ここで実際に入れたIDを確認して、Curlコマンドを1回打ちます。そうしますと赤字で囲まれた部分で、メッセージIDの確認ができますので、これを確認した後に、ここでもう1回メッセージIDを打って、この二段階でJSONのデータが確認できるようになっています。

これで先ほどと同じように、メンションで送られてくるデータの確認ができるようになります。
Webhookの情報の内容を確認しながら設定できない点が、難解なところかなと思います。

以上が実践検証の結果になります。

ここまでお話しした中で、最後にAlertHub導入をきっかけにKompira導入をお考えのお客様がいらっしゃいましたら、クイックガードでは導入前から導入後のサポートまでを行っていますので、ぜひ一度ご相談いただければと思います。

ご視聴ありがとうございました。

※ご指摘頂いたAlertHubの改善状況については、以下の通りです。（2020/12/4現在）
AlertHubの基本マニュアルを公開致しました
https://blog.cloud.kompira.jp/manual
設定補助ツール公開致しました。
https://blog.cloud.kompira.jp/entry/alerthub-tools
ルール設定数削減の機能改善は引き続き対応を行っております。