オンラインセミナー資料「はじめてのMackerel 〜アラートの洪水から脱出! Mackerel流の通知活用法〜」20210303

2021年3月3日（水）11時開催当該セミナーの講演資料です。

Transcript

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