2024.12.12

#25 Dynatrace Workflowsの検討事例紹介その2

Dynatrace

Workflows

本テーマの構成

本テーマは、2本の記事で構成しております。

[目次] ――――――――――――――――――――――――

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

――――――――――――――――――――――――

 1本目の記事では、Workflowsの概要と検討事例を2つご紹介させていただきました。
本記事では、残り2点の検討事例をご紹介させていただきます。（下記目次の2-3、2-4に該当します。）

2．Workflows検討事例

2-3. トレースIDが同じエラーログの通知

こちらの事例は、アラートストーム改善のために同じ処理に関するエラーをまとめて通知したいというお客様からのご要望への対応事例です。お客様はシステムから出力されるエラーを1件1件丁寧に確認されているのですが、確認すると同じ処理に関するエラーだったということが度々あるということでした。

また、処理の紐づけ方法としてDynatraceのトレースIDを利用するアイディアをいただきました。Dynatraceのログ取り込みでは、ログのエンリッチメントを設定すると、トレースとログの紐づけを行うことが可能となります（詳細はDynaTipsをご参照ください）。このとき、ログとトレースの紐づけはトレースIDで管理されます。同一トレースのログは、同じトレースIDが付与されます。

例として、図1はDynatrace社のデモ環境で、トレースと紐づけされているログかつ、エラーレベルのログをフィルターしたものとなります。赤く囲っている2行のログはtrace_idが同じです。

図1：Dynatrace社デモ環境のLogsの画面

それぞれのログから紐づけされたDistributed tracesに遷移してみます。1つ目のログは「/cart/checkout」というアプリケーションから、2つ目のログは「Charge」というアプリケーションから出力されたエラーであることがわかりました。しかし、2つのアプリケーションは同じDistributed tracesから呼び出されておりますので、同じ処理から発生しているエラーであることがわかります。

図2：trace_idが同じログの1つ目からDistributed tracesに遷移した画面

図3：trace_idが同じログの2つ目からDistributed tracesに遷移した画面

この2つのエラーログを同じ事象として紐づけることができたなら、エラーログの確認の手間が半分で済みます。Dynatraceの標準機能では、トレースIDごとのアラート通知はできませんが、Workflowsであれば可能です。

図４が弊社で作成したWorkflowの設定となります。Problemをトリガーとして、該当時間帯に出力されたエラーログのトレースIDを検索し、トレースIDの数だけアラート通知をループさせる設定となります。

図4：トレースIDが同じIDのエラーログの通知を行うWorkflow

弊社の検証は簡易的にし、トレースとログの紐づけまでは実施せず、ログを出力するプロセスIDの数だけアラートを通知できるかを検証しました。結果は、図5のように同じプロセスIDのエラーを紐づけてアラートを通知させることができました。

図5：Workflowの通知結果

同様に、同じトレースIDを持つエラーログを紐づけて通知することで、同じ処理のエラーなのか特定が容易となり、問題の迅速な特定と対処が可能となります。皆様の中で、アラート通知について課題を抱えていたり、通知後に度々同じ対応を繰り返していて自動化できないか検討されていましたら、ぜひ弊社にお声がけください。

本事例の詳細な設定方法を知りたい方はぜひ、担当営業または担当SEにご連絡ください。

2-4. ディスク使用率の将来予測値に対する閾値設定

最後の事例は、将来予測値に対する閾値設定となります。Dynatraceでは、「Davis forecast analysis」という予測分析機能が提供されており、Dynatraceで取得したメトリックやDQLクエリの結果をもとに将来予測値を出力することが可能となっております。将来予測値を知ることで、事前のリソース割り当てやスケールアウトなど、プロアクティブな対処や障害の未然防止といった効果が期待されています。

一方で、大規模な環境で多様なデータを取得している場合には、すべてのデータの将来予測値を確認することが困難なため、閾値を設けてチェックしたいと考える方もいるかと思います。2024年11月現在、閾値チェック機能で将来予測値は設定項目対象外となっていますが、WorkflowsでJavaScriptを使用することで将来予測値に対する閾値チェックを行えます。　

JavaScriptのサンプルはDynatrace社公式のブログやドキュメントで公開されております。下記では、弊社のDynatraceテナントでサンプルJavaScriptを使用してみた結果を記載させていただきます。

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

図6：ディスク使用率の将来予測値に対する閾値チェックを行うWorkflow

上記設定により、ディスク空き率の将来予測値が15%を下回るディスクについてProblemが出力されました。

図7：Workflow実行の結果、出力されたProblem

Problemが出力されたディスクの空き率についてNotebookで予測分析してみると、確かにディスク空き率が減少傾向にあるようでした。

図8：Problemが出力されたディスクの空き率の予測分析結果

弊社のDynatraceテナントでデータ取得しているディスクは、一時的なものも含めると690個ほどあるため、すべてのデータの将来予測値を確認することは困難です。閾値チェックにより、対処が必要なディスクを効率的にピックアップすることができました。

図9：弊社でデータ取得している全ディスクの空き率の予測分析結果

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

このように、Dynatrace社提供のJavaScriptをコピーするだけで簡単に将来予測値の閾値チェックを実現することができました。多くの対象サーバーやディスクのデータを取得されている場合には、チェックが必要なディスクをすぐに特定することができ、大変便利です。もし皆様の環境で、多くの対象サーバーやディスクのデータを取得されている場合には、気軽な気持ちでお試しいただくのはいかがでしょうか。

本事例でご紹介したWorkflowの詳細な設定方法は、Dynatrace社公式のブログやドキュメントをご参照ください。

まとめ

いかがでしたでしょうか。Workflowsを活用することで、運用の自動化と効率化が実現できます。本記事を参考に、ぜひWorkflowsの設定に挑戦してみてください。また、弊社としても検討のお手伝いさせていただきたく、自動化したい業務がございましたらぜひご連絡ください。

執筆者

N.T.　

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

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

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

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