スタートガイド > 3. アラートを受け取って自動対応しよう > 3-11. アラートを受け取ったら、自動で復旧処理を行いたい

3-11. アラートを受け取ったら、自動で復旧処理を行いたい

アラートを受け取ったら自動で復旧処理を行い、復旧できなかった場合に担当者に連絡したいケースの実現例を示します。

1. 要件

1-1. 監視対象サービス

アラートが発生したら、件名に ERROR を含むメールをOpsAidへ送信する
対象サービスの状態が回復したら、件名にOKを含むメールをOpsAidへ送信する

1-2. OpsAid

件名にERRORを含むアラートを受信したら、AWS CLIコマンドを実行してEC2インスタンスを再起動する
アラートの受信から10分後に担当者のユーザー01(組織に登録済み)に電話発信する
アラートを受信してから10分以内に、件名にOKを含むアラートを受信したら、電話発信をキャンセルする

2. OpsAidの登録内容

以下の内容で、OpsAid側のアラート受信準備を行います。

2-1. プロジェクト作成

1-1. プロジェクトを用意しように従って、アラートを受信するプロジェクトを作成します。アラートを受信するプロジェクトが既に作成されている場合は、このセクションは飛ばして構いません。

プロジェクトのメールアドレスが発行されたら、メモを取っておきます。

2-2. 担当者ユーザーをプロジェクトに追加

2-1. で用意したプロジェクトに、担当者のユーザー01のユーザーを追加します。
設定方法は

3-1. アラートが発生したら担当者に電話で通知したい
　> 2-2. 担当者ユーザーをプロジェクトに追加

を参照してください。

2-3. ルール登録

アラートを受信するプロジェクトに、ルールを1件登録します。
ルールの条件には以下の内容を設定します。

マッチ条件

「検知条件・キャンセル条件で設定する」のタブを選択します

検知条件
- 「件名」に「ERROR」が含まれる

待機時間
- 「10」分間

キャンセル条件
- 「件名」に「OK」が含まれる

再処理禁止時間
- 「10」分間

件名に ERROR を含むアラートを受信したら、このルールを適用します。
10分以内に件名にOKを含むアラートを受信したら、アクション実行をキャンセルし、受信しなかった場合はアクションを実行します。

検知時に実行する処理

AWS CLI
- コマンド名: 実行するコマンドを区別するための名称
  例) インスタンスの再起動
- 実行するコマンド: EC2インスタンスを再起動するコマンドとインスタンスID
  例) aws ec2 reboot-instances --instance-ids i-aabbccddeeff
  インスタンスIDは、AWS管理コンソール等で確認します。
- 認証情報: 直接入力
- AWSリージョン: EC2インスタンスが登録されているAWSリージョン
  例) アジアパシフィック(東京)
- Access Key ID: インスタンス再起動のロールを持つユーザーのAccess Key ID
  AWS管理コンソールのIAMで、ユーザーの作成/ロールの割当/Access Key IDの生成・確認ができます。
- Secret Access Key: Access Key IDに対応するSecret Access Key
  Access Key ID生成時に取得したSecret Access Keyを設定します。Secret Access Keyを後から確認することは出来ないので、分からない場合は新しくAccess Key IDを生成する必要があります。

このルールが適用されたら、設定されたAWS CLIコマンドを実行します。複数登録されている場合は、上から順に実行されます。実行結果は、起票されたインスタンスの対応履歴に記録されます。

Gcloud CLI
- コマンド名: 実行するコマンドを区別するための名称
  例) インスタンスの再起動
- 実行するコマンド: GCEインスタンスを再起動するコマンドとインスタンス名
  例) gcloud compute instances reset your-instance-name --zone us-central1-a
  インスタンス名は、GCP Compute Engine管理コンソール等で確認します。
- 認証情報: 直接入力
- Service Account Key: インスタンス再起動の権限を持つユーザーのService Account Key
  GCP IAM管理コンソールで、ユーザーの作成/権限の割当/Service Account Keyの生成・確認ができます。

このルールが適用されたら、設定されたGcloud CLIコマンドを実行します。複数登録されている場合は、上から順に実行されます。実行結果は、起票されたインスタンスの対応履歴に記録されます。

アクション設定

自動コール
- 呼び出し秒数: 20秒
- リトライ回数: 2
- 連絡先1: ユーザー01の電話番号

このルールが適用されたら、アラートを受信してから10分後に連絡先1のユーザー01の電話番号に電話を発信します。20秒間呼び出しを行い、応答があった場合は、結果[OK]でアクションを終了します。応答がなかった場合は、リトライ回数2回まで再度連絡先1に発信します。すべての発信で応答がなかった場合は、結果[NG]でアクションを終了します。電話を発信する前にキャンセル条件にマッチするアラートを受信した場合は、電話の発信はキャンセルされます。

インシデント設定

条件にマッチした場合に作成するインシデントの設定
- ステータス: 完了
- 担当者: ユーザー01
その他の項目は任意で設定します。

3. アラート受信時の動き

上記のルールをプロジェクトに登録した状態で、監視対象サービスでアラートが発生すると、以下の流れでアラートの自動対応が行われます。

3-1. 件名にERRORを含むアラートを受信した後、10分以内に件名にOKを含むアラートを受信した場合

監視対象サービスから、プロジェクトのメールアドレスへ向けて、件名にERRORを含むアラートを送信する
OpsAidでプロジェクトがアラートを受信する
プロジェクトに登録されたルールに、アラートがマッチするかチェックする。アラートの件名にERRORが含まれているので、作成したルールの検知条件にマッチする
ルールの検知条件にマッチしたので、自動でインシデントが起票される
検知時に実行する処理に登録されたAWS CLIコマンドが実行され、その後10分間の待ち状態となる
検知時に実行する処理の結果が起票されたインシデントに記録される
監視対象サービスから、プロジェクトのメールアドレスへ向けて、件名にOKを含むアラートを送信する
プロジェクトに登録されたルールに、アラートがマッチするかチェックする。アラートの件名にOKが含まれているので、作成したルールのキャンセル条件にマッチする
アクションの実行がキャンセルされ、インシデントのステータスが対応不要となる

3-2. 件名にERRORを含むアラートを受信した後、10分以内に件名にOKを含むアラートを受信しなかった場合

監視対象サービスから、プロジェクトのメールアドレスへ向けて、件名にERRORを含むアラートを送信する
OpsAidでプロジェクトがアラートを受信する
プロジェクトに登録されたルールに、アラートがマッチするかチェックする。アラートの件名にERRORが含まれているので、作成したルールの検知条件にマッチする
ルールの検知条件にマッチしたので、自動でインシデントが起票される
検知時に実行する処理に登録されたAWS CLIコマンドが実行され、その後10分間の待ち状態となる
検知時に実行する処理の結果が起票されたインシデントに記録される
件名にOKが含まれるアラートを10分以内に受信しなかったので、アクションの実行が開始され、ユーザー01への電話発信が行われる
アクションの結果を受けて、ルールの実行結果が起票したインシデントに記録される
問題なく終了したら、インシデントのステータスが完了となる

以上で、OpsAidの自動対応が終了します。

以上の設定を行うことで、アラートを受け取ったら自動で復旧処理を行い、復旧できなかった場合に担当者に連絡したいケースの実現が可能です。

最後に

OpsAidの活用事例の紹介と設定例については以上となります。
ここまでご紹介した条件指定やアクション指定を組み合わせて、OpsAidは様々なケースに対する自動対応を行うことが可能です。ぜひ、OpsAidを活用してシステム管理の負担軽減にお役立てください。