通常、Sumo Logic 内のログ メッセージのメッセージ時間と受信時間は同じです。ただし、ネットワーク遅延、データ量のランダムな一時的増加、およびサービスの中断により遅延が発生し、その結果、メッセージ時間と受信時間に差異が発生する可能性があります。差異が大きいと、不正確なイベントが表示され、検索のパフォーマンス問題が発生することもあります。また場合によっては、ダッシュボードにデータを入力できなくなる可能性もあります。

このページでは、時間差異が生じうる要素について説明し、問題をトラブルシューティングする解決策を示します。リンクをクリックして、トピックに移動してください。

メッセージ時間と受信時間

  • メッセージ時間は、当社のサービスによって parse されたログ イベントの時間を表します。Source を Collector に追加する際、大部分の顧客は、自動でログ内のタイムスタンプを検出し、[Enable Timestamp Parsing (タイムスタンプの parse の有効化)] オプションを選択してタイムスタンプを parse することを選びます。

    TimeZone_EnableTimestampParsing.png
  • 受信時間は、ログ メッセージが Sumo Logic レシーバに到達する際のタイムスタンプです。詳細は、「受信時間の使用」を参照してください。

タイム ゾーンの設定

時間差異が大きくなるのは、通常、Collector のセットアップ プロセス時に Source に指定したタイム ゾーンの設定が関係しています。データ ソースに設定されたタイム ゾーンが不正確な場合、メッセージ時間と受信時間の差異が発生する可能性があります。

Collector の Source にタイム ゾーンを設定する際は、細心の注意を払ってください。Source を Collector に追加し、[Advanced Options for Logs (ログの詳細オプション)] を展開すると、次のダイアログが表示されます。

TimeZone_AdvancedOptionsforLogs2.png

最初のオプションの選択は、以下に示すように、タイム ゾーンがメッセージ タイムスタンプに含まれること、そしてサポート対象の Java SimpleDateFormat であることを前提としています。

文字 日付または時間要素
z タイム ゾーン (一般的なタイム ゾーン) Pacific Standard; PST; GMT-08:00
Z タイム ゾーン (RFC 822 タイム ゾーン) -0800


メッセージにタイム ゾーンが含まれていないか、タイム ゾーンの形式がサポートされていない場合、Sumo Logic は選択されたフォールバック オプションを使用して、適切なオフセットをメッセージ時間に適用します。

タイム ゾーン設定で発生する可能性のある問題

次のシナリオは、Sumo ユーザにとって一般的なタイム ゾーン関連の設定問題を示しています。これらの使用事例を確認して、タイム ゾーンの設定で発生する可能性のある問題を把握してください。

例 1 - ファイル内のタイム ゾーン形式がサポートされていない

Source のタイム ゾーンの選択: UTC
サンプル メッセージのタイムスタンプ: Sep 28 19:00:00 US/Pacific

このシナリオの "US/Pacific" は有効なタイム ゾーン形式ではありません。そのため Sumo Logic では GMT-08:00 を使用しないで、UTC タイム ゾーンを適用します。またこの不一致により、ユーザが「過去 15 分間」の検索を実行した場合、取得されるイベントは不正確になります。

例 2 - タイムゾーン設定が不適切

Source のタイム ゾーンの選択: 未選択 (UI に「Select a Time Zone (タイム ゾーンを選択してください)」が表示される)
サンプル メッセージのタイムスタンプ: Sep 28 19:00:00

このシナリオでは、サンプル メッセージの中にタイム ゾーンがありません。ただしログを取得するサーバはロサンゼルスにあるため、想定されるタイムゾーンは GMT-08:00 になります。実際には Source に対してタイム ゾーン オプションが選択されていないため、Sumo Logic はデフォルトの UTC タイム ゾーンをこれらのメッセージに適用します。ここでも最初の例と同様に、ユーザが「過去 15 分間」の検索を実行した場合、取得されるイベントは不正確になります。

不適切なタイム ゾーン設定のトラブルシューティング

取り込み中 (データ取得中) に明らかな遅延が発生している場合は、タイム ピッカーの [Use Receipt Time (受信時間の使用)] チェック ボックスをオンにします。これにより、Sumo によって受信された順番にデータが表示されるほか、検出/適用されたタイムスタンプが表示されます。

UseReceiptTime_chekcbox.png

2 つの値に差異がある場合、特に以下の例のように、差異が (ほぼ) 倍の時間になる場合、タイム ゾーンの設定ミスの可能性があります。

TimeDiscrepancy.png

タイム ゾーンの設定を確認し、送信側アプリケーションのものであるタイム ゾーンを Source に適用します。たとえばアプリケーションが UTC タイムスタンプでイベントを送信している場合、Source 設定で UTC タイムスタンプを指定できます。

TimeZone_AdvancedOptions.png

タイムスタンプの差分の検出

アカウントで以下のクエリを実行して、Source ごとに、受信時間とメッセージ時間が 30 分以上離れているメッセージ数を確認できます。少なくともこの確認作業は、さらに分析を実行するための良い出発点になるはずです。

*
| _receiptTime as r
| _messageTime as t
| t - r as d
| toInt(d) as i
| abs(i) as i
| 30 as minutes
| minutes * 60 * 1000 as milliseconds
| where i > milliseconds
| formatDate(fromMillis(r),"MM/dd hh:mm") as r
| formatDate(fromMillis(t),"MM/dd hh:mm") as t
| count by _collector, _source
| order by _count


前の検索で (問題のある) Source の一覧を確認した後、以下のクエリを使用して、各 Source の平均遅延時間、最大遅延時間、最小遅延時間を表示できます。<problem_child> は、上記の最初のクエリで見つかった Source に置き換えてください。  
 

_source=<problem_child>
| _format as format
| formatDate(fromMillis(_receipttime),"MM/dd hh:mm") as r
| formatDate(fromMillis(_messagetime),"MM/dd hh:mm") as t
| abs(_receipttime - _messagetime) as delt| delt/1000/60 as delt
| min(delt), max(delt), avg(delt), stddev(delt), count(*) by _collector, _sourcename


平均遅延、最大遅延、最小遅延の値が非常に近接している場合、時間差異は、ほぼ間違いなくタイム ゾーン設定が正しくないために発生しています。元に戻り、Source 設定がログ メッセージと正しく適合していることを確認してください。未処理メッセージのタブに切り替えると、タイムスタンプがファイルから parse された方法が [format (形式)] フィールドに表示されます。