2020年11月18日に開催したMackerel オンラインセミナー「はじめてのMackerel 〜アラートの洪水から脱出! Mackerel流の通知活用法〜」の発表資料です。
Online Seminar2020.09.24
View Slide
注意事項● 参加者の画面はオフ、音声もオフになっています● 質問がある場合は、ZoomのQ&Aボタンにコメントください○ 気になった質問には「いいね」ボタン で投票してください。投票の多い質問を優先して回答します● チャットはスタッフからのお知らせで使用します。● サポートメンバーについて● 一時的に音声／画質の品質が低下したり、接続が切断されてしまう可能性があります。予めご了承ください。音声が聞こえにくい場合などはチャットでご連絡ください● 投票機能について
Mackerel にぜひアクセスしてみてくださいお手元のWebブラウザのアドレスバーに以下の通りご入力ください。まだMackerelをお使いいただいたことのない方は、ブランドサイトが表示されます。すでにアカウントをお持ちの方は、MackerelのWebコンソールが開きます。mackerel.ioサービス名の由来：Mackerel = 「鯖」= サーバー （駄洒落です...
講師 自己紹介Hello!● 三浦 美沙 （id:missasan / @mur_ms_）● 略歴○ SIerでインフラエンジニア○ MSP企業でテクニカルセールスなど○ 2018年3月にMackerel CREとしてジョイン。現在はCREチーム サブディレクター● 技術的なトピック○ サーバー構築 / 運用○ オンプレミス / クラウド
アラートの洪水から脱出!Mackerel流の通知活用法
こんな人におすすめ● 監視につきもののアラート・通知をもっと最適化できないか悩んでいる● 長く使っているうちに通知設定がごちゃごちゃしてきて困っている● 通知設定のベストプラクティスが知りたい● Mackerel を更に活用したい
アラートの洪水によるエンジニアの苦労● 本末転倒！重要なアラートが埋もれる○ 大量の通知が飛んでくると、通知を受けるメールやチャットツールのタイムラインもごちゃごちゃに○ その中に潜む重要なアプリケーションのエラーログを見落としてしまうことも...● 優先順位がつけられない○ そもそもアラートが多いと、どこから手を付けてよいのか迷う○ 障害はいつも複合的に起こる■ リソースの負荷増加・アプリケーションのエラー・プラットフォーム障害...etc● 夜も眠れなくなる○ これらが解消しないと、通知に叩き起こされる夜がまたやってくる...
今日お話したいこと● Mackerelの通知機能の概要● 通知を設計する○ 通知する・しないを判断する○ ステークホルダーによって通知を出し分ける○ 通知の全体像をイメージする● 設定方法・デモ● アンチパターン・活用Tips● まとめ
Mackerelの通知機能の概要
Mackerel のアーキテクチャ● URL外形監視● クラウドインテグレーション● mackerel-agentからの push型でのメトリック投稿● 各種通知機能監視対象サーバー（オンプレ / クラウド / コンテナ）各種クラウドサービスマネージドサービス● Webコンソール・ スマートフォンで GUIを確認時系列データベース▼今日はここを詳しく掘り下げます▼
Mackerelの通知機能の特徴● 豊富な外部サービスとの連携機能● 通知グループ・通知チャンネル機能による、柔軟な通知の出し分けが可能
Mackerelの通知機能 メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネルアラートサービスA ホストxxCPU使用率 90% Critical
アラートサービスA ホストxxCPU使用率 90% CriticalMackerelの通知機能 メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネル
アラートの洪水はなぜ起きるのか● 厳密すぎる設定によってセンシティブに通知されすぎている○ 予測できない未来の事象に対して厳密に通知設定しすぎている○ 通知を受け取ったが...■ 収束するまで様子を見るだけ■ 問題ないことをログから確認してクローズする● メンテナンスされていない通知設定がそのまま運用され続ける○ 一度設定した通知設定を削除するのは怖い○ 追加する運用はしていても、削除する運用は回っていない
アラートの洪水はなぜ起きるのか● 厳密すぎる設定によってセンシティブに通知されすぎている○ 予測できない未来の事象に対して厳密に通知設定しすぎている○ 通知を受け取ったが...■ 収束するまで様子を見るだけ■ 問題ないことをログから確認してクローズする● メンテナンスされていない通知設定がそのまま運用され続ける○ 一度設定した通知設定を削除するのは怖い○ 追加する運用はしていても、削除する運用は回っていない通知設定をシンプルに保ち続けることが重要！
通知を設計する
通知を考えるうえで必要なこと3点● 通知する・しないを判断する● ステークホルダーによって通知を出し分ける● 通知の全体像をイメージする
通知する・しないを判断する通知するということは、原則として人が何かしら行動を起こす必要があるもの。また、行動が具体的な手順に落とし込めるものから通知対象として検討していく。事象の緊急度 例 監視 通知高：すぐに対応が必要 SLIが低下するものユーザーが期待する機能が提供できていない状態を表すものする する中：すぐに対応は必要 ないが気づきたいすぐに対応する必要はないが放置しているといずれ障害になるものする する低：記録・観測のみ でよい単体では対応が必要ないもの障害の原因を切り分ける参考になるものする しない
ステークホルダーによって通知を出し分けるサービス（システム）の運用には複数のステークホルダーが関わっているものステークホルダーはそれぞれの役割によって、障害について知りたいことのレベルや観点が違う例）● 開発部門● インフラ部門● 企画部門● サポート部門
ステークホルダーの知りたいこと（例）障害時の役割システムの障害対応をメインで行う。障害時の原因究明、暫定対応、その後の根本対策などを行う。知りたいことユーザー影響の有無に関わらずアラートは基本的にすべて通知を受け取りたい。開発・インフラ部門障害時の役割ユーザーへの対応判断（告知など）や事業への影響を分析し、今後の開発計画などにフィードバックする。知りたいことユーザー影響がある障害が起こった際は、いち早く通知を受け取りたい。企画部門障害時の役割ユーザーからの問い合わせが合った際に、発生している障害の対応状況や影響範囲を確認し回答する。知りたいこと問い合わせがあったときに、都度障害対応の経緯を確認して、最新の状況がわかればよい。サポート部門
ステークホルダーごとの通知の要件を整理する開発・インフラ部門企画部門サポート部門（基本的には通知は受けない）システムの障害対応対応ユーザーへの告知ユーザーからの問合せ対応例）CPU使用率中：ユーザー影響はないが継続するようなら対応を検討する事象の緊急度例）外形監視高：ユーザー影響が出ている
Mackerelでの通知の全体像をイメージする企画channelCPU使用率70% Warning90% CriticalDefault通知グループ※サービスACPU使用率サービスA緊急度高通知グループメトリック監視ルール通知グループ通知チャンネルサービスA外形監視開発・インフラ部門企画部門運用channelサポート部門（基本的には通知は受けない）※ Default通知グループとは？デフォルトで設定されている通知グループ。オーガニゼーションの全てのサービスの全てのアラートを登録している通知チャンネルに投稿する。デフォルトでは、オーガニゼーションに登録されたアカウントにメール通知を行う設定になっている。
設定方法・デモ
通知チャンネルの設定24通知グループ・通知チャンネルの一覧は「Channels」で確認できます。初期状態では、全てのアラートが登録されたアカウントのメールアドレス宛てに通知される設定になっています。新しい通知グループ・通知チャンネルを作成するときは、右上の「通知グループ/通知チャンネルを追加」をクリックします。メール通知や、Slackなどアラートの通知に使用した方法をクリックし、必要な項目を入力して「作成」します。
通知グループの設定25新しい通知グループを作成するときは通知チャンネルと同じく、右上の「通知グループ/通知チャンネルを追加」をクリックします。一番上の「通知グループ」を選択し、通知対象をサービス単位、または監視ルール単位で指定します。何も指定しないと通知は行われません。通知する先の通知チャンネルを選択します。
アンチパターン・活用Tips
アンチパターンこんな運用していませんか？● 監視ルールを追加する度に通知グループを追加・変更している● アラート通知が多いので通知グループを変更する
通知グループを追加・変更する前に...通知グループは、運用体制に密接にかかわります。通知グループを追加するということは、誰が何のアラートを検知し、対応する（しない）かという運用ルールを変更したい場合です。SLIの設計が変わった、ステークホルダーが増えた、特定のアラートは別チームに対応を依頼することになった、などの場合です。監視ルールを追加したらすでに設定してある通知グループに則って通知されるよう、通知グループ設定をシンプルに留めておくことがおすすめです。アラート通知が多いので通知を減らしたい、などの場合は、監視ルールを見直されるのがおすすめです。
設定追加前 メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネル
監視ルールを追加する度に通知グループを追加 メール SlackCPU使用率70% Warning90% CriticalサービスACPU使用率通知グループサービスACPU使用率サービスBCPU使用率通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネルサービスBメモリ使用率メモリ使用率70% Warning90% CriticalサービスBメモリ使用率通知グループNEW! NEW! NEW!ケース：Mackerelを触り始めたばかりの新メンバーに監視ルールの追加を依頼したアンチパターン①
すでにある通知グループから通知されるようにする メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネルサービスBメモリ使用率メモリ使用率70% Warning90% CriticalNEW! NEW!ポイント：通知グループを細かく設定しすぎない。監視ルールを追加しても通知グループを変更しないで済むようにシンプルに保つのがコツ。アンチパターン①：回避策
アラート通知が多いので通知グループを変更 メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループ【オプション】CriticalOnlyサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネルサービスBメモリ使用率メモリ使用率70% Warning90% CriticalCHANGEケース：通知を減らしたいので、通知設定を変更しようと思いこんでしまうアンチパターン②
通知が必要ない監視ルールを削除 メール SlackCPU使用率70% Warning90% CriticalサービスA通知グループサービスACPU使用率サービスB通知グループサービスBCPU使用率メトリック監視ルール通知グループ通知チャンネルサービスBメモリ使用率メモリ使用率70% Warning90% CriticalCHANGEポイント：通知が不要＝人の対応が不要。アラーティング自体が不要なケースが考えられる。アンチパターン②：回避策
通知しないものの取り扱い● 監視ルールのチューニング・削除を検討する○ アラートが上がりすぎて狼少年になっていないか？○ 平均値監視、最大試行回数をチューニングする○ 閾値をCriticalのみ、Warningのみにする○ 監視ルールを削除、通知から除外してもよい可能性を検討する● 定期的に能動的に観測する○ カスタムダッシュボードを作成し、運用定例などを開催してシステムの傾向を把握、キャパシティプランニングをする● アラート一覧で確認する○ アラートグループ機能を使って同じ時間帯に発生したアラートをまとめてみる
活用Tips● シフト用の携帯電話に自動架電したい● 自動復旧の仕組みを実装したい● さまざまな通知チャンネルによる連携機能● Mackerelの設定変更を通知する● 一時的に監視を止めたい
シフト用の携帯電話に自動架電したい確実性と自由度の高い通知を低コストで実現● アラート通知にクラウド架電サービスのTwilioをサポート● TwiMLを活用してメンバーへ順番に架電もAPISMS自動架電Twilio にアラートを通知する
自動復旧の仕組みを実装したい通知チャンネルのWebhook連携を活用し、自動復旧を実装● 例）MackerelのWebhookとAWSの API Gateway + Lambda を組み合わせ EC2の自動再起動を実装するAPI GatewayWebhookLambda EC2再起動
さまざまな通知チャンネルによる連携機能
Mackerelの設定変更を通知する通知チャンネルで通知するイベントを指定することでMackerelの設定変更を通知することができます。● ホストステータスの変更● ホスト登録・退役● 監視ルールの操作※一部の通知チャンネルで利用できます
一時的に監視を止めたいダウンタイム機能を利用してメンテナンス中や、障害が長期化しているときなどに時間を指定して監視を停止することができます。Mackerel Drink Up #9 - ダウンタイムの紹介
まとめはじめから厳密に通知設定を行おうと思わず、必要なものが適切に通知されるよう監視・通知設定をチューニングしていきましょう● 人が何かしら行動を起こす必要があるもの、行動が具体的な手順に落とし込めるを通知する● 通知設定を変更をしたくなったら、監視ルールが適切か見直してみる● 監視ルール・通知設定を日々チューニングする監視は完璧に整えておくものではなく、運用しながら育てるものです
”監視は育てるもの”
もしMackerelを使ってみたくなったら...mackerel.io から 「無料で試してみる」をクリック！
Mackerel がご提供できるサポート● PoC計画サポート● ハンズオン・各種セミナー● WBSサンプルご提供● 設定サンプルご提供● テクニカルサポート▼まず話を聞いてみたい方はこちらからhttps://calendly.com/mackerel/online-sodankai
mackerelio
tomoaki25
tacck
sansantech
poteboy
revcomm_inc
oldbigbuddha
kazuhitotakahashi
chloe463
coconala_engineer
knsg16
kawagoi
is_ryo
destraynor
addyosmani
mongodb
vanstee
mthomps
eileencodes
lara
sugarenia
chrislema
jlugia
frogandcode
holman