Dynatrace SaaSの新機能「Workflows」はご存知でしょうか。Workflowsとは、Dynatraceで取得した情報をもとにタスク自動化を行う機能です。業務多忙な皆様を助ける強力な自動化ツールなのですが、その多機能さゆえ、どのように活用していけば良いか分からない方も多いかと思います。
本記事では、Workflowsの具体的な検討事例を解説します。本事例紹介がWorkflow利用の後押しとなり、皆様の業務効率化の一助となればと思っています。
なお、これ以降、機能の総称を「Workflows」と複数形で表記し、事例ごとに作成した単体の設定を「Workflow」と単数形で表記させていただきます。また、各事例で作成したWorkflowの詳細設定まで掲載すると記事が長くなってしまうため、本記事では各事例のご紹介までとさせていただいております。ご興味のある事例がございましたら、ぜひ詳細情報をご案内させていただきたく、お問い合わせいただけますと幸いです。
本テーマは、2本の記事で構成しております。
1. Workflowsの概要
2. Workflows検討事例
2-1. 稼働レポートの定期的なメール通知
2-2. CPU使用率高騰をトリガーとしたOS再起動
2-3. トレースIDが同じエラーログの通知
2-4. ディスク使用率の将来予測値に対する閾値設定
3. まとめ
1本目の本記事では、Workflowsの概要と具体的な検討事例として、2-1,2-2をご紹介します。
2本目、次の記事にて、残り2点の検討事例をご紹介させていただきます。
Workflowsは、Problemやスケジュールなどをトリガーにしてタスクを自動実行する機能です。タスクとは、Workflows内で実行される個々の処理や操作のことで、Dynatraceのクエリ言語「DQL」をはじめ、外部APIコールできるHTTPリクエスト、JavaScriptなどで自由に設定することができます。また、タスク間の並列実行や分岐処理、パラメータのやり取りなどの指定も可能となっています。
さらに、タスクの中の細かい操作は「アクション」と呼ばれています。Workflowsでは、Dynatrace Hubに公開されているアクションを追加することで、様々なツールとの外部連携も実現できます。ご参考までに、2024年11月現在に設定可能なトリガーの一覧とアクションの一部を掲載します。なお、最新情報はDynatrace社のドキュメントやDynatrace Hubをご参照ください。
No. |
分類 |
トリガー名 |
説明 |
1 |
イベント |
Problem |
Dynatrace(Davis)がProblemを検知したとき |
2 |
イベント |
Davisイベント |
Dynatrace(Davis)がイベントを検知したとき |
3 |
イベント |
イベント |
DQLクエリで設定された条件に合致したとき |
4 |
スケジュール |
固定スケジュール |
特定の日時 |
5 |
スケジュール |
定期間隔 |
毎日、毎月などの定期的な時間 |
6 |
スケジュール |
Cron設定 |
定期間隔をCron形式で設定 |
7 |
オンデマンド |
手動実行 |
Workflows画面で「Run」をクリックするかAPIでのみ起動 |
表1:Dynatrace Workflowsで設定可能なトリガーの一覧
No. |
分類 |
アクション名 |
説明 |
1 |
プリセット |
DQLクエリ |
DQLクエリの実行 |
2 |
プリセット |
HTTPリクエスト |
HTTPリクエストの発行 |
3 |
プリセット |
JavaScript |
JavaScriptの実行 |
4 |
Dynatrace Hub |
Email for Workflows |
メール通知 |
5 |
Dynatrace Hub |
Jira for Workflows |
Jiraの起票 |
6 |
Dynatrace Hub |
Red Hat Ansible for Workflows |
AnsibleのPlaybookの実行 |
7 |
Dynatrace Hub |
Davis for Workflows |
Dynatrace社の提供する問題分析AIや将来予測による分析 |
表2:Dynatrace Workflowsで設定可能なアクション例
※アクションは他にもDynatrace Hubに数多く公開されております。
Containsのプルダウンから「Actions」を選択して検索してみてください。
ここからは具体的な検討事例を4件ご紹介していきます。本記事では前半2点をご紹介し、次の記事で後半2点をご紹介します。
1. 稼働レポートの定期的なメール通知
2. CPU使用率高騰をトリガーとしたOS再起動
3. トレースIDが同じエラーログの紐づけ
4. ディスク使用率の将来予測値に対する閾値設定
このWorkflowにより、図2のようにホスト別のCPUやメモリの使用率をメールで通知することができました。
続いての事例は、弊社としても大きな目標と掲げている「NoOps」(No Operations)への取り組みとなります。IT運用の現場では、システムの安定性を維持するために、昼夜問わず対応を求められることがあります。運用担当者が夜間にアラートで起こされるという話も耳にします。そんな運用業務をできる限り自動化し、運用担当者の負担を少しでも軽減できないかというアプローチとなります。
想定としては、CPU使用率が高騰した際に処理を受け付けなくなり、OS再起動により解消するサーバーがあることを仮定しています。また、WorkflowsではOS再起動のコマンドを発行することはできないため、司令塔サーバーを別途構築し、Dynatraceからのリクエストにより対象サーバーを再起動するスクリプトを準備しておきます。なお、弊社では図3のように簡易的なスクリプトで実装しましたが、Ansibleなどの自動化ツールとも組み合わせることが可能です。
以下が弊社で作成したWorkflowの設定となります。
上記設定により、CPU使用率高騰のProblem発報後、わずか5分でProblemがクローズしました。
また、WorkflowによりOS再起動が実行された旨をProblemのコメントやMicrosoft Teamsへ通知することができました。
このように、Workflowsを活用することで、CPU使用率高騰の検知から解消まで人手を介することなく、迅速な解決が可能となります。もちろん、実務を担当されている方からの懸念も認識しており、本当にOS再起動で解消する事象なのか、人手で行われている確認も自動化していく必要があると考えています。実際の運用までの障壁はありますが、「NoOps」の未来に向けた最初の一歩として、こうした検討事例があることをご認識いただけますと幸いです。
本事例でご紹介したWorkflowの詳細な設定方法は、弊社サポートページに公開されている「Workflows利用方法」にも掲載されております。サポートページの閲覧にはユーザーIDとパスワードが必要です。ご不明な方は担当営業までお問合せください。
次回の記事では、「トレースIDが同じエラーログの紐づけ」や「ディスク使用率の将来予測値に対する閾値設定」をWorkflowsで実現した事例をご紹介させていただきます。