Header background

メインフレームの可用性を大幅に向上させるために、ログとトレースを連携させましょう

Dynatrace SaaS およびマネージド環境の両方で、z/OS のログとトレースをコンテキスト化することで、メインフレームアプリケーションの問題解決を迅速化し、予防的かつ先制的な運用モードへの移行を実現します。

ログはオブザーバビリティテレメトリの基盤です

組織は、ビジネス上重要な目標を達成するための必須要素であるシームレスなデジタルサービスの提供において、ますます課題に直面しています。これらの課題は、複雑なハイブリッドクラウド環境によって増幅され、クラウドプロバイダーやIBM Zメインフレームなどのプラットフォームにまたがる多様なテクノロジーの管理が特に困難になります。

この複雑性に対処するためには、メインフレームプラットフォームを含むアプリケーションデリバリーチェーンの全レイヤーにわたる可観測性テレメトリとそのシグナルを、単一のAI搭載オブザーバビリティソリューション内で統合することが不可欠です。

Dynatraceのエンリッチメント機能は、トレースID、スパンID、プロセスグループインスタンスIDなどのコンテキストメタデータを自動的に追加することで、手動でのタグ付け作業を必要とせず、取り込まれたログレコードを強化します。これにより、ログ、アプリケーションパフォーマンスメトリクス、トレース間のシームレスな相関分析が可能となります。これは、AI駆動の根本原因分析を加速し、RCA(根本原因分析)とMTTx(平均復旧時間)の短縮に要する時間を大幅に削減するために不可欠であり、多くのお客様がこれを確認されています。

z/OSログ収集の簡素化と自動化

Dynatraceのログ管理および分析機能は、分散型テクノロジースタックを超え、IBM Zメインフレームプラットフォームのサポートも提供します。監視対象のIBM CICSおよびIBM IMSリージョンからログを自動的に取得・取り込み、高度な取り込みルールを提供します。収集されたすべてのログは、トポロジカルメタデータによって自動的にエンリッチされ、z/OSホスト(LPAR)およびz/OSプロセス(リージョン)向けのDynatraceトポロジおよびエンティティモデルへのシームレスなマッピングを可能にします。

Dynatrace automatically maps log lines to z/OS entities, in this case, to the process name and job ID of a CICS region
図1. Dynatraceはログ行をz/OSエンティティ(この場合はCICSリージョンのプロセス名とジョブID)に自動的にマッピングします

さらに、ログにはトレースIDおよびスパンIDを付加することができ、各ログ行を、それに対応するCICSまたはIMSトレース、あるいはそれを生成したスパンと正確に関連付けることが可能です。

Dynatrace can map log lines to a specific z/OS trace, which allows you to directly navigate to the trace that created the specific log line (via “View trace”).
図 2. Dynatrace はログ行を特定の z/OS トレースにマッピングできます。これにより、特定のログ行を生成したトレースに直接移動することが可能です(「トレースを表示」経由)。

これにより、組織内のあらゆるユーザーにとってナビゲーションが劇的に簡素化されます。トレースIDとスパンIDを含むログ行を選択することで、負荷時間や遅延を理解しながら、関連するトレースに直接移動できます。

This example shows an end-to-end trace and the log line that was written by a CICS COBOL program
図 3. この例は、エンドツーエンドのトレースと、CICS COBOL プログラムによって書き込まれたログ行を示しています

これまでにご紹介した内容をまとめます。ログのエンリッチメントにより、以下の点が大幅に強化・加速されます:

  • 分散トレースとの相関により、システム横断的なエンドツーエンドの可視性を実現します。
  • トラブルシューティング:ログを特定のスパンスまたはトランザクションに紐付けることで、トラブルシューティングを加速します。
  • 構造化および非構造化ログデータ双方のオブザーバビリティを実現し、ログ形式に関わらず包括的なインサイトを保証します。

エージェントを超えた機能:OpenTelemetryによるメインフレームログのDynatraceへのストリーミング

Dynatrace OneAgent® は、標準でログの取り込みをサポートしております。しかしながら、メインフレーム環境においては、状況がより複雑になります。

すべてのログが同じように扱われるわけではない理由

一部のログ、特にメインフレーム上のログは、独自仕様で顧客固有であり、レガシーワークフローに深く組み込まれています。Dynatraceは追加のログタイプに対する自動化されたカバレッジを継続的に拡充していますが、その構造や関連性が顧客ごとに異なるため、OneAgentでネイティブにサポートされないログも存在します。

とはいえ、それらが完全に手の届かない存在というわけではありません。

OpenTelemetryによる解決策

OneAgentのネイティブ対応範囲外のログについては、OpenTelemetryが強力な代替手段を提供します。OpenTelemetry Collectorを導入することで、お客様はLPARから分散ホスト(MSU消費を節約するため、Linux、Windows、またはzLinuxが推奨されます)へログデータをストリーミングできます。ただし、z/OS自体もOpenTelemetry Collectorのホスト先として選択肢となります。

コレクターは以下の機能をサポートします:

  • 任意のテキストファイル用ファイルログ受信機
  • 構造化システムログ用Syslog受信機
  • 前処理およびエンリッチメントのためのフィルタープロセッサー
  • 複数のバックエンドへの同時エクスポート(OTLP経由のDynatraceを含む)

メインフレームからのログ取得

LPARから分散システムへログを移動する方法はいくつかあります:

  • SFTP:簡素ながら信頼性の高い方法
  • z/OSMF:SMFレコードへのREST APIアクセスを提供します
  • z/OS Data Gatherer:SMF REST サービス
  • カスタムスクリプトまたはプロセス:特定のデータセットに合わせて調整
  • ストリーミングフレームワーク:Kafka、MQ、さらにはFTPからコレクターへのブリッジ

結論として:メインフレームから OpenTelemetry Collector が配置されたホストへログデータを転送するだけで、その後はすべて Collector が処理いたします。

OpenTelemetry Collector を実行するための専用ホストを必ずしも用意する必要はありません。Dynatrace OneAgent が既に LPAR の監視を行っている場合、Dynatrace zRemote コンポーネントをホストする ActiveGate は Collector にとって十分に適切な環境となります。

The ActiveGate hosting the zRemote mediates the ingestion of both out-of-the-box logs and OpenTelemetry logs.
図4. zRemoteをホストするActiveGateは、標準装備のログとOpenTelemetryログの両方の取り込みを仲介します。

前処理とエンリッチメント

DynatraceディストリビューションとOpenTelemetry CollectorのContribディストリビューションの両方が高度な前処理をサポートしております:

  • タイムスタンプの正規化(例:z/OS タイムスタンプを Unix タイムに変換)
  • リソース属性抽出(例:ジョブ名、LPAR ID、サブシステム)
  • 機密データのマスキングおよびフィルタリング

これにより、複雑なログであってもバックエンドに到達する前に構造化されたテレメトリに変換されます。

さらに優れた機能:Dynatrace OpenPipeline®

OpenTelemetry が収集と変換を担当する一方で、Dynatrace OpenPipeline® は収集および処理中にさらなる知能層を追加します:

  • ビジネスコンテキストによるログのさらなる充実
  • メトリクス、イベント、ビジネスオブザーバビリティイベントの抽出
  • AI 駆動によるベースライン設定と異常検知の適用
  • データの変換、マスキング、または削除
  • これらの機能の一部はコレクターと重複しており、ユーザーはパフォーマンス、コスト、制御に基づいてロジックを適用する場所を柔軟に選択できます。

Operlog:最適な候補

多くの顧客がストリーミングを希望するシステムログであるOperlogを例に挙げましょう。単純なテキストデータセットではありませんが、創造的な解決策でそのギャップを埋めることが可能です。Operlogレコードを抽出し、Linuxホスト上にテキストとして保存できれば、コレクターは即座にそれらを取り込むことができます。そこから、Dynatraceの可視化機能とアラート機能が作動します。

以下は、OperlogがDynatraceでストリーミングおよび処理された後の様子のスナップショットです:

Log entries captured from Operlog visualized in Dynatrace
図 5. Operlog からキャプチャされたログエントリを Dynatrace で可視化したもの

ログだけでは物足りないですか?

OpenTelemetryを介したプロプライエタリなログファイルの取り込みに限定されるわけではありません。

メインフレーム上のサブシステムの健全性追跡に関連するメトリクスにアクセスできますか?特定のデータをログではなくイベントとして取り込みたいとお考えですか?

OpenTelemetry Collectorが高度にカスタマイズ可能であるのと同様に、Dynatraceではこれらすべてのシグナルを取り込むための複数の方法を提供しています。

Possible sources for OpenTelemetry signals and how Dynatrace ingests them
図6. OpenTelemetryシグナルの可能なソースとDynatraceによる取り込み方法

結論

メインフレームのログは複雑かもしれませんが、決して手の届かないものではありません。OpenTelemetryとDynatraceを連携させることで、最もプロプライエタリなデータセットさえも取り込むことが可能です。OneAgent、OpenTelemetry、あるいはハイブリッドアプローチのいずれを利用する場合でも、重要なのは創造性と適切なツールの選択です。

今後の展開

Dynatraceは現在、z/OSエージェントを通じてCICS MSGUSRおよびIMSマスターターミナルログをサポートしており、これらの機能強化に引き続き取り組んでおります。これには、追加のz/OSログタイプのサポート検討や、z/OSエージェントを通じて収集される情報の範囲拡大が含まれます。

また、IBM Z および LinuxONE 上の Linux 向けログ監視もご利用いただけます。詳細は、ブログ記事「IBM Z メインフレーム上の Linux 向け完全なオブザーバビリティをログで実現」をご覧ください

Dynatraceログオブザーバビリティの導入を開始する

エンドツーエンドのオブザーバビリティを向上させ、お客様の特定の z/OS 環境におけるカスタマイズされた可能性を探求したいとお考えでしたら、ぜひお問い合わせください。デモのご依頼や、Dynatrace が提供できる機能についてさらに詳しく知りたい場合は、お気軽にご連絡ください。