Workflow

この演習では、RBAで少し複雑なJobを作成する方法を学びます。

RBA Jobのインポート#

以下のJob定義ファイルをアップロードして、新たに2つJobを作成します。

参考: RBA Job定義ファイルのインポート

RBA Jobの編集#

環境に合わせてJobの設定を一部修正します。

  1. R1_AutoRemediation の編集画面を開き、Workflowタブをクリックします。Optionsの pd_user をクリックします。 Image

  2. Default Value欄のメールアドレスを、PagerDutyユーザーのメールアドレスに書き換えます。
    PagerDutyの操作をするJob Stepでは、ここで指定したユーザーで操作を行います。 Image

  3. R2_Escalate_Incidents についても同様に編集画面を開き、pd_user を編集してください。

  4. R2_Escalate_Incidents では、Job Stepも一部修正が必要です。Workfowの1つ目のJob Stepをクリックし、開いてください。 Image

  5. このJob Stepでは、PagerDuty REST APIにHTTPリクエストを送り、インシデントのUrgencyとPriorityを変更します。PriorityはIDで指定しますが、IDは環境によって異なるので自身の環境に合わせて修正が必要です。 Image

  6. PagerDuty REST APIを利用して、Priority IDを確認します。
    APIリファレンス: List prioritiesをブラウザで開き、Test API Token欄にPagerDutyのAPI Tokenの値を入力します。 Image

参考: PagerDuty REST API Tokenの発行

  1. 画面右側の Send API Request ボタンをクリックし、Responseを確認します。SummaryにP2の記載のあるブロックの id の値をコピーします。以下の例ではPXNGTUVの部分です。 Image

  2. RBAのJob Stepに戻り、Your Priority IDの箇所をコピーしたidの値に置き換えてください。 Image

  3. Job StepをSaveし、再度Saveをクリックして、Job編集画面を閉じてください。

Jobの実行#

Job:R1_AutoRemediationの動作を試すために、まずインシデントを起票します。

  1. PagerDuty Event APIv2のリファレンスページをブラウザで開きます。

  2. 画面右のBody編集画面内で、インシデントを起票するServiceのIntegration Keyの値を入力します。 また今回は Urgency:Low で起票するために、severityの値をinfoに書き換えます。
    routing_keyとseverityを変更したら、Send API Requestボタンをクリックしてください。 Image

  3. PagerDutyにログインし、Operations Console(AIOps > Operations Console)または Incidents > All Incidents から、起票されたインシデントのタイトルをクリックします。

  4. Dynamic Notificationが正しく設定されていれば、以下のように Urgency:Low でインシデントが起票されるはずです。
    以降のシナリオでUrgencyやPriorityを変更するJobを試しますが、UrgencyやPriorityはインシデント詳細画面から手動で変更することも可能です。Jobの動作を確認する際に、必要に応じて変更するようにしてください。 Image

  5. Jobの実行には、Incident IDが必要になります。Incident IDは、インシデント詳細画面のURLから確認することができます。 Image

シナリオ1: 自動診断 失敗#

最初は自動診断が失敗したケースで、どのような実行結果になるか試します。

  1. RBAにログインし、Job:R1_AutoRemediationの実行画面を開いてください。
    Incident IDの値を入力し、Auto Diag Result欄の値をデフォルトのSUCCESS以外の値に変更した後、Run Job Nowをクリックします。 Image

  2. 自動復旧は実行されませんが、正常な動作です。 Image

トラブルシューティング

Jobの実行結果が Succeeded ではなく Faild になった場合は、Job Stepのどこかで失敗しています。 Logを確認し、トラブルシュートを行ってください。

  1. PagerDutyでインシデント詳細画面を開き、Timelineでどのような操作が行われたのか確認します。
    最初はUrgency: Lowで起票され、その後UrgencyがHighに、PriorityはP2に変更され、自動診断が失敗した旨がNoteに追記されています。 Image

シナリオ2: 自動修復 失敗#

次は自動診断は成功、自動修復に失敗するケースを試してみます。

PagerDutyで、既存のインシデントをResolvedに変更後、新たにインシデントを起票してください。
(または、既存のインシデントのUrgencyをLow, PriorityをP2以外に変更してください。)

  1. RBAにログインし、Job:R1_AutoRemediationの実行画面を開いてください。
    Incident IDの値を入力し、Auto Remediation Result欄の値をデフォルトのSUCCESS以外の値に変更した後、Run Job Nowをクリックします。 Image

  2. PagerDutyでインシデント詳細画面を開き、Timelineでどのような操作が行われたのか確認します。
    自動診断の実行後、UrgencyがHighに、PriorityはP2に変更され、自動復旧が失敗した旨がNoteに追記されています。 Image

シナリオ3: 自動診断&修復 成功#

最後は、自動診断・自動修復ともに成功するケースを試します。

  1. RBAにログインし、Job:R1_AutoRemediationの実行画面を開いてください。
    Incident IDの値を入力し、Auto Diag ResultとAuto Remediation Result欄の値をデフォルトのSUCCESSに戻し、Run Job Nowをクリックします。 Image

  2. PagerDutyでインシデント詳細画面を開き、Timelineでどのような操作が行われたのか確認します。
    自動診断と自動修復の実行後、問題が解決した旨のNoteが追記され、インシデントのステータスがResolvedに変更されています。 Image

以降は、Job R1とR2の設定の解説になります。
設定と解説を確認しながら、自由に設定を変更して動作を確認し、理解を深めてください。

Ruleset#

Worlflow StrategyでRulesetを選択すると、Job Stepの実行順序や要否を細かく設定することができます。

参考: Ruleset Workflow Strategy Plugin

R1の以下の例では、1-7行目で実行順序を指定し、9-12行目でJob Stepを実行する条件を指定しています。 Image 

[1,2] run-at-start
[3] run-after:1,2
[4] run-after:3
[5,6] run-after:4
[7] run-after:5
[8] run-after:7
[9] run-after:8

[4] if:export.result_d!=SUCCESS
[5-7] if:export.result_d==SUCCESS
[8] if:export.result_d==SUCCESS if:export.result_r!=SUCCESS
[9] if:export.result_r==SUCCESS

また、以下のように実行順序と条件を同じ行に指定することも可能です。 

[1,2] run-at-start
[3] run-after:1,2
[4] run-after:3　if:export.result_d!=SUCCESS

Log Filter#

Log Filterを利用すると、Jobの実行結果を変数(Variables)に保存し、後続のJobで利用することができます。

参考: Log Filters, Pass Data Between Steps

R1のStep1では、実行結果の出力全体をdata.disk_usageという変数に保存しています。
変数に保存する値の指定には、Javaの正規表現を利用します。正規表現の動作確認には、こちらのサイトが便利です。

Image

Image

Step6では、data.disk_usageを利用して、取得した値をIncident Noteに書き出す処理を行っています。 Image

Variablesの種類とスコープ#

Variables(変数)にはタイプがあり、利用できる場面(スコープ)が異なります。

参考: Context Variables

R1のStep2はNode Stepのため、Log Filterで作成したdata.result_diagはNode Scopeになります。

Image

このままではRulesetやWorkflow Stepでは利用できないため、Step3では新たにGlobal Scopeの変数result_dを作成し、Node Scopeの変数result_diagから値を渡しています。

Image

Image

Step3で作成したGlobal Scopeの変数は、以下のような形で利用することができます。

Options#

JobのWorkflowタブでは、Optionsを設定することができます。
各Optionは変数として利用でき、Jobの実行時に値を指定することができます。

参考: Job Options

Image

例えばインシデントIDはインシデント毎に値が異なるため、Optionとして設定しておき、実行時にArgumentとして値を指定することで、どのインシデントに対してもJobが実行できるようにしています。

Image

Job Reference Step#

Job reference stepを利用すると、他のJobを呼び出して実行することができます。

参考: Builtin Node Steps

Job reference stepのArguments(引数)では、実行するJobのOptionの値を指定することができます。

R1のStep4では、Notesに追記したいテキストを pd_comment として指定しています。
また、Import Options?にチェックを入れ、このJobで設定されているOptionsの値を、呼び出されるJobでも利用できるようにしています。 Image

外部APIを扱う方法#

R2のStep1では、HTTP Request Node Stepを利用して、PagerDuty REST API: Update an incident にHTTPリクエストをPUTしています。

参考: Builtin Node Steps

Image

Pluginが用意されていない操作については、このようにHTTP Node StepやScript等を使ってAPI経由で行うことができます。

AWSで利用できるPlugin等

AWSには様々なPluginが用意されていますが、Pluginがないものについては、HTTP Request Node Stepの他、Command stepやScript stepを使って、AWS CLIやBoto3を利用します。
また、AWS CLIやBoto3をAWS Lambda Workflow Stepを利用して実行することもできます。

以上でJob Workflowの演習は完了です。お疲れ様でした！