トラブルシューティングガイド：トランザクションログの使用 - Support and Troubleshooting

トラブルシューティングガイド：トランザクションログの使用 Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } }  このトラブルシューティングガイドの情報を使用してトランザクションログテーブルの関連エントリーを調べることが、問題の原因解明に役立ちます。

問題点を把握するための重要な手法の 1 つは、報告された例に関連するトランザクション履歴の詳細を追跡することです。トランザクションの詳細を知るための鍵は、トランザクションログテーブル [syslog_transaction] を使用することです。この記事では、このテーブルの機能と使用方法について説明します。このテーブルに豊富に含まれる詳細情報から、問題の解決に十分な情報が得られるかもしれません。問題解決に十分な情報ではないとしても、調査できる多くの手がかりが得られます。

トランザクションログを使用したパフォーマンス問題のトラブルシューティング ボトルネックはどこですか？ パフォーマンスの問題に対処するときはいつでも重要になる質問が、「ボトルネックはどこか」です。トランザクションログには、時間が費やされている場所の内訳が表示されるため、ボトルネックの原因を理解するのに役立ちます。トランザクションログには、サーバー、クライアント、SQL、ビジネスルール、クライアントスクリプト、UIポリシー、待機時間などのタイミングが含まれます。これらの各フィールドの意味を理解することで、特定のパフォーマンスの問題の原因を切り分けることができます。

ユーザーは何をしていましたか？ トランザクションログの URL フィールドを確認することで、ユーザーがアクセスしていたページを特定できます。また、フォーム送信の場合、トランザクション URL にはパラメーターが含まれます。URL パスの意味と「?」に続く部分に含まれるパラメーターを理解することは、あるトランザクションで何が起こっていたかを正確に解釈するのに大いに役立ちます。(詳細については、「 URL による移動 」を参照してください。)

[ユーザーエージェント] フィールドを確認することで、ユーザーが使用していたブラウザとOSを特定できます。この情報は、問題がクライアント側の問題であり、問題を再現する方法を知る必要がある場合に非常に重要です。問題の正確な「再現手順」を見つけることは、問題のトラブルシューティングの重要な部分です。一部の問題は、特定のブラウザバージョンとオペレーティングシステムの組み合わせでのみ再現できるため、ユーザーエージェントフィールドはこれをつなぎ合わせるのに役立ちます。厄介なのは、ユーザーエージェントの文字列を解読するのが難しい場合があることです。 UserAgentString.com のようなツールが役立ちます。

[IP アドレス] ィールドを観察することで、トランザクションがどのネットワークから発生したかを判断できます。この情報は、断続的に発生し、一部のユーザーまたは地域に影響を与え、他のユーザーまたは地域に影響を与える問題を診断する場合に非常に役立ちます。たとえば、この問題は、ユーザーが企業ネットワーク内からログオンしている場合に発生する可能性がありますが、ホーム ネットワークからログインしている場合は発生しません。または、パフォーマンスの問題が、同じ地理的な場所にある特定のユーザーグループから報告されているような場合もあります。特定の IP アドレスからのトランザクションが他の IP アドレスよりも遅いことが判明するかもしれません。 問題はどこで発生しましたか？ ServiceNow は「クラスター化された」アーキテクチャを採用しており、複数の Java ノードが存在するため、問題が ServiceNow アーキテクチャのどこで発生したかを知ることは重要です。ここでは セッション ID フィールドと システム ID フィールドが重要です。セッション ID は、特定のユーザーのセッションに関連するすべてのトランザクションを示します。セッションは、ユーザーがシステムにログインすると開始されます。ユーザーが再度ログインする必要がある場合は、新しいセッションが作成されます。セッションのデフォルトのタイムアウトは、非アクティブ状態が 30 分間続くことです。[システム ID] は、問題が発生したノードを示します。1 つのノードのすべてのトランザクションが影響を受けたが、他のノードのトランザクションは影響を受けなかった場合を考えてみましょう。この情報は、考えられる原因を切り分ける上で重要です。ノード固有の詳細なシステムログを検索できるように、問題が発生した場所を知ることも重要です。(ログファイルダウンローダーまたはログファイルブラウザからアクセス)

影響があった期間(時間帯)に何が何が起こっていたか？ 特定の期間中に複数のユーザーが問題を経験したものの、その後問題が解消した場合、この質問を考えることになります。トランザクションログテーブルを使用して、特定の期間中にどのようなトランザクションやスケジュール済みジョブが実行されていたかを判断できます。この情報を判断するのは少し難しい場合があります。理由の 1 つは、トランザクションログテーブルの Created フィールドに、トランザクションの開始時刻ではなく、トランザクションが完了した時刻が反映されるためです。

次の例を考えてみましょう。午前 7 時 15 分から 7 時 45 分の間に、速度低下の期間があったことが報告されたとします。さらに、その根本原因が、午前 7 時 10 分に開始し、午前 9 時 15 分に終了したトランザクションにあるとします。午前 7 時 15 分から 7 時 45 分の間に作成されたすべてのトランザクションを検索しても、トランザクションが午前 9 時 15 分まで終了せず、作成時刻が午前 9 時 15 分になるため、問題の原因となったトランザクションは明らかになりません。

ここで役立つ別のタイムスタンプフィールドがあります。処理開始時間 (start_process_at) フィールドは、トランザクションにスレッドが与えられ、実際に処理が開始された時刻を示します。これは、トランザクション処理の開始前にネットワーク待機、セマフォ待機、またはセッション待機が蓄積されている可能性があるため、ユーザーが考える開始時刻とは異なる場合があります。非常に長い実行時間のトランザクションを見つけるには、より広い時間枠 (影響期間の両側で 1 時間など) を検索し、120,000 ミリ秒 (または 2 分) を超える応答時間の条件を含めることができます。このタイプの検索は、24 時間の時間スパンで検索する場合でも、10 秒から 20 秒以内に完了します。

仕組み トランザクションログテーブル [syslog_transaction] は、ServiceNow 製品を介して行われる多くのトランザクションをキャプチャします。これには、ユーザートランザクション、統合トランザクション (SOAP、REST など)、バックグラウンドトランザクション (スケジュール済みジョブ) が含まれます。ただし、次のタイプのトランザクションはキャプチャされません。

AJAX や Angular などの非常に短い非同期トランザクションの一部 大量の REST トランザクションの一部 Record Watcher やエージェントチャットなどの非同期メッセージバス (AMB) トランザクション 失敗やキャンセルによって完了しなかったトランザクション。キャンセルされたトランザクションを表示する別のテーブルがあります。 各トランザクションには、応答時間 (サーバー上の時間)、クライアントネットワーク時間 (合計時間 - (サーバー + クライアント時間))、データベース包括時間、ビジネスルール包括時間、ブラウザ時間など、どこで時間が費やされたかのブレークダウンが含まれます。追跡されるその他の詳細情報には、どのユーザーがどのトランザクションを実行していたか、ユーザーがログインしたノード、ユーザーの送信元 IP アドレス、使用されたブラウザとオペレーティングシステムを示すユーザーエージェント文字列が含まれます。 トランザクションログテーブルへのアクセスに関する注意 トランザクションログテーブルは非常に大きいため、クエリの実行には常に注意が必要です。ほとんどのお客様にとって、24 時間はトランザクションログテーブルでクエリを実行する必要がある最大時間です。それを超えると、クエリが非常に遅くなる可能性があります。ただし、インデックス付きフィールドに特定のフィルターがある場合は、問題なくより長い期間をクエリできます。このため、テーブルにアクセスするモジュール (システム診断>トランザクション、システム診断>トランザクション (バックグラウンド)、およびシステム診断>トランザクション (すべてのユーザー)) にはすべて、作成日 = 本日のデフォルトフィルターがあり、「ゲスト」ユーザーが開始したトランザクションは除外されます。ただし、一部の顧客システムでは、24 時間のクエリーでも、システムが妥当な時間内に処理するには多すぎる場合があります。そのため、ベストプラクティスとして、まず URL でテーブルにアクセスし、sysparm_filter_only=true パラメーターを使用してリストフィルターのみを表示するようにします。そこから、必要な情報のみを問い合わせる、条件を厳密に絞ったクエリを指定することができます。[Between] フィルターと他の制約フィルター ([応答時間] > 1000 や [作成者] = joe.employee など) を使用して、できるだけ短い期間を指定するようにしてください。 注:「ゲスト」ユーザーによって作成された多くのトランザクションが表示されるのは、ServiceNow ではまったく正常な動作です。「ゲスト」ユーザーとは、ユーザーが現在認証されていないトランザクションに対してシステムによって属性付けされるユーザーです。たとえば、公開ページにアクセスしている場合や、プライベートページにアクセスしたがまだ認証されていないためにログイン画面にリダイレクトされる場合などです。 関連するログエントリーを効率的にクエリする手順 ユーザーテーブル (sys_user) から問題が発生したユーザーの user ID を確認します。

問題がいつ発生したか(問題を経験した時間)を調べます (可能であれば分単位まで)。

問題が発生したときのユーザーの操作を確認します。

アドミンユーザーとしてインスタンスにログインします。

/syslog_transaction_list.do?sysparm_filter_only=true に移動します。

リストに対してグラフィカルフィルタービルダーを展開し、次のフィルターを追加して、報告された時間前後のそのユーザーによるすべてのトランザクションを取得します。 [Created] [between] [ ] and [ ] [Created by] [is] [ ]

[実行] をクリックします。

返されるトランザクションのリストから、URL または応答時間がユーザーから提供された問題の説明と一致するかどうかを確認します。 また、 KB0997495 - 遅いトランザクションのトラブルシューティング方法 も、解決の参考になります。

トランザクションログテーブルのフィールドの定義 まだカスタマイズしていない場合は、リストの歯車アイコンをクリックして、リストに表示される列をカスタマイズします。このセクションで説明する列は、役に立つ場合があります。

サーバーメトリクス (フィールドラベルのアルファベット順にリスト) アプリスコープ (app_scope) ：トランザクションが実行された親スコープ。 ビジネスルール時間 (business_rule_time) : ビジネスルールまたはスクリプトジョブの実行にかかった時間 (ミリ秒)。スクリプトジョブには、スケジュール済みスクリプト実行と非同期ビジネスルールが含まれます。これには、最初のビジネスルール呼び出しからダウンストリームにかかった時間が含まれます。タイマーはビジネスルールの開始とともにスタートし、そのビジネスルールが完了したときにのみ停止します。これには、SQL の完了待ち、または最上位ビジネスルールのスクリプトからトリガーされた他のビジネスルールやプロセスの待ち時間も含まれます。SQL のトリガー方法はビジネスルール以外にも存在するため、SQL 時間として、ビジネスルール時間よりも長い時間が表示されることはあり得ます。ただし、ビジネスルールによってトリガーされた SQL の実行にかかった時間はすべて、ビジネスルール時間の計算に含まれることに注意してください。 作成日時 (sys_created_on) ：トランザクションが記録された時点。トランザクションはそのトランザクションの終了時に記録されることに注意してください。従って、トランザクション (スケジュール済みジョブを含む) の開始時刻を判定するには、[作成日時] から [応答時間] の値を引く必要があります。 作成者 (sys_created_by)： トランザクションを実行したユーザーのユーザー ID (sys_user.user_name)。ほとんどのバックグラウンド/スケジュール済みジョブは、「system」と呼ばれる特別なユーザーによって実行されます。ユーザーの事前認証によって開始したトランザクションには、「guest」と呼ばれる特別なシステムユーザーが記録されます。 IP アドレス (ip_address) : ServiceNow に入ってくるトランザクションのソース IP アドレス。 ネットワーク時間 (network_time) : Zurichの時点では、これはサーバーが応答のすべてのバイトを出力ストリームに書き込むのにかかる時間であり、それらのバイトをインターネット経由で送信するのにかかる時間ではありません。これは、ほとんどの人がネットワーク時間という名前の測定に期待するものではありません。これは、ほとんどの人が予想するよりもはるかに低く、通常は0〜5ミリ秒の範囲です。このメトリクスはほとんど役に立ちません。 処理開始時間 (start_process_at) : トランザクションにスレッドが与えられ、実際に処理が開始された時刻を示します。 応答時間 (response_time) ： サーバーがトランザクションの実行に費やした時間の長さ (ミリ秒)。リダイレクト前に費やされたサーバー時間 (HTTP 302) は含まれません。その後の部分的なページ要求 (AJAX など) やリソース (CSS、JavaScript、画像など) の提供に費やされた時間は含まれません。セマフォの待機時間や、同一セッションの前のトランザクション完了を待機する時間は含まれます。従って、一部のトランザクションでは応答時間の 90% 以上が別のトランザクションの完了待機に費やされ、測定値が大きく上昇して原因がわかりにくくなる可能性があります。 セマフォ待機時間 (semaphore_wait_time) ：すべてのセマフォが使用中であることに起因する待機時間 (ミリ秒)。 セッション (session) : ログインしたユーザーの Java セッション ID。この ID は、同じユーザーがシステムログに出力したログメッセージの判別に役立ちます。バックグラウンドジョブの場合、セッション ID には、ジョブを実行しているワーカーの名前が含まれます。 セッション待機時間 (session_wait_time) ：同一ユーザーセッションが最初のトランザクションが完了する前に 2 番目のトランザクションを開始したことによる待機時間 (ミリ秒)。 SQL 時間 (sql_time) ：データベースへの要求と応答の待機にかかった時間 (ミリ秒)。データベースへの要求/応答の処理に関与するリソース (アプリケーションサーバーの CPU、アプリケーションサーバーと db サーバー間のネットワーク帯域幅など) が過負荷になっている場合、この値が不自然に増大する場合があります。なお、ホームページでは、マルチスレッドを使用することで複数の SQL ステートメントを同時に実行することが可能です。SQL 時間は、メインスレッドまたは子スレッドでトランザクションの一部として実行されたすべての SQL の合計であるため、home.do トランザクションの SQL 時間は、多くの場合トランザクションの合計処理時間より長くなります。 システム ID (system_id) ： このフィールドには、トランザクションが実行されたノードの名前が含まれます。 テーブル (table) 表示されたテーブル (incident、change_request など)。 合計待機時間 (total_wait_time) ：サーバーがトランザクションを処理できるようになる前に、トランザクションが待機していた時間 (ミリ秒)。 トランザクションパターン (transaction_pattern) ：匿名化された URL を識別する一意のハッシュコード。これは、ログ内の特定のトランザクションを遅いトランザクションモジュール (sys_transaction_pattern テーブル) とリンクするために使用できます。 トランザクション処理時間 (transaction_processing_time)： サーバーの応答時間から待機時間を差し引いた時間。すべての処理時間を実際にはどのトランザクションが使用しているかを測定するのに適した方法です。 タイプ (type) ： トランザクションのタイプ (フォームやリストなど)。 URL (url) : 受信 HTTP 要求の宛先アドレス。スケジュール済みジョブトランザクションの場合、これはプリフィックス「JOB:」の後にジョブの名前が続きます。 ユーザーエージェント (user_agent) : ユーザーエージェント文字列は、トランザクションを開始したブラウザとオペレーティングシステムを識別する一意の識別子です ( http://www.useragentstring.com/index.php を参照 ビュー (view_id) : このフォーム/リストに使用されたビュー (sys_ui_view テーブル)。 クライアントトランザクションタイミング クライアント側 (ブラウザやモバイルデバイスなど) で操作を追跡するタイミング。すべてのトランザクションタイプで使用できるわけではありません。Safari では利用できません。

クライアントトランザクション：(client_transaction) トランザクションでクライアントタイミングが正常に記録された場合、true。 クライアント応答時間：(client_response_time) navigationStart から loadEventEnd までの時間 (ミリ秒)。つまり、ページ要求から HTML 読み込みイベントの実行完了までの合計時間 (サーバー時間を含む)。これには、onLoad クライアントスクリプトと、結果として起動した onChange スクリプトが含まれます。つまり、サーバー時間、ブラウザ時間、javascript、および HTTP 要求や HTTP 応答にかかった時間がこれに含まれます。これは最も包括的なタイミング測定基準であるため、他の時間よりも大きくなるはずです。ただし、SQL 時間のように複数のスレッドの累積時間をカウントする可能性があるものは、このルールの例外になります。 クライアントネットワーク時間：(client_network_time) client_response_time の合計値からサーバーおよびブラウザの応答時間とみなされる値を差し引いた値が反映されます。一部のトランザクションではこの式とわずかに差異が発生する可能性がありますが、概して正確です。 コア UI トランザクションタイプの場合、client_network_time計算は、次のように測定される合計「期間」です。 [エンドツーエンドのトランザクション期間] - [サーバー時間] - [ブラウザーのレンダリング時間] = client_network_time

一部のトランザクションでは、この数式にわずかな不一致があることに気付くかもしれませんが、ほとんどの場合正確です。 注意点として、HTTP 302 リダイレクト直後のトランザクションでは、直前のトランザクション応答時間が client_network_time に反映されます。[2018 年 10 月 30 日の時点] これは製品の現行の動作であり、変更の予定はありません。これはPRB632265に記載されています。すべてのサービスカタログトランザクションが 302 リダイレクトを使用するため、サーバー時間をクライアントネットワーク時間と誤ってアトリビューションすることは、コア UI サービスカタログのトランザクションで最も一般的に見られます。アイテムの注文を開始した時点から注文概要ページに到達するまで、service_catalog.do プロセッサにヒットする最初のトランザクションがあり、次に適切なページにリダイレクトされる 2 番目のトランザクションがあります。 パフォーマンスタイミング DOM オブジェクトをサポートしていないブラウザの場合、client_network_time は、ページの読み込み開始時点とページ要求時点の差からサーバー時間を引いた値によって決まります。これにより、実際にはブラウザの時間である時間がネットワーク時間として記録されるため、時間が肥大化する可能性があります。ほとんどすべてのブラウザーが API をサポートしています。サポートされているブラウザーのリストについては、 https://developer.mozilla.org/en-US/docs/Web/API/Performance を参照してください。 2025 年現在、client_network_time は構成可能なワークスペースなどのネクストエクスペリエンス UI に関連するトランザクションの応答時間の追跡に使用されています。計算は次のように行われます。 [responseStart] - [fetchStart] - [syslog_transaction.response_time] = client_network_time

Next Experience のパフォーマンスのトラブルシューティングの詳細については、 KB1640661 「 How to troubleshoot Slow Transactions or Page Load Issues in Next Experience Workspace and Portal Experiences 」を参照してください。

閲覧時間 (browser_time) : コア UI のみ。閲覧時間の測定方法は、リスト V2 とリスト V3 のどちらを使用しているかによって異なります。 [Live V2 以前] responseEnd から loadEventEnd までの時間 (ミリ秒)。これは、現在のページが最初のワイヤフレーム HTML ページのダウンロードを完了してから、「load」イベントとその結果生じるすべてのアクションが完了するまでの時間です。リンクされたすべてのリソース (画像、CSS、JavaScript など) をダウンロードする時間が含まれます。スクリプトを実行する時間は含まれません。

[リスト V3：Helsinki で利用可能][おそらく Jakarta 以降のすべてのトランザクションについて、KB のこの段落は改訂が必要] リスト V3 では、browser_time によって、JavaScript が最初に実行を開始する時間から、AJAXClientTimings 要求がサーバーに送り返されるまでの時間が追跡されます。この時間は、loadEventEnd - responseEnd の window.performance.timing イベントを実行する以前の方法に比べて長くなります。そのため、リスト V3 への移行後に browser_time 測定基準が増大したとしても、驚く必要はありません。部分的にはユーザーエクスペリエンスの実際の低下を反映している可能性もありますが、単純に測定基準が変更されたことの影響も考えられます。例えば、リスト V3 では browser_time が client_response_time の 2 ～ 3 倍になることがあり、混乱を招く場合があります。これは client_response_time で window.performance.timing オブジェクトを使用する古いモデルが採用されているためです。

クライアントスクリプト時間 (client_script_time) : コア UI のみ。クライアントスクリプトの実行に費やされたミリ秒数。 その他のクライアントタイミングの詳細 Fuji 以降、ServiceNow はほとんどのクライアントタイミングの計算処理に window.performance オブジェクトを使用しています。このオブジェクトは、執筆時点 (2016 年 10 月 14 日) において、すべてのブラウザの最新版でサポートされている Web 標準です。Window.performance は IE9 以降でサポートされています。この window.performance の詳細については、次のリソースを参照してください。 https://www.html5rocks.com/en/tutorials/webperformance/basics/ http://w3c.github.io/navigation-timing/ https://www.w3.org/TR/navigation-timing/#dom-performancetiming-requeststart 次の図は、ナビゲーションタイミング Web 標準のタイムラインのクイックリファレンスです。

Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } }

Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } }