$30 off During Our Annual Pro Sale. View Details »

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

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

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

mackerelio

March 03, 2021
Tweet

More Decks by mackerelio

Other Decks in Technology

Transcript

  1. View Slide

  2. 注意事項
    ● 参加者の画面はオフ、音声もオフになっています
    ● 質問がある場合は、ZoomのQ&Aボタンにコメントください
    ○ 気になった質問には「いいね」ボタン  で投票してください。投票の多い質問を優先して回答
    します
    ● チャットはスタッフからのお知らせで使用します。
    ● サポートメンバーについて
    ● 一時的に音声/画質の品質が低下したり、接続が切断されてしまう可能性があ
    ります。予めご了承ください。音声が聞こえにくい場合などはチャットでご連
    絡ください
    ● 投票機能について

    View Slide

  3. Mackerel にぜひアクセスしてみてください
    お手元のWebブラウザのアドレスバーに以下の通りご入力ください。
    まだMackerelをお使いいただいたことのない方は、ブランドサイトが表示されま
    す。すでにアカウントをお持ちの方は、MackerelのWebコンソールが開きます。
    mackerel.io
    サービス名の由来:Mackerel = 「鯖」= サーバー (駄洒落です...

    View Slide

  4. 講師 自己紹介
    Hello!
    ● 三浦 美沙 (id:missasan / @mur_ms_)
    ● 略歴
    ○ SIerでインフラエンジニア
    ○ MSP企業でテクニカルセールスなど
    ○ 2018年3月にMackerel CREとしてジョイン
    ● 技術的なトピック
    ○ サーバー構築 / 運用
    ○ オンプレミス / クラウド

    View Slide

  5. アラートの洪水から脱出!
    Mackerel流の通知活用法

    View Slide

  6. こんな人におすすめ
    ● 監視につきもののアラート・通知をもっと最適化できないか悩んでいる
    ● 長く使っているうちに通知設定がごちゃごちゃしてきて困っている
    ● 通知設定のベストプラクティスが知りたい
    ● Mackerel を更に活用したい

    View Slide

  7. アラートの洪水によるエンジニアの苦労
    ● 本末転倒!重要なアラートが埋もれる
    ○ 大量の通知が飛んでくると、通知を受けるメールやチャットツールのタイムラインもごちゃご
    ちゃに
    ○ その中に潜む重要なアプリケーションのエラーログを見落としてしまうことも...
    ● 優先順位がつけられない
    ○ そもそもアラートが多いと、どこから手を付けてよいのか迷う
    ○ 障害はいつも複合的に起こる
    ■ リソースの負荷増加・アプリケーションのエラー・プラットフォーム障害...etc
    ● 夜も眠れなくなる
    ○ これらが解消しないと、通知に叩き起こされる夜がまたやってくる...

    View Slide

  8. 今日お話したいこと
    ● Mackerelの通知機能の概要
    ● 通知を設計する
    ○ 通知する・しないを判断する
    ○ ステークホルダーによって通知を出し分ける
    ○ 通知の全体像をイメージする
    ● 設定方法・デモ
    ● アンチパターン・活用Tips
    ● まとめ

    View Slide

  9. Mackerelの通知機能の概要

    View Slide

  10. Mackerel のアーキテクチャ
    ● URL外形監視
    ● クラウドインテグレーション
    ● mackerel-agentからの
      push型でのメトリック投稿
    ● 各種通知機能
    監視対象サーバー
    (オンプレ / クラウド / コンテナ)
    各種クラウドサービス
    マネージドサービス
    ● Webコンソール・
      スマートフォンで
      GUIを確認
    時系列データベース
    ▼今日はここを詳しく掘り下げます▼

    View Slide

  11. Mackerelの通知機能の特徴
    ● 豊富な外部サービスとの連携機能
    ● 通知グループ・通知チャンネル機能による、柔軟な通知の出し分けが可能

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 通知を設計する

    View Slide

  17. 通知を考えるうえで必要なこと3点
    ● 通知する・しないを判断する
    ● ステークホルダーによって通知を出し分ける
    ● 通知の全体像をイメージする

    View Slide

  18. 通知する・しないを判断する
    通知するということは、原則として人が何かしら行動を起こす必要があるもの。
    また、行動が具体的な手順に落とし込めるものから通知対象として検討していく。
    事象の緊急度 例 監視 通知
    高:すぐに対応が必要 SLIが低下するもの
    ユーザーが期待する機能が提供できていな
    い状態を表すもの
    する する
    中:すぐに対応は必要
      ないが気づきたい
    すぐに対応する必要はないが放置していると
    いずれ障害になるもの
    する する
    低:記録・観測のみ
      でよい
    単体では対応が必要ないもの
    障害の原因を切り分ける参考になるもの
    する しない

    View Slide

  19. ステークホルダーによって通知を出し分ける
    サービス(システム)の運用には複数のステークホルダーが関わっているもの
    ステークホルダーはそれぞれの役割によって、障害について知りたいことのレベル
    や観点が違う
    例)
    ● 開発部門
    ● インフラ部門
    ● 企画部門
    ● サポート部門

    View Slide

  20. ステークホルダーの知りたいこと(例)
    障害時の役割
    システムの障害対応をメイン
    で行う。障害時の原因究明、
    暫定対応、その後の根本対策
    などを行う。
    知りたいこと
    ユーザー影響の有無に関わら
    ずアラートは基本的にすべて
    通知を受け取りたい。
    開発・インフラ部門
    障害時の役割
    ユーザーへの対応判断(告知
    など)や事業への影響を分析
    し、今後の開発計画などに
    フィードバックする。
    知りたいこと
    ユーザー影響がある障害が起
    こった際は、いち早く通知を
    受け取りたい。
    企画部門
    障害時の役割
    ユーザーからの問い合わせが
    合った際に、発生している障
    害の対応状況や影響範囲を確
    認し回答する。
    知りたいこと
    問い合わせがあったときに、
    都度障害対応の経緯を確認し
    て、最新の状況がわかればよ
    い。
    サポート部門

    View Slide

  21. ステークホルダーごとの通知の要件を整理する
    開発・インフラ部門
    企画部門
    サポート部門
    (基本的には通知は受けない)
    システムの障害対応
    対応
    ユーザーへの告知
    ユーザーからの問合せ対応
    例)CPU使用率
    中:ユーザー影響はないが継続す
    るようなら対応を検討する
    事象の緊急度
    例)外形監視
    高:ユーザー影響が出ている

    View Slide

  22. Mackerelでの通知の全体像をイメージする
    企画
    channel
    CPU使用率
    70% Warning
    90% Critical
    Default
    通知グループ

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

    View Slide

  23. 設定方法・デモ

    View Slide

  24. 通知チャンネルの設定
    24
    通知グループ・通知チャンネルの一覧は
    「Channels」で確認できます。
    初期状態では、全てのアラートが登録されたアカ
    ウントのメールアドレス宛てに通知される設定に
    なっています。
    新しい通知グループ・通知チャンネルを作成する
    ときは、右上の「通知グループ/通知チャンネルを
    追加」をクリックします。
    メール通知や、Slackなどアラートの通知に使用し
    た方法をクリックし、必要な項目を入力して「作
    成」します。

    View Slide

  25. 通知グループの設定
    25
    新しい通知グループを作成するときは通知チャン
    ネルと同じく、右上の「通知グループ/通知チャン
    ネルを追加」をクリックします。
    一番上の「通知グループ」を選択し、通知対象を
    サービス単位、または監視ルール単位で指定しま
    す。何も指定しないと通知は行われません。
    通知する先の通知チャンネルを選択します。

    View Slide

  26. アンチパターン・活用Tips

    View Slide

  27. アンチパターン
    こんな運用していませんか?
    ● 監視ルールを追加する度に通知グループを追加・変更している
    ● アラート通知が多いので通知グループを変更する

    View Slide

  28. 通知グループを追加・変更する前に...
    通知グループは、運用体制に密接にかかわります。通知グループを追加するという
    ことは、誰が何のアラートを検知し、対応する(しない)かという運用ルールを変
    更したい場合です。
    SLIの設計が変わった、ステークホルダーが増えた、特定のアラートは別チームに対
    応を依頼することになった、などの場合です。
    監視ルールを追加したらすでに設定してある通知グループに則って通知されるよ
    う、通知グループ設定をシンプルに留めておくことがおすすめです。アラート通知
    が多いので通知を減らしたい、などの場合は、監視ルールを見直されるのがおすす
    めです。

    View Slide

  29. 設定追加前
      メール
     Slack
    CPU使用率
    70% Warning
    90% Critical
    サービスA
    通知グループ
    サービスA
    CPU使用率
    サービスB
    通知グループ
    サービスB
    CPU使用率
    メトリック
    監視
    ルール
    通知
    グループ
    通知
    チャンネル

    View Slide

  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を触り始めたばかりの新メ
    ンバーに監視ルールの追加を依頼し

    アンチパターン①

    View Slide

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

    View Slide

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

    View Slide

  33. 通知が必要ない監視ルールを削除
      メール
     Slack
    CPU使用率
    70% Warning
    90% Critical
    サービスA
    通知グループ
    サービスA
    CPU使用率
    サービスB
    通知グループ
    サービスB
    CPU使用率
    メトリック
    監視
    ルール
    通知
    グループ
    通知
    チャンネル
    サービスB
    メモリ使用率
    メモリ使用率
    70% Warning
    90% Critical
    CHANGE
    ポイント:
    通知が不要=人の対応が不要。アラーティング自体が不要な
    ケースが考えられる。
    アンチパターン②:回避策

    View Slide

  34. 通知しないものの取り扱い
    ● 監視ルールのチューニング・削除を検討する
    ○ アラートが上がりすぎて狼少年になっていないか?
    ○ 平均値監視、最大試行回数をチューニングする
    ○ 閾値をCriticalのみ、Warningのみにする
    ○ 監視ルールを削除、通知から除外してもよい可能性を検討する
    ● 定期的に能動的に観測する
    ○ カスタムダッシュボードを作成し、運用定例などを開催してシステムの傾向を把握、キャパシ
    ティプランニングをする
    ● アラート一覧で確認する
    ○ アラートグループ機能を使って同じ時間帯に発生したアラートをまとめてみる

    View Slide

  35. 活用Tips
    ● シフト用の携帯電話に自動架電したい
    ● 自動復旧の仕組みを実装したい
    ● さまざまな通知チャンネルによる連携機能
    ● Mackerelの設定変更を通知する
    ● 一時的に監視を止めたい

    View Slide

  36. シフト用の携帯電話に自動架電したい
    確実性と自由度の高い通知を低コストで実現
    ● アラート通知にクラウド架電サービスのTwilioをサポート
    ● TwiMLを活用してメンバーへ順番に架電も
    API
    SMS
    自動架電
    Twilio にアラートを通知する

    View Slide

  37. 自動復旧の仕組みを実装したい
    通知チャンネルのWebhook連携を活用し、自動復旧を実装
    ● 例)MackerelのWebhookとAWSの API Gateway + Lambda を組み合わせ EC2
    の自動再起動を実装する
    API Gateway
    Webhook
    Lambda EC2
    再起動

    View Slide

  38. さまざまな通知チャンネルによる連携機能

    View Slide

  39. Mackerelの設定変更を通知する
    通知チャンネルで通知するイベントを指
    定することでMackerelの設定変更を通知
    することができます。
    ● ホストステータスの変更
    ● ホスト登録・退役
    ● 監視ルールの操作
    ※一部の通知チャンネルで利用できます

    View Slide

  40. 一時的に監視を止めたい
    ダウンタイム機能を利用してメンテナンス
    中や、障害が長期化しているときなどに時
    間を指定して監視を停止することができま
    す。
    Mackerel Drink Up #9 - ダウンタイムの紹介

    View Slide

  41. まとめ
    はじめから厳密に通知設定を行おうと思わず、必要なものが適切に通知されるよう
    監視・通知設定をチューニングしていきましょう
    ● 人が何かしら行動を起こす必要があるもの、行動が具体的な手順に落とし込め
    るを通知する
    ● 通知設定を変更をしたくなったら、監視ルールが適切か見直してみる
    ● 監視ルール・通知設定を日々チューニングする
    監視は完璧に整えておくものではなく、
    運用しながら育てるものです

    View Slide

  42. ”監視は育てるもの”

    View Slide

  43. もしMackerelを使ってみたくなったら...
    mackerel.io から 「無料で試してみる」をクリック!

    View Slide

  44. Mackerel がご提供できるサポート
    ● PoC計画サポート
    ● ハンズオン・各種セミナー
    ● WBSサンプルご提供
    ● 設定サンプルご提供
    ● テクニカルサポート
    ▼まず話を聞いてみたい方はこちらから
    https://calendly.com/mackerel/online-sodankai

    View Slide

  45. 質疑応答
    https://forms.gle/1i9arMPCGsQvb3Lx9
    ▼アンケートにご回答ください▼

    View Slide