2024.12.12

#24 Dynatrace Workflowsの検討事例紹介その1

Dynatrace

Workflows

はじめに

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点の検討事例をご紹介させていただきます。

1．Workflowsの概要

Workflowsは、Problemやスケジュールなどをトリガーにしてタスクを自動実行する機能です。タスクとは、Workflows内で実行される個々の処理や操作のことで、Dynatraceのクエリ言語「DQL」をはじめ、外部APIコールできるHTTPリクエスト、JavaScriptなどで自由に設定することができます。また、タスク間の並列実行や分岐処理、パラメータのやり取りなどの指定も可能となっています。

さらに、タスクの中の細かい操作は「アクション」と呼ばれています。Workflowsでは、Dynatrace Hubに公開されているアクションを追加することで、様々なツールとの外部連携も実現できます。ご参考までに、2024年11月現在に設定可能なトリガーの一覧とアクションの一部を掲載します。なお、最新情報はDynatrace社のドキュメントやDynatrace Hubをご参照ください。

表1：Dynatrace Workflowsで設定可能なトリガーの一覧

表2：Dynatrace Workflowsで設定可能なアクション例

※アクションは他にもDynatrace Hubに数多く公開されております。

Containsのプルダウンから「Actions」を選択して検索してみてください。

2．Workflows検討事例

ここからは具体的な検討事例を4件ご紹介していきます。本記事では前半2点をご紹介し、次の記事で後半2点をご紹介します。

1.    稼働レポートの定期的なメール通知
2.    CPU使用率高騰をトリガーとしたOS再起動
3.    トレースIDが同じエラーログの紐づけ
4.    ディスク使用率の将来予測値に対する閾値設定

2-1.稼働レポートの定期的なメール通知

まずは、あるお客様からのご要望で、定期的な稼働レポートのメール通知に取り組んだ事例です。もともと、各サーバーのご担当者様が定期的に複数のメトリックを取得して手計算で稼働レポートを作成されており、これを自動化したいというご要望でした。さらに、レポートをメールで送付することにより、普段はDynatraceにログインしないメンバーにも情報を共有することができます。メールであればスマートフォンやタブレットから外出先や移動中でも確認できるため、より効率的にシステムの状況を把握することができるのではないかと考えました。

今回は、稼働レポートのサンプルとして、ホスト別のCPUやメモリの使用率をメール通知するWorkflowを作成しました。メール通知したい情報はシステムにより異なるかと思いますが、情報の取捨選択はDQLにより調整可能です。作成したWorkflowの設定は図1の通りです。

図1：定期的な稼働レポートのメール通知を行うWorkflow

このWorkflowにより、図2のようにホスト別のCPUやメモリの使用率をメールで通知することができました。

図2：Workflowにより通知されたメール本文

2-2. CPU使用率高騰をトリガーとしたOS再起動

続いての事例は、弊社としても大きな目標と掲げている「NoOps」（No Operations）への取り組みとなります。IT運用の現場では、システムの安定性を維持するために、昼夜問わず対応を求められることがあります。運用担当者が夜間にアラートで起こされるという話も耳にします。そんな運用業務をできる限り自動化し、運用担当者の負担を少しでも軽減できないかというアプローチとなります。
 
想定としては、CPU使用率が高騰した際に処理を受け付けなくなり、OS再起動により解消するサーバーがあることを仮定しています。また、WorkflowsではOS再起動のコマンドを発行することはできないため、司令塔サーバーを別途構築し、Dynatraceからのリクエストにより対象サーバーを再起動するスクリプトを準備しておきます。なお、弊社では図3のように簡易的なスクリプトで実装しましたが、Ansibleなどの自動化ツールとも組み合わせることが可能です。

図3：CPU使用率高騰をトリガーとしたOS再起動の仕組みの構成図

以下が弊社で作成したWorkflowの設定となります。

図4：CPU使用率高騰をトリガーとしたOS再起動を行うWorkflow

上記設定により、CPU使用率高騰のProblem発報後、わずか5分でProblemがクローズしました。

図5：Workflow実行の結果、クローズしたProblem

また、WorkflowによりOS再起動が実行された旨をProblemのコメントやMicrosoft Teamsへ通知することができました。

図6：WorkflowによるProblemへのコメント

図7：WorkflowによるMicrosoft Teamsへの通知

このように、Workflowsを活用することで、CPU使用率高騰の検知から解消まで人手を介することなく、迅速な解決が可能となります。もちろん、実務を担当されている方からの懸念も認識しており、本当にOS再起動で解消する事象なのか、人手で行われている確認も自動化していく必要があると考えています。実際の運用までの障壁はありますが、「NoOps」の未来に向けた最初の一歩として、こうした検討事例があることをご認識いただけますと幸いです。

本事例でご紹介したWorkflowの詳細な設定方法は、弊社サポートページに公開されている「Workflows利用方法」にも掲載されております。サポートページの閲覧にはユーザーIDとパスワードが必要です。ご不明な方は担当営業までお問合せください。

 次回の記事では、「トレースIDが同じエラーログの紐づけ」や「ディスク使用率の将来予測値に対する閾値設定」をWorkflowsで実現した事例をご紹介させていただきます。

執筆者

N.T.　

営業技術本部 技術サービス統括部 技術サービス１部　

お客様担当SEとして、製品の構築から活用方法までの一連のサポートを担当
また、お客様環境にて性能問題が発生した際には、製品のアウトプットを利用し、問題解決に向けた調査／提案業務を実施

■経歴
2013年　入社
2014年　品質管理部隊へ配属、10月からお客さまサポート部隊へ異動

主にシステムリソース情報からの性能管理サポートに従事し、近年は、上記に加えAPM製品を利用したユーザー体感レスポンスやアプリケーション視点での性能管理サポートにも従事。現在に至る