導入背景

ホストコンピューターからオープンプラットフォームへの移行が進むにつれ、監視すべき対象が増加しました。
これに伴い、オンライン処理を中心に性能課題が発生し、システムの性能問題発生時の対応時間の増加に頭を悩ませておりました。

問題発生時に、復旧までの時間を短縮し、システム利用者の業務影響を最小限にすること目指し、Dynatraceを中心に据えて運用改善を図ることにいたしました。

導入による効果

サーバーリソースの描画方法として、累積した情報をインプットとして自社ツールでグラフ化する方法を採っていましたが、表示の自由度が低い状況にありました。Dynatrace(ホスト機能)の活用により、確認したいときに確認したいメッシュで可視化ができるようになりました。

メッシュ例

１．　リソース情報(CPU,メモリ,ディスクなど)の状況が掴め、詳細確認も容易に

２．　ログが1日単位で別ファイルとなっていることで、日跨りの部分を別グラフで確認が必要だったが、1週間単位でグラフ描画をさせるなど、ワンクリックで見たい粒度に変更可能に

お話を伺った方

単純導入では解決できなかった課題を解決

弊社で導入している独自のフレームワークにより、Dynatraceを単純導入するだけでは、細かい単位でのトランザクション情報は収集できますが、運用管理をしているメンバーが管理の際に必要としている処理ID単位での情報が識別できないことが確認されました。

Dynatraceの”Request attribute”という機能を用いることで、　弊社が必要とする処理IDが格納されているクラス/メソッドのパラメータをDynatraceに指定し、処理IDを取得・紐づけを実現しました。

Request attributeとは

各リクエストの属性情報を取得することで、各分析画面に表示されるリクエストをフィルターしやすくする機能。

Dynatraceがデフォルトで取得していない値も取得可能。

時間短縮と原因特定が可能に

Dynatraceを活用していない場合、有識者が設計書、ログ、プログラムを確認し、遅延箇所を特定することになりますが、不具合箇所周辺にログ情報が無ければ、原因特定に至らないケースもありました。

今回の対応により、独自フレームワーク上でも、管理したいトランザクション単位で、実行時間、レスポンスタイムを一覧で出力できるようになりました。これにより、事象発生の処理を即座に特定することが可能になりました。

また、特定処理からコンポーネント単位の処理時間を確認する画面にドリルダウンができるようになったため、ピンポイントで原因箇所を特定することができるようになりました。

今後の展望

今回はサーバー監視をベースとしたレスポンス課題への運用高度化検討の取り組みを実施したが、システム利用者から見ると「システム全体として安定的に利用できること」が必要となります。

性能悪化などのシステム課題は、サーバー領域だけでなく、OA端末、NWに起因するケースもあるため、サーバー領域にとどまらず、OA、NWを含めたシステム全体の運用高度化を推し進めていきます。

結果として、安定的にサービスを提供できる(サス鉄ナブル®な)　基幹システムへの到達を目指します。

各担当で運用改善検討を推進し、それぞれが運用改善に必要な情報を明確化している現状から、それぞれが欲しい情報を集約・融合し、システム全体として統合的な監視を狙っていきたいと考えております。

2025年2月