ServiceNowのData Snapshotsは動いたのか？ 実行ログ88行から9時間の記録を読む

「機能は入っているが、使われているのか」を判断したい場面があります。設定画面を見ても、有効か無効かしか分かりません。Australia の PDI で syslog_pa_dm を開くと、Data Snapshots の実行ログが88行だけ残っていました。9時間ぶんです。 その先が無い理由まで、レコードから追えました。

「この機能、使われているのか」を判断する

新しく入った機能を評価するとき、設定画面を見ても分かることは限られます。有効か無効か、それだけです。

本当に知りたいのは、過去に動いたのか、動いたとして何を処理したのか、そしていつから止まっているのかです。

この3つに答えられるのがログです。ただしログを持たない機能も多いので、専用のログテーブルがあるかどうかが最初の分かれ目になります。

Data Snapshots は専用のログを持っている

Data Snapshots には syslog_pa_dm という専用のログテーブルがありました。画面上の名前は Data Snapshots Logs です。

継承元を見ると Log Entry でした。ServiceNow の標準的なログの仕組みに乗っているという意味です。だから重大度（Information / Warning / Error）や作成日時といった、ログとして必要な項目が最初から揃っています。

システムログ全般の読み方はシステムログ（syslog）の読み方と溜まり方にまとめました。今回はその機能別の版を読みます。

名前が役割を語っている

syslog_pa_dm という名前は3つに分かれます。syslog がシステムログ、pa が Performance Analytics、dm がデータモデル。どの機能のどんなログかが名前だけで分かります。

ジョブ側の sysauto_dm_cdc_collector にも dm が入っていて、同じ機能群だと判別できます。こちらは Scheduled Job を継承していて、定期実行の仕組みに乗っていました。

専用ログがある機能は、後から追える。 これは機能を選ぶときの判断材料にもなります。

結論：ログは9時間で途切れ、その25分後に無効化されていた

88行から読み取れたことは3つあります。

ログは88行しかありません。2026年7月18日の17時台から翌19日の01時台まで、9時間ぶんだけです。毎時ちょうど10行ずつ記録されています。

88行すべてが Information でした。エラーも警告も1件もありません。 開始と完了もペアで揃っていて、途中で落ちた記録はゼロです。

そして最後の行の25分後に、3本のジョブが1秒間隔で無効化されていました。ログが途切れた理由が、別のテーブルの更新時刻から読み取れます。

88行のログを分解する

まず全体を見ます。画面上のラベルは Data Snapshots Logs でした。

process で分けると3グループでした。DAILY_CDC_LOADING が52件、FIRST_DAY_SNAPSHOT が18件、TABLE_CREATION_OR_UPDATION が18件です。

source でも分けてみました。

CDCDataCollectorJob が52件、CDCFirstDaySnapshot が18件、TableCreator が18件。プロセスとソースが1対1で対応しています。どちらで数えても同じ結果になる作りです。

エラーが1件も無い

level を見ると、これが分かりやすい結果でした。

88件すべてが Information です。 Warning も Error も1件もありません。

失敗して止まったわけではない、と分かります。動いていたときは正常に動いていました。

エラーで止まった機能を調べるときは、まずここを見ます。Error が並んでいれば原因の手がかりになりますし、今回のように0件なら別の理由を探すことになります。

開始と完了がペアで揃っている

メッセージを完全一致で数えると13パターンありました。triggered と completed の組で並べます。

CDC events job for all changes は開始17件に対して完了17件。First Day Snapshot CDC Job は9件と9件でした。Daily CDC Job も同じく9件ずつ。Table creation/update は initiated が9件、completed が9件です。

4つとも差がゼロでした。 開始したのに完了していない記録は1つもありません。

ログを読むとき、この対応が崩れていれば異常です。今回は崩れていないので、落ちた形跡が無いと言い切れます。

処理時間はほぼゼロだった

完了メッセージには所要時間が入っていました。数字を拾うと、いちばん長いもので 0.006分。約0.36秒です。

25件は「0 minutes」と記録されていました。計測できないほど短いという意味でしょう。

対象が0件だから速い

理由はメッセージのなかにありました。Table creation/update task completed for 0 Analytics Sources という行が9件あります。

処理対象が0件です。集計元が1つも設定されていないので、走っても何もすることがありません。だから0秒で終わります。

前に調べたときも、この機能を有効にするには集計元テーブルの指定が要ると分かっていました。指定が無いまま、ジョブだけが動いていた状態です。

duration 列はほとんど空

duration というフィールドもありましたが、88件中9件にしか値が入っていません。値の範囲は3から13でした。

単位が何かは分かりません。79件が空なので、この列を当てにして分析するのは無理があります。時間はメッセージ本文から読むほうが確実でした。

列があるのに使われていない状態です。ログの設計としては、あとから足された列か、特定の条件でだけ埋まる列でしょう。空の多い列は分析の軸にしないという判断が要ります。

ログが止まった理由

いちばん知りたいのはここです。なぜ9時間で止まったのか。

毎時ちょうど10行

時刻の分布を見ると、規則性がはっきりしていました。

最初の17時台だけ8行で、18時台から01時台までは毎時ちょうど10行です。ジョブが定期的に動いていた証拠になります。

3本のジョブのうち2本が1時間おき、1本が30分おきでした。1時間あたりの実行回数を数えると、開始と完了で10行になる計算です。

最後の行から25分後

ログの最後の行は 2026-07-19 の 01:35:06 でした。TABLE_CREATION_OR_UPDATION の開始と完了が同じ秒に記録されています。

そこでジョブ側のレコードを見ました。

3件とも active が false です。更新時刻を確認すると、02:00:05、02:00:06、02:00:07 でした。

ログが途切れた25分後です。しかも1秒ずつずれています。

1秒間隔が意味すること

人が画面を開いて1件ずつ無効にすると、1秒では終わりません。チェックを外して保存し、次のレコードを開く。数十秒はかかります。

1秒間隔ということは、まとめて処理されたということです。 スクリプトか一括更新の操作だと考えられます。

更新者は3件とも admin でした。更新回数は2回、1回、2回と少ないので、何度も設定を変えた形跡もありません。

インスタンス構築の一連の処理のなかで、最後に止めた。そういう流れが見えてきます。

誰が何のために止めたかまでは追えません。ただ、9時間動かして対象が0件だと分かったなら、止めるのは妥当な判断です。動かし続けてもログが増えるだけになります。

3つのプロセスが何をしていたか

process の値から、それぞれの役割が読めます。

TABLE_CREATION_OR_UPDATION

18件のうち9件が「initiated」、9件が「completed」でした。完了メッセージには for 0 Analytics Sources が付いています。

集計元テーブルに対応する保存先を作る処理でしょう。集計元が0件なので、作るものがありません。

この処理が毎回0件で終わっているのが、機能が使われていない決定的な証拠でした。設定を1つも入れていない状態です。

FIRST_DAY_SNAPSHOT

こちらも18件で、9件ずつのペアです。ジョブ側の First snapshot に対応します。

説明では「セットアップ時に一度だけ動く」とされていた処理です。ところがログには9回記録されています。

対象が0件だと完了扱いにならず、毎時間やり直していたのだと考えられます。初回のデータが取れないので、いつまでも「初回」が終わりません。

メッセージには「Completed in 0 minutes」と出ています。完了はしているのに、次の時間にまた triggered が記録される。完了しても状態が進んでいない状態です。この繰り返しが9時間続きました。

DAILY_CDC_LOADING

52件でいちばん多い分類です。ここには2種類のジョブが混ざっていました。

Daily CDC Job が開始9件・完了9件。CDC events job for all changes が開始17件・完了17件。合計52件になります。

全変更のジョブは30分おきなので、9時間で17〜18回。1時間おきの2本より多く記録されるのは計算に合います。

30分おきという設定は、3本のなかでいちばん短い間隔です。変更を細かく拾うためでしょう。ただし対象が0件なら、細かく回しても拾うものがありません。実行回数がいちばん多いジョブが、いちばん無駄に動いていたことになります。

実行間隔の設定が、ログの件数にそのまま出ているのが確認できました。

ログの件数から実行回数を逆算する

毎時ちょうど10行という規則性は、3本の設定から説明が付きます。

1時間おきのジョブが2本で、開始と完了の2行ずつ。ここで4行です。30分おきのジョブが1本で、1時間に2回動くので4行。合わせて8行になります。

残る2行は TABLE_CREATION_OR_UPDATION でした。こちらも1時間に1回、開始と完了で2行です。

4 + 4 + 2 で10行。設定どおりに動いていたことが件数から裏付けられます。

最初の1時間だけ8行なのはなぜか

17時台だけ8行でした。2行足りません。

開始が17時台の途中だったので、30分おきのジョブが1回しか回らなかったのだと考えられます。切りのいい時刻から始まっていない状態です。

こうした端数は、ログを読むときによく出ます。中途半端な数字は開始時刻のずれを疑うと説明が付くことが多いと感じます。

定期実行の仕組みとの関係

このジョブは sysauto_dm_cdc_collector というテーブルに入っていました。名前の頭に sysauto が付きます。

ServiceNow の定期実行は sysauto 系のテーブルで管理されます。スクリプトを動かすもの、レポートを送るもの、インポートを走らせるもの。用途ごとにテーブルが分かれています。

定義と実行が2層になっている構造は定期実行（sysauto_script）：定義と実行キューの2層で扱いました。今回のジョブも同じ仕組みに乗っています。

実行キューには残っていない

定義側は3件とも残っていますが、無効なので実行キューには積まれません。

今回追えたのは、専用のログテーブルがあったからです。syslog_pa_dm に残っていなければ、9時間動いた事実そのものが分かりませんでした。

機能ごとに専用のログを持っているかどうかで、後から追える範囲が変わります。持っていない機能は、動いた記録が残りません。

イベント経由の処理とは別

ServiceNow にはイベントをキューに積んで処理する仕組みもあります。こちらはイベントはキューに積まれてから動く（sysevent）で扱いました。

定期実行とイベント駆動は別の経路です。今回のログは定期実行の側なので、イベントテーブルを見ても記録はありません。

どちらの仕組みで動くかを知らないと、探す場所を間違えます。

この88行から何を学べるか

小さなログですが、読み方の練習材料としてはよくできています。

ログの3要素を押さえる

どんなログでも、見るところは同じです。いつ・何が・どうなったかの3つ。

いつは sys_created_on。何がは process と source。どうなったかは level と message。この4つの列で判断できます。

今回は「7月18日から19日にかけて・3種類のジョブが・全部正常に完了した」と読めました。あとは、その先が無い理由を探す作業です。

件数の規則性を見る

毎時10行という規則が見えた時点で、設定どおり動いていたと判断できました。

規則が崩れているときのほうが情報量は多くなります。ある時間だけ件数が跳ね上がる、途中から半分になる。そういう変化は原因を示します。

まず規則を見つけて、崩れているところを探す。 ログを読む順番として使えます。

他のテーブルと時刻で結ぶ

今回いちばん効いたのがこれでした。ログの最終時刻と、ジョブの更新時刻。25分差で繋がりました。

同じ手が使える組み合わせは他にもあります。プロパティの変更日時、プラグインの操作日時、更新セットの適用日時。設定を変えた記録は、どこかに時刻付きで残ります。

システムプロパティがどこに置かれるかはシステムプロパティ（sys_properties）は設定値の置き場で扱いました。設定変更を追うとき、この2つを合わせて見ます。

新しく入った機能をどう評価するか

この調査で分かったのは、Data Snapshots がこの環境では使われていないという事実です。

3段階で見る

新機能が使える状態かどうかは、3段階で判断できます。

プラグインが有効か。ジョブが有効か。処理対象があるか。今回は1段目だけが真で、2段目と3段目が偽でした。

プラグインの有効・無効の見方はプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめています。1段目はここで確認できます。

「入っている」と「使える」の距離

プラグインが有効なら使えると考えがちですが、実際には距離があります。

今回のように、ジョブが止まっていれば動きません。動いていても、対象が0件なら結果は出ないでしょう。結果が出たとしても、それを見る画面が無ければ意味がありません。

段階が多いほど、どこかで止まっている可能性が高くなります。 新機能ほど、この確認が必要でした。

素の環境の状態を記録しておく

今回のログは、インスタンスが作られたときの記録です。構築の過程で何が動いて、何が止められたかが残っています。

この情報は時間が経つと消えます。ログの保持期間を過ぎれば削除されるためです。

導入直後にこうしたログを控えておくと、後から「最初はどうなっていたか」を確認できます。素の状態を知っていることが、比較の基準になります。

ログテーブルの名前から役割を読む

syslog_pa_dm という名前は、3つの部分に分かれています。

syslog はシステムログ。pa は Performance Analytics。dm はデータモデルでしょう。名前だけで、どの機能のどんなログかが分かる作りです。ジョブ側の sysauto_dm_cdc_collector にも dm が入っていて、同じ機能群だと名前から判別できます。

命名から探す

自分の環境で似たログを探すときも、この規則が使えます。syslog で始まるテーブルを一覧すれば、機能ごとのログが並びます。

機能名の略称が入っているので、探している機能の頭文字で絞り込めます。全部のログが1つのテーブルに入っているより、追いやすい構造です。

専用ログの利点と欠点

機能ごとにログを分けると、その機能だけを追うのが簡単になります。今回のように88行しかなければ、全部読めます。

一方で、機能をまたいだ調査は面倒になります。同じ時刻に何が起きていたかを知りたいとき、複数のテーブルを見る必要があります。

片方だけを見て結論を出さない。 今回もジョブ側のテーブルを見なければ、止まった理由に届きませんでした。

保持期間を確認しておく

ログは放っておくと消えます。保持期間の設定があるためです。

今回の88行は7月18日から19日のもので、調べたのは8月10日でした。3週間経っても残っています。

ただし今後も残る保証はありません。調べたい記録があるなら、消える前に控えておく必要があります。数字だけでも書き留めておけば、後から比較できます。

52件のうち、どのジョブが何件かはこの絞り込みで確認できます。1つのプロセス名に2種類のジョブが入っている構造が見えます。

用語

Data Snapshots：集計元テーブルの状態を定期的に取り込み、履歴としてためる仕組み。

CDC：Change Data Capture の略。変更された分だけを拾う方式。

Analytics Sources：集計の元になるテーブルの指定。この環境では0件だった。

triggered / completed：ジョブの開始と完了。ログにはこの2つが対で記録される。

Information / Warning / Error：ログの重大度。この88行はすべて Information。

実機を見て気づいたこと

ログが「無い」ことも情報になる

88行という数を見て、最初は少なすぎると思いました。運用が続いていればもっと溜まるはずです。

9時間で止まっているということは、その後動いていないという事実そのものです。ログの件数ではなく、最後の日時を見るべき場面でした。

システムログの溜まり方はシステムログ（syslog）の読み方と溜まり方でも扱いました。溜まり続けるものと、途切れるものがあります。途切れているなら理由があります。

25分の差が答えを教えてくれた

ログの最終時刻とジョブの更新時刻を並べたとき、これは繋がっていると分かりました。

片方だけ見ていたら、「9時間で止まった」で終わっていたはずです。別のテーブルの時刻と突き合わせると、止まった理由まで届きます。

調査で時刻が出てきたら、他のテーブルの時刻と並べてみる。今回はそれで25分差という関係が見つかりました。

「エラーが無い」は良いことばかりではない

88行すべて Information で、失敗が1件もありません。安定して動いていたように見えます。

ただし処理対象は0件でした。何もしていないから失敗しようがないとも読めます。

正常に完了しているログが並んでいても、中身を見ないと判断できません。for 0 Analytics Sources という一言が無ければ、順調に動いていたと誤解するところでした。

実務では何に使えるか

機能が使われているかを調べる手順

新しい機能が実際に動いているかを確認したいとき、順番があります。

まず設定側を見ます。ジョブが有効かどうか、プラグインが入っているかどうか。ここが無効なら、そこで終わりです。

次にログを見ます。過去に動いた記録があるか。最後の実行がいつか。有効でも、対象が無ければ実質動いていません。

最後に処理対象を確認します。今回のように「0件」と記録されていれば、走っていても意味がありません。

定義があることと動いていることを分ける考え方はServiceNowのスケジュールジョブは本当に動いている？でも扱いました。同じ切り分けがここでも効きます。

止まった時期を特定する

ログの最終日時は、いつから使われていないかを示します。

そこから前後の変更を探すと、原因が見つかります。ジョブの sys_updated_on、プロパティの変更日、プラグインの操作履歴。時刻で突き合わせる方法です。

変更の記録がどこに残るかはServiceNowの変更履歴はどこに残る？にまとめました。設定変更の追跡と組み合わせると、原因にたどり着けます。

この機能を使うなら何から始めるか

Data Snapshots を実際に使うつもりなら、順番が決まっています。

集計元を指定するのが先です。ログにあった「0 Analytics Sources」を1件以上にしない限り、ジョブを有効にしても何も起きません。

そのうえで3本のジョブを有効化します。初回スナップショットで下地を作り、日次と全変更で更新していく流れです。

インジケータの設計そのものはServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順を参照してください。何を測るかが決まっていないと、集計元も決まりません。

自分の環境で確認するときのURL

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

• ログをプロセス別に見る：/syslog_pa_dm_list.do?sysparm_query=GROUPBYprocess

• ログをレベル別に見る：/syslog_pa_dm_list.do?sysparm_query=GROUPBYlevel

• ログを新しい順に見る：/syslog_pa_dm_list.do?sysparm_query=ORDERBYDESCsys_created_on

• 収集ジョブの一覧：/sysauto_dm_cdc_collector_list.do

• 定期実行の一覧：/sysauto_script_list.do

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-10 に確認しました。件数と日時はこの環境の実測値です。

確認していないことがあります。ジョブを有効化していません。集計元も設定していないので、動かしたときに何が記録されるかは分かりません。

無効化を誰が何のためにやったかも、記録からは追えません。1秒間隔という事実から一括処理だと推測しましたが、確認したわけではありません。

duration 列に9件しか値が入っていない理由も不明です。単位も分かりません。

このログには context_map という列があり、そこにインスタンスを特定できる情報が含まれています。記事にも画面にも載せていません。自分の環境で開くときは、画面共有や資料への貼り付けに注意してください。

ログの保持期間も確認していません。古い行が削除されている可能性は残ります。ただし最初の行から連続して記録されているので、この88行が全部だと考えています。

関連記事

• システムログ（syslog）の読み方と溜まり方 — ログの基本的な追い方

• ServiceNowのスケジュールジョブは本当に動いている？ — 定義と実行を分けて見る方法

• ServiceNowのPerformance Analyticsは何を測る？ 指標設計を5つのテーブルで決める手順 — この仕組みの目的