Loading article…
ソフトウェア工学におけるトレースとは、ソフトウェアプログラムの実行に関する情報をキャプチャして記録するプロセスを指します。この情報は通常、プログラマーがデバッグの目的で使用しますが、トレースログに含まれる情報の種類と詳細に応じて、経験豊富なシステム管理者やテクニカルサポート担当者、ソフトウェア監視ツールがソフトウェアの一般的な問題を診断するためにも使用されます。 [1]トレースは分野横断的な関心事です。
トレースと他の形式のログ記録の間には、必ずしも明確な区別があるわけではありません。ただし、トレースという用語は、プログラムの機能要件であるログ記録にはほとんど適用されません(したがって、高エネルギー物理学実験でのデータ取得や先行書き込みログ記録などの外部ソースからのデータのログ記録は除きます)。プログラムの使用状況 (サーバー ログなど) や、主にシステム管理者に関係するオペレーティング システムのイベント (イベント ビューアーなどを参照) を記録するログは、用語上はグレー エリアに分類されます。
トレースは主に、マイクロサービスやサーバーレス機能などの分散ソフトウェアシステムにおける異常検出、障害分析、デバッグ、診断の目的で使用されます。[2]
ソフトウェアトレース
ソフトウェア トレースは、開発者がデバッグ用の情報を収集するためのツールです。この情報は、開発サイクル中とリリース後の両方で使用されます。イベント ログとは異なり、ソフトウェア トレースには通常、イベントの「クラス」や「イベント コード」という概念はありません。イベント コードに基づくイベント ログ ソリューションがソフトウェア トレースに適さないその他の理由としては、次のことが挙げられます。
- ソフトウェア トレースは低レベルであるため、定義する必要のあるメッセージの種類が多数あることが多く、その多くはコード内の 1 か所でのみ使用されます。イベント コード パラダイムでは、これらの「ワンショット」メッセージに対して大幅な開発オーバーヘッドが発生します。
- ログに記録されるメッセージの種類は、イベント ログの場合よりも開発サイクルを通じて安定しないことがよくあります。
- トレース出力は開発者が使用することを意図しているため、メッセージをローカライズする必要はありません。したがって、トレース メッセージを、ローカライズする必要がある他のリソース (イベント メッセージなど) から分離しておくことが重要です。
- 決して見てはいけないメッセージがあります。
- トレース メッセージは、コードの可読性を高めることができるため、コード内に保持する必要があります。これは、イベント ログ ソリューションでは必ずしも可能または実行可能であるとは限りません。
ツール
OpenTelemetryは、分散トレースの包括的なサポートを提供するCNCFオープンソースプロジェクトです。 [3] Datadog、New Relic、SplunkなどのベンダーもトレースSaaSサービスを提供しています。[4]
GoogleとMetaは、 DapperとCanopyという独自のトレースフレームワークを開発しました。[2]
アプリケーション固有のトレース
- GNUデバッガのトレースコマンドによるトレース[5]
- cwrap による Linux C/C++ アプリケーションのトレース
- UST による Linux アプリケーションのトレース - LTTngと同じプロジェクトの一部
- Windows ソフトウェア トレース プリプロセッサ(別名 WPP)
- 命令セットシミュレーション
システム固有のトレース
オペレーティング システムでは、イベント ログを提供するために使用されるテクノロジの一部が利用できない 状況 (起動など) でトレースを使用できます。
Linux は、カーネル マーカーとLTTngを使用して、システム レベルおよびユーザー レベルのトレース機能を提供します。ftraceも Linux カーネル トレースをサポートしています。syslogは、さまざまなオペレーティング システムでシステム メッセージをログに記録およびトレースするための別のツールです。
FreeBSDとSmartOS は、カーネルとユーザーランドのトレースに DTrace を採用しています。
組み込みソフトウェアでは、トレースには効率的な計測とログ記録、およびCPUオーバーヘッドの低減のための特別な技術も必要です。[6]
テクニック
トレースの生成と収集
メソッド呼び出しのトレース生成は、ソースコードインストルメンテーション、ランタイム情報収集、またはデバッガ制御によって行うことができます。[7]トレースマクロ、アスペクト指向プログラミング、および関連するインストルメンテーション技術を採用することができます。
ソースコード内で使用されるライブラリは、データをエージェントに送信するか、直接コレクションコンポーネントに送信します。[4]
トレース分析
実行ツリーをモデル化するために、ISVisはルート付きツリーを有向非巡回グラフに変換し、Jinsightはコールフレーム原理を利用してトレースの累積情報を収集し、表現します。[7]
主な視覚化方法はスイムレーン ビューです。これはJaegerなどのツールに例えられ、注釈やキー値属性が含まれることがよくあります。広く使用されているにもかかわらず、この設計には厳密な正当性が欠けており、ユーザーは機能の欠落やわかりにくいナビゲーションなどの課題に頻繁に直面します。スイムレーン ビューの代替として、Jaeger のサービス依存関係ビューや SkyWalking のリスト、ツリー、テーブル ビューなどがあります。集計視覚化は大量のトレースを分析するためにも使用され、Canopy などのシステムはクエリ可能なメトリックを提供し、Jaeger はトレース比較機能を提供します。[8]
イベントログ
イベント ログは、システム管理者に診断と監査に役立つ情報を提供します。ログに記録されるさまざまなイベント クラスと、イベント メッセージに表示される詳細は、開発サイクルの早い段階で検討されることがよくあります。多くのイベント ログ テクノロジでは、イベントの各クラスに一意の「コード」を割り当てることが許可されているか、または割り当てが要求されています。このコードは、イベント ログ ソフトウェアまたは別のビューア (イベント ビューアなど) によって使用され、人間が判読できるメッセージをフォーマットして出力します。これにより、ローカリゼーションが容易になり、システム管理者は発生した問題に関する情報をより簡単に取得できます。
イベント ログは高レベルの情報 (多くの場合、障害情報) をログに記録するために使用されるため、ログの実装のパフォーマンスはそれほど重要ではありません。
重複したイベントが「頻繁に」記録されるのを防ぐという特別な懸念は、イベントスロットリングによって対処されます。
イベント ログとソフトウェア トレースを明確に区別することが難しいのは、両方に同じテクノロジがいくつか使用されていることと、両者を区別する基準の多くが個別ではなく連続的であるためです。次の表は、開発者が各目的のテクノロジを選択するために使用する、重要ではあるものの、決して正確でも普遍的でもない区別の一部を示しています。これらの区別は、各領域で新しいテクノロジを個別に開発するガイドとなります。
課題と限界
実行時にトレースを有効または無効にするには、多くの場合、バイナリに追加のデータを含める必要があります。これにより、トレースがアクティブでない場合でもパフォーマンスが低下する可能性があります。
コンパイル時にトレースが有効または無効になっている場合、クライアントのシステムからトレース データを収集できるかどうかは、トレース専用に有効になっているソフトウェアのバージョンをインストールし、その後問題を再現する意思と能力があるかどうかにかかっています。
ソフトウェアでのトレースでは、通常、トレース出力の精度と信頼性だけでなく、トレース対象のプロセスが中断されないことを保証する上でも、 高い堅牢性の基準が求められます。
トレースは低レベルであるため、大量のメッセージが生成される可能性があります。パフォーマンスの問題を軽減するには、コンパイル時または実行時にソフトウェア トレースを無効にするオプションが必要になることがよくあります。
セキュリティとプライバシー
プロプライエタリソフトウェアでは、トレースデータに製品のソースコードに関する機密情報が含まれる場合があります。
参照
参考文献
- ^ 「The Tracing Book」。2009年2月24日時点のオリジナルよりアーカイブ。
- ^ ab Li, Bowen; Peng, Xin; Xiang, Qilin; Wang, Hanzhang; Xie, Tao; Sun, Jun; Liu, Xuanzhe (2022). 「観測性を楽しむ: マイクロサービスのトレースと分析に関する産業調査」. Empirical Software Engineering . 27 (1): 25. doi :10.1007/s10664-021-10063-9. ISSN 1382-3256. PMC 8629732. PMID 34867075 .
- ^ Mandel, Maya (2023-06-07). 「Council Post: 分散トレース: マイクロサービスの可観測性の鍵」. Forbes . 2024-01-12閲覧。
- ^ ab Janes, Andrea; Li, Xiaozhou; Lenarduzzi, Valentina (2023). 「オープン トレーシング ツール: 概要と批判的比較」.システムおよびソフトウェア ジャーナル. 204. Elsevier BV: 111793. arXiv : 2207.06875 . doi :10.1016/j.jss.2023.111793. ISSN 0164-1212.
- ^ 「トレースポイント (GDB によるデバッグ)」. sourceware.org . 2022 年 6 月 24 日閲覧。
- ^ Kraft, Johan; Wall, Anders; Kienle, Holger (2010)、「組み込みシステムのトレース記録: 5 つの産業プロジェクトから学んだ教訓」、Runtime Verification、Springer Berlin Heidelberg、pp. 315–329、doi :10.1007/978-3-642-16612-9_24、ISBN 9783642166112
- ^ ab Mertz, Jhonny; Nunes, Ingrid (2019). ソフトウェア監視の実用的実現可能性について: 影響の少ない実行トレースのフレームワーク。CASCON '04: 2004 年共同研究に関する先端研究センター会議の議事録。IEEE。pp. 169–180。doi : 10.1109 / SEAMS.2019.00030。ISBN 978-1-7281-3368-3。
- ^ 「分散トレース視覚化に関する質的インタビュー調査：課題と機会の特徴づけ」IEEE Xplore 2023-02-01 2024-01-12閲覧。