概要
今回は皆さん大好き承認機能付きのProcess Workflowを作成したので、そちらをご紹介します。
まずWorkflowの説明をします。
1, Windows Agentからサービスを監視し、Downを検知
2, サービスの再起動スクリプトの実行承認を依頼する
3, 承認された場合Workflowでサービス再起動が自動で実施される
4, 自動対応内容がアラート/チケットにコメントされる
皆さんの環境でこのWorkflowを再現したい場合、以下の説明から作成もできますが、
後日、APIPOSTでサクッと作成出来る方法を投稿しますので、そちらのほうが簡単かもしれません。
各タスクの説明
画像の各タスクをWorkflowの流れと一緒に順に説明します。
※原則記載の無い設定項目はデフォルト値です。
startevent(アラート発生)
アラートのcomponentのフィールドの文字列が”Print Spooler”であった場合、
このWorkflowを開始する。
| 項目 | 値 |
|---|---|
| Name | ServiceAlert |
| ID | 自動入力 |
| Configuration | Alert |
| Configuration2 | Created |
| Filter Criteria | $component = "Print Spooler" |
User Task(承認申請)
タスクチケットを作成します。
言い換えますと、承認申請がタスクという種類のチケットで作成されます。
| 項目 | 値 |
|---|---|
| Name | ObtainApproval |
| ID | 自動入力 |
| Subject | サービス再起動承認依頼 |
| Description | 下記サービスが停止中です、再起動のためワークフローの承認をお願いします。$ServiceAlert.alert.resource.hostName, $ServiceAlert.alert.component
|
| Priority | high |
| Assignee | 任意(承認者にするのがいいと思います。) |
※ここにない項目はデフォルトで構いません。
(Taskチケット)
予めCustom Formで承認対応用のフィールドを用意しておきましょう。
(Custom Formの詳細はこれだけでとても長くなるため省略します。)
Setup＞Service Desk＞Custom Forms＞Task
| 項目 | 値 |
|---|---|
| Formの種類 | Drop-down list |
| Display Label | Actions |
| Is editable? | 有効 |
| Dropdown Options 1 | Deny(※横のボックスも同じ内容を入力) |
| Dropdown Options 2 | Approve(※横のボックスも同じ内容を入力) |
(承認作業)
承認者が内容を確認し、承認します。
要件
「承認する = Workflowを先にすすめる」という事になるのですが、
その条件として、この作成されたTaskチケットのステータスを「Resolved」にする必要があります。
これはOpsRampのドキュメントに書いていないので要注意です。(2021/12/03現在)
合わせて、事前に作成した「Action」のフィールドは「Approved」を選択しましょう。
Exclusive Gateway(承認された場合のみ次のタスクを実行する)
Taskチケットを更新したことにより、先に進むことが出来るようになりました。
次に待ち構えているのは条件分岐です。
下記の設定で、Taskチケットの「Action」のフィールドは「Approved」の時だけ
関所を通す設定を入れていきます。
これ勘違いしやすいのですが、分岐のFunctionであるExclusive Gatewayには
分岐の条件を入れる項目はありません。分岐の条件を入れるのはそこから伸びている
棒線矢印の中に入れていきます。
1, Exclusive Gateway
| 項目 | 値 |
|---|---|
| Name | Get Responce |
| ID | 自動入力 |
2, Global Connect その1(矢印の棒線)
| 項目 | 値 |
|---|---|
| Name | Deny |
| ID | 自動入力 |
3, Global Connect その2(矢印の棒線)
| 項目 | 値 |
|---|---|
| Name | Approve |
| ID | 自動入力 |
| Condition | $ObtainApproval.task.Actions = "Approve" |
Script Task(プロセスを再起動する)
承認が通っているため、Downしたプロセスをスクリプトで起動させます。
これによって対象のアラートは復旧します。
今回はOpsRamp上で用意したスクリプトを動かします。
| 項目 | 値 |
|---|---|
| Name | RestartService |
| ID | 自動入力 |
| Configuration | Agent |
| Script Category | 任意 |
| Script Name | 任意 |
| Resource Id | $ServiceAlert.alert.resource.uuid |
| Imputs-Service Name | $ServiceAlert.alert.component |
※このスクリプトはOpsRamp内で作成し、スクリプトのImputのパラメータを
仕込んであります。ですので、通常はパラメータなければImput入力項目は
出てきません。
Service Task(アラート/インシデントチケットに自動対応実施のログを残す)
最後にスクリプトを実行したということをアラートとインシデントにコメントして残します。
このService TaskはOpsRampUIから取れるアクションの一部を自動で実施してくれます。
ドロップダウンから選択するだけなので、スクリプト等がなくても簡単に実行できるので楽ちんです。
1, アラート
| 項目 | 値 |
|---|---|
| Name | AddAlertComment |
| ID | 自動入力 |
| Service | Platform Service |
| Task | Post Alert Comment |
| AlertID | $ServiceAlert.alert.uuid |
| Comments | 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName |
2, インシデント
| 項目 | 値 |
|---|---|
| Name | UpdateIncident |
| ID | 自動入力 |
| Service | Platform Service |
| Task | Update Incident |
| Response | 自動化ワークフローによりサービスの再起動を実施しました。承認者: $ObtainApproval.task.assignedTo.loginName |
それぞれこの様にポストされました。
アラート
インシデントチケット
以上です。