2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Dynatraceで障害の自動分析を検証してみた

Last updated at Posted at 2023-07-14

背景

Dynatraceでは監視対象ホストにOneAgentと呼ばれるエージェントソフトをインストールするだけで監視を始めることができ、障害が発生した場合はAIによる自動分析で問題の根本原因をピンポイントで特定します。

監視対象システムで問題を検知したらエンジニアによる問題解析(影響範囲、原因特定など)を行う必要があります。

既知の問題の場合は時間はあまりかかりませんが、未知の問題の場合はしばしば多くの時間を要することがあります。

そこで今回は簡易的なシステムを作成したうえで意図的に障害を発生させてDynatraceの自動分析を検証したいと思います。

検証環境概要

画像1.png

今回はタスク管理システムとWebサイトを構築しました。

タスク管理システム
Javaで開発したCRUDアプリケーション。AWS上のEC2にLB、APサーバ、オンプレESXiにDBサーバ(MySQL)が存在します。 管理者はタスクを登録、削除、更新、読み出しができます。
タスク読み出しAPIを実装しています。
Webサイト
Webサイトにアクセスがあるとタスク管理システムに対してAPI Requestを実行し、取得したタスク一覧をWebサイトに表示します。EC2とSpring Bootを用いて作成しています。

処理の流れは以下の通りです。
① ユーザがWebサイトにアクセス
②アクセスをトリガーとしてタスク管理システムに対してAPI Requests
③ LB経由でタスク管理システムのAPサーバにアクセス
④ APサーバからDBサーバにアクセス
⑤ APサーバからWebサイトに対してAPI Responseを送信
⑥ 返却されたレスポンスをもとにWebサイトを表示

今回の検証ではWebサイトが表示されるまでの時間を長くして意図的に障害を発生させたいと思います。
そのため、アプリケーション内のコードに意図的に600ms待機するコードを追加します。

public class Api extends HttpServlet {
	  public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException
	  {
    		try {
    			Thread.sleep(600);	//ここで600ms待機
    		} catch(InterruptedException e) {
			
    		}
		~~~省略~~~

Dynatraceでは監視対象ホストにOneAgentをインストールするだけで監視を行うことができます。
今回は監視対象ホスト4台すべてにOneAgent導入済みです。

問題検出

応答時間劣化を検出させるため、ローカル端末から4秒間隔でWebサイトにアクセスするスクリプトを実行しています。

画像2.png

上図は、WebサイトのApache Tomcatサービスのコンソール画面になります。
棒グラフはリクエスト数、折れ線グラフは応答時間の中央値を表しており、10:16ごろから応答時間が急激に増加していることがわかります。
この時間にタスク管理システムのTomcatに600ms待機するコードを埋め込んだアプリケーションをデプロイしました。

画像4.png

遅延発生の約5分後にDynatraceでプロブレムとして検出されました。
また、プロブレム検出から数分後には根本原因が特定されました。

根本原因分析

ではDynatraceの分析結果をみてみましょう。

画像5.png

上図は先ほどのプロブレムの詳細画面となっており、ここではビジネスインパクト分析結果や、影響を受けたサービスなどを確認できます。

また、根本原因の欄を確認するとtodoappというTomcatサービスが原因だと提示しています。
こちらは実際に600msの待機を埋め込んだアプリをデプロイしたTomcatです。
当該Tomcatはプロセスリスタート→デプロイメント変更のイベントまで検出しています。

画像6.png

応答時間劣化の分析を行うとアクティブ待ち時間に多くの時間を割かれていることがわかります。
600ms待機するコードを埋め込んだので辻褄はあってます。

一連の処理の中でアクティブ待ち時間が増加したことにより問題が発生したことがわかりました。
では、コード内のどこにアクティブ待ち時間が存在するのか、というコードレベルの分析も行ってみましょう

画像8.png

一連の処理の中でどの関数で応答時間にどれだけの影響度を与えるのかかという分析をしてくれます。
こちらを見るとThread.sleepが応答時間の影響度に94%も寄与していることがわかります。
今回追加したコードと一致ます。

このようにDynatraceを活用すれば原因分析のためにサーバにログインしてログ分析やコードの見直しなど行う必要もなく、ピンポイントで原因箇所を提示してくれました。

まとめ

  • 監視対象ホストにOneAgentを導入することで問題の自動分析が可能
  • 様々な原因が考えられる中、ピンポイントで根本原因を特定する
  • 応答時間の影響度について関数レベルで分析してくれた

応答時間劣化としてNW遅延やDBやサーバのリソース枯渇などあらゆる原因が考えられます。
従来の運用では根本原因の特定に至るまで1つずつ可能性を潰していく必要がありますが、DynatraceはAIがピンポイントで根本原因を特定してくれました。

今後は他の障害パターンやk8s環境なども検証してみたいと思います。

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?