7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

mackerelで監視した後の一次対応を自動化する話

Posted at

はじめに

監視システムからアラートを受信した後におこなう対応のうち、手順が決まっていて誰がやっても同じ部分(一次対応)を自動化して、その後対応するエンジニアが楽になるようにお膳立てします。

監視アラート対応

監視から通知される情報は、一時点・一監視項目(メトリクス)の情報にすぎません。
対応するエンジニアが適切な診断・正しい対応判断するためには情報不足であり、追加でその周辺情報や時系列遷移を情報収集するという作業が毎回発生しています。

今回はこの情報収集作業を、監視の通知がされたらすぐに自動で行われるようにします。

これができると、

  • エンジニアが情報収集作業を飛ばして、即時に対応が開始できるようになります。
    なんといっても楽ですし、復旧時間を短縮でき、障害によるサービスレベルの低下・損失を最小化できます。
  • CPU使用率やメモリ使用率の一過性の閾値超過など、エンジニアが確認したときには既に解消してしまっていて何がおこっていたのか判断する材料がない!という状況を改善できます。
    情報収集をタイムリーにおこなう仕組みができあがるため、判断材料がなくて原因判明までに時間がかかるという問題を解決できます。
  • エンジニアは、情報収集の結果・ログの記録をチケットに添付し忘れたり、後日まとめて整理して記録するといった面倒から解放されます。

対応フロー

自動化したあとの監視アラート対応のフロー図(一部)です。(〇がスタート)
この図の一次対応のレーンを自動化します。

mackerel-action.png

対応フロー説明と設定のポイント

  • 通知
    • 異常をmackerelが検知し、Slack通知とWebhook通知をおこないます。
      • Slack通知では「関連するグラフを表示」を有効にします。
      • Webhook通知の通知先は、FrontOpsで作成したNgrokのエンドポイントを指定します。
  • Slack通知
    • 二次対応担当者はSlackで異常発生を認知します。また時系列グラフをみて傾向をつかみます
  • Webhook通知
    • FrontOpsは、Webhook通知を受けてフローを開始します。
  • 実機確認・情報収集
    • 異常が検出された対象ホストにSSHでログインして情報収集をおこないます
      • 対象ホストの情報は、通知データに含まれるhostsデータから取得します。
        • mackerelのhostデータには、外部IPアドレスを保持するプロパティがありません。代わりにmemoプロパティをIPアドレス登録用に使用することにしました。
    • 情報収集には、アラート種別に応じたコマンドを使います。
      • 共通
        • hostnamewlast -5 で、ログインしているホストが正しいか、誰かがログインして作業していないか、サーバが再起動していないか確認します
      • CPU|loadavg の場合
        • toppsを使ってどのプロセスがリソースを使っているのか確認します。
      • Memory|Swap の場合
        • topfreeを使って、どのプロセスがメモリを使っているのか、メモリ使用状況がどうかを確認します
      • Filesystemの場合
        • df を使って、ディスク全体の状態を確認します。
          • mackerelのアラートデータには、対象デバイス情報が含まれていません。対象デバイス情報がとれれば、find ${mountpoint} -mmin -1 -ls で最近更新されているファイルリストも取得したいところ。
  • チケット作成・更新
    • Redmineのチケットを作成して収集した情報を記録します
      • Webhook通知で受信したデータ
        • 元のJSONのままでは可読性が低いので、YAML形式にして記録します
      • 情報収集コマンドの結果
        • 標準出力の結果を記録します
  • Slack通知
    • 追加で収集したデータとチケットのURLをSlack通知します
    • 二次対応担当者は、追加データをみて状況把握し、対応判断をおこない以降の対応をおこないます

二次対応者のSlack画面

  • Mackerelからのアラート通知の後に、情報収集した結果とチケットURLが補足添付されます。
    二次対応者は自分で情報を集めて回る必要がなく、Slack上に判断材料が準備されるおかげで、迅速に診断・対応判断が行えます。

mackerel-slack.png

仕組み

mackerel-action-picture.png

次回に続く

この仕組みの作り方は次回に続きます。
mackerl-flow-overview.png

使うもの

  1. 監視にはmackerelを使います
  • Webhookを使って一次対応ツールと連携させます
  • mackerelは通知メッセージに監視項目の時系列グラフを含めることができます
    • 時系列観点での判断情報提供を標準で行っている点が気に入っています
  1. 一次対応には FrontOpsを使います
  • FrontOpsを動かすPC1台
  • 従来なかった新カテゴリのツールです。ターミナル操作はもちろん、電話やチャット、ブラウザ操作まで一次対応者が使う大半の道具をワークフローの中で操作できます
    • 2017年11月リリースしたばかりの新ソフトです。今までこのようなツールがなかったので作りました。
  1. チケットにはRedmineを使います
  2. エンジニアとのコミュニケーションにはSlackを使います
7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?