Upgrade to Pro — share decks privately, control downloads, hide ads and more …

はじめてのMackerel 〜アラートの洪水から脱出! Mackerel流の通知活用法〜 /...

mackerelio
November 18, 2020

はじめてのMackerel 〜アラートの洪水から脱出! Mackerel流の通知活用法〜 / Mackerel Online Seminar 20201118

2020年11月18日に開催したMackerel オンラインセミナー「はじめてのMackerel 〜アラートの洪水から脱出! Mackerel流の通知活用法〜」の発表資料です。

mackerelio

November 18, 2020
Tweet

More Decks by mackerelio

Other Decks in Technology

Transcript

  1. 注意事項 • 参加者の画面はオフ、音声もオフになっています • 質問がある場合は、ZoomのQ&Aボタンにコメントください ◦ 気になった質問には「いいね」ボタン  で投票してください。投票の多い質問を優先して回答 します • チャットはスタッフからのお知らせで使用します。

    • サポートメンバーについて • 一時的に音声/画質の品質が低下したり、接続が切断されてしまう可能性があ ります。予めご了承ください。音声が聞こえにくい場合などはチャットでご連 絡ください • 投票機能について
  2. 講師 自己紹介 Hello! • 三浦 美沙 (id:missasan / @mur_ms_) •

    略歴 ◦ SIerでインフラエンジニア ◦ MSP企業でテクニカルセールスなど ◦ 2018年3月にMackerel CREとしてジョイン。現在はCREチーム サブディ レクター • 技術的なトピック ◦ サーバー構築 / 運用 ◦ オンプレミス / クラウド
  3. アラートの洪水によるエンジニアの苦労 • 本末転倒!重要なアラートが埋もれる ◦ 大量の通知が飛んでくると、通知を受けるメールやチャットツールのタイムラインもごちゃご ちゃに ◦ その中に潜む重要なアプリケーションのエラーログを見落としてしまうことも... • 優先順位がつけられない

    ◦ そもそもアラートが多いと、どこから手を付けてよいのか迷う ◦ 障害はいつも複合的に起こる ▪ リソースの負荷増加・アプリケーションのエラー・プラットフォーム障害...etc • 夜も眠れなくなる ◦ これらが解消しないと、通知に叩き起こされる夜がまたやってくる...
  4. Mackerel のアーキテクチャ • URL外形監視 • クラウドインテグレーション • mackerel-agentからの   push型でのメトリック投稿

    • 各種通知機能 監視対象サーバー (オンプレ / クラウド / コンテナ) 各種クラウドサービス マネージドサービス • Webコンソール・   スマートフォンで   GUIを確認 時系列データベース ▼今日はここを詳しく掘り下げます▼
  5. Mackerelの通知機能   メール  Slack CPU使用率 70% Warning 90% Critical サービスA 通知グループ

    サービスA CPU使用率 サービスB 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル アラート サービスA ホストxx CPU使用率 90% Critical
  6. アラート サービスA ホストxx CPU使用率 90% Critical Mackerelの通知機能   メール  Slack CPU使用率

    70% Warning 90% Critical サービスA 通知グループ サービスA CPU使用率 サービスB 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル
  7. アラートの洪水はなぜ起きるのか • 厳密すぎる設定によってセンシティブに通知されすぎている ◦ 予測できない未来の事象に対して厳密に通知設定しすぎている ◦ 通知を受け取ったが... ▪ 収束するまで様子を見るだけ ▪

    問題ないことをログから確認してクローズする • メンテナンスされていない通知設定がそのまま運用され続ける ◦ 一度設定した通知設定を削除するのは怖い ◦ 追加する運用はしていても、削除する運用は回っていない
  8. アラートの洪水はなぜ起きるのか • 厳密すぎる設定によってセンシティブに通知されすぎている ◦ 予測できない未来の事象に対して厳密に通知設定しすぎている ◦ 通知を受け取ったが... ▪ 収束するまで様子を見るだけ ▪

    問題ないことをログから確認してクローズする • メンテナンスされていない通知設定がそのまま運用され続ける ◦ 一度設定した通知設定を削除するのは怖い ◦ 追加する運用はしていても、削除する運用は回っていない 通知設定をシンプルに保ち続けることが重要!
  9. 通知する・しないを判断する 通知するということは、原則として人が何かしら行動を起こす必要があるもの。 また、行動が具体的な手順に落とし込めるものから通知対象として検討していく。 事象の緊急度 例 監視 通知 高:すぐに対応が必要 SLIが低下するもの ユーザーが期待する機能が提供できていな

    い状態を表すもの する する 中:すぐに対応は必要   ないが気づきたい すぐに対応する必要はないが放置していると いずれ障害になるもの する する 低:記録・観測のみ   でよい 単体では対応が必要ないもの 障害の原因を切り分ける参考になるもの する しない
  10. ステークホルダーの知りたいこと(例) 障害時の役割 システムの障害対応をメイン で行う。障害時の原因究明、 暫定対応、その後の根本対策 などを行う。 知りたいこと ユーザー影響の有無に関わら ずアラートは基本的にすべて 通知を受け取りたい。

    開発・インフラ部門 障害時の役割 ユーザーへの対応判断(告知 など)や事業への影響を分析 し、今後の開発計画などに フィードバックする。 知りたいこと ユーザー影響がある障害が起 こった際は、いち早く通知を 受け取りたい。 企画部門 障害時の役割 ユーザーからの問い合わせが 合った際に、発生している障 害の対応状況や影響範囲を確 認し回答する。 知りたいこと 問い合わせがあったときに、 都度障害対応の経緯を確認し て、最新の状況がわかればよ い。 サポート部門
  11. Mackerelでの通知の全体像をイメージする 企画 channel CPU使用率 70% Warning 90% Critical Default 通知グループ

    ※ サービスA CPU使用率 サービスA 緊急度高 通知グループ メトリック 監視 ルール 通知 グループ 通知 チャンネル サービスA 外形監視 開発・インフラ部門 企画部門 運用 channel サポート部門 (基本的には通知は 受けない) ※ Default通知グループとは? デフォルトで設定されている通知グループ。オーガニゼーションの全てのサービスの全てのアラートを登録している通知チャンネ ルに投稿する。デフォルトでは、オーガニゼーションに登録されたアカウントにメール通知を行う設定になっている。
  12. 設定追加前   メール  Slack CPU使用率 70% Warning 90% Critical サービスA 通知グループ

    サービスA CPU使用率 サービスB 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル
  13. 監視ルールを追加する度に通知グループを追加   メール  Slack CPU使用率 70% Warning 90% Critical サービスA CPU使用率

    通知グループ サービスA CPU使用率 サービスB CPU使用率 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル サービスB メモリ使用率 メモリ使用率 70% Warning 90% Critical サービスB メモリ使用率 通知グループ NEW! NEW! NEW! ケース: Mackerelを触り始めたばかりの新メ ンバーに監視ルールの追加を依頼し た アンチパターン①
  14. すでにある通知グループから通知されるようにする   メール  Slack CPU使用率 70% Warning 90% Critical サービスA 通知グループ

    サービスA CPU使用率 サービスB 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル サービスB メモリ使用率 メモリ使用率 70% Warning 90% Critical NEW! NEW! ポイント: 通知グループを細かく設定しすぎない。監視ルールを追加しても 通知グループを変更しないで済むようにシンプルに保つのがコ ツ。 アンチパターン①:回避策
  15. アラート通知が多いので通知グループを変更   メール  Slack CPU使用率 70% Warning 90% Critical サービスA 通知グループ

    サービスA CPU使用率 サービスB 通知グループ 【オプション】 CriticalOnly サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル サービスB メモリ使用率 メモリ使用率 70% Warning 90% Critical CHANGE ケース: 通知を減らしたいので、通知設定を 変更しようと思いこんでしまう アンチパターン②
  16. 通知が必要ない監視ルールを削除   メール  Slack CPU使用率 70% Warning 90% Critical サービスA 通知グループ

    サービスA CPU使用率 サービスB 通知グループ サービスB CPU使用率 メトリック 監視 ルール 通知 グループ 通知 チャンネル サービスB メモリ使用率 メモリ使用率 70% Warning 90% Critical CHANGE ポイント: 通知が不要=人の対応が不要。アラーティング自体が不要な ケースが考えられる。 アンチパターン②:回避策
  17. 通知しないものの取り扱い • 監視ルールのチューニング・削除を検討する ◦ アラートが上がりすぎて狼少年になっていないか? ◦ 平均値監視、最大試行回数をチューニングする ◦ 閾値をCriticalのみ、Warningのみにする ◦

    監視ルールを削除、通知から除外してもよい可能性を検討する • 定期的に能動的に観測する ◦ カスタムダッシュボードを作成し、運用定例などを開催してシステムの傾向を把握、キャパシ ティプランニングをする • アラート一覧で確認する ◦ アラートグループ機能を使って同じ時間帯に発生したアラートをまとめてみる
  18. Mackerel がご提供できるサポート • PoC計画サポート • ハンズオン・各種セミナー • WBSサンプルご提供 • 設定サンプルご提供

    • テクニカルサポート ▼まず話を聞いてみたい方はこちらから https://calendly.com/mackerel/online-sodankai