タイムスタンプ、タイム ゾーン、時間範囲、および日付フォーマット
Sumo Logic では、タイムスタンプ、タイム ゾーン、時間範囲、日付について複数のオプションがサポートされています。ログ データを収集するときは、アカウント内のデータの整合性と、クエリ結果の正確さの両方を維持するために、メッセージに付けられたタイムスタンプが非常に重要です。タイムスタンプのこの重要性により、Sumo Logic では各メッセージのタイムスタンプがインデックス化され、クエリの時間範囲に関連するデータが、検索結果で正しく返されます。これにより、正しいイベントの時系列を再現できます。
タイムスタンプ
タイムスタンプは、イベントが発生した時刻を示すログ メッセージの一部です。取り込み中に、メッセージのタイムスタンプを検出し、それを Unix エポック時間 (UTC 1970 年 1 月 1 日午前 0 時からのミリ秒数) に変換してインデックスを付けることができます。タイムスタンプは、デフォルトのタイムスタンプ parse 設定、または指定したカスタム形式 (タイム ゾーンを含む) を使用して parse されます。
Source を設定するときは、デフォルトのタイムスタンプ parse 設定を使用するか、またはログ メッセージのタイムスタンプを parse するためのカスタム形式を指定するかを選択できます。タイムスタンプの parse を有効にするオプションはデフォルトで選択されています。オフにすると、タイムスタンプ情報は parse されません。代わりに、メッセージが処理された時刻でログにスタンプが付けられます。
タイムスタンプの考慮事項
デフォルトでは、ログ メッセージのタイムスタンプが自動的に検出されます。自動検出では、一般的な形式のタイムスタンプが識別され、メッセージで先に表示されるタイムスタンプが優先されます。
Source からのログ メッセージに複数のタイムスタンプがある場合、異常な形式のタイムスタンプがある場合、または異なるタイムスタンプの形式が混在している場合には、次の 2 つの選択肢があります。
- ログ形式ごとに Source を設定する
- Source のカスタム タイムスタンプ形式を設定する
Collector では、特定の Source から送信されたすべてのログ メッセージが、互いに近接するタイムスタンプであると想定されます。Collector を介して送られるメッセージが、Source からの最近のメッセージよりも 1 日以上前または後に表示される場合は、現在の時刻と一致するように自動修正されます。この自動修正は、Source 上でカスタム タイムスタンプ形式を明示的に設定することによって停止できます。
Collector はまた、特定の Source から提供されるすべてのログ メッセージのタイムスタンプが、現在の時間と比較して -1 年から +2 日の範囲内になると仮定します。parse されたタイムスタンプがこの範囲から外れたログ メッセージは、自動的に現在の時刻で再スタンプされます。この自動修正動作を調整するには、Sumo Logic のサポートに連絡する必要があります。詳細については、古いデータや過去のデータを取り込む方法について参照してください。
タイムスタンプの parse の自動化
Sumo は自動的に以下のタイムスタンプ フォーマットのいずれかを parse できます。ログ メッセージで複数の有効なタイムスタンプが検出された場合、通常は、メッセージの " 一番左 " に表示されるタイムスタンプが選択されます。
タイムスタンプの形式 | 例 |
yyyy-MM-dd'T'HH:mm:ss*SSSZZZZ | 2018-08-20'T'13:20:10*633+0000 |
yyyy MMM dd HH:mm:ss.SSS zzz | 2017 Mar 03 05:12:41.211 PDT |
MMM dd HH:mm:ss ZZZZ yyyy | Jan 21 18:20:11 +0000 2017 |
dd/MMM/yyyy:HH:mm:ss ZZZZ | 19/Apr/2017:06:36:15 -0700 |
MMM dd, yyyy hh:mm:ss a | Dec 2, 2017 2:39:58 AM |
MMM dd yyyy HH:mm:ss | Jun 09 2018 15:28:14 |
MMM dd HH:mm:ss yyyy | Apr 20 00:00:35 2010 |
MMM dd HH:mm:ss ZZZZ | Sep 28 19:00:00 +0000 |
MMM dd HH:mm:ss | Mar 16 08:12:04 |
yyyy-MM-dd'T'HH:mm:ssZZZZ | 2017-10-14T22:11:20+0000 |
yyyy-MM-dd'T'HH:mm:ss.SSS'Z' | 2017-07-01T14:59:55.711'+0000' 2017-07-01T14:59:55.711Z |
yyyy-MM-dd HH:mm:ss ZZZZ | 2017-08-19 12:17:55 -0400 |
yyyy-MM-dd HH:mm:ssZZZZ | 2017-08-19 12:17:55-0400 |
yyyy-MM-dd HH:mm:ss,SSS | 2017-06-26 02:31:29,573 |
yyyy/MM/dd*HH:mm:ss | 2017/04/12*19:37:50 |
yyyy MMM dd HH:mm:ss.SSS*zzz | 2018 Apr 13 22:08:13.211*PDT |
yyyy MMM dd HH:mm:ss.SSS | 2017 Mar 10 01:44:20.392 |
yyyy-MM-dd HH:mm:ss,SSSZZZZ | 2017-03-10 14:30:12,655+0000 |
yyyy-MM-dd HH:mm:ss.SSS | 2018-02-27 15:35:20.311 |
yyyy-MM-dd HH:mm:ss.SSSZZZZ | 2017-03-12 13:11:34.222-0700 |
yyyy-MM-dd'T'HH:mm:ss.SSS | 2017-07-22'T'16:28:55.444 |
yyyy-MM-dd'T'HH:mm:ss | 2017-09-08'T'03:13:10 |
yyyy-MM-dd'T'HH:mm:ss'Z' | 2017-03-12'T'17:56:22'-0700' |
yyyy-MM-dd'T'HH:mm:ss.SSS | 2017-11-22'T'10:10:15.455 |
yyyy-MM-dd'T'HH:mm:ss | 2017-02-11'T'18:31:44 |
yyyy-MM-dd*HH:mm:ss:SSS | 2017-10-30*02:47:33:899 |
yyyy-MM-dd*HH:mm:ss | 2017-07-04*13:23:55 |
yy-MM-dd HH:mm:ss,SSS ZZZZ | 11-02-11 16:47:35,985 +0000 |
yy-MM-dd HH:mm:ss,SSS | 10-06-26 02:31:29,573 |
yy-MM-dd HH:mm:ss | 10-04-19 12:00:17 |
yy/MM/dd HH:mm:ss | 06/01/22 04:11:05 |
yyMMdd HH:mm:ss | 150423 11:42:35 |
yyyyMMdd HH:mm:ss.SSS | 20150423 11:42:35.173 |
MM/dd/yy*HH:mm:ss | 08/10/11*13:33:56 |
MM/dd/yyyy*HH:mm:ss | 11/22/2017*05:13:11 |
MM/dd/yyyy*HH:mm:ss*SSS | 05/09/2017*08:22:14*612 |
MM/dd/yy HH:mm:ss ZZZZ | 04/23/17 04:34:22 +0000 |
MM/dd/yyyy HH:mm:ss ZZZZ | 10/03/2017 07:29:46 -0700 |
HH:mm:ss | 11:42:35 |
HH:mm:ss.SSS | 11:42:35.173 |
HH:mm:ss,SSS | 11:42:35,173 |
dd/MMM HH:mm:ss,SSS | 23/Apr 11:42:35,173 |
dd/MMM/yyyy:HH:mm:ss | 23/Apr/2017:11:42:35 |
dd/MMM/yyyy HH:mm:ss | 23/Apr/2017 11:42:35 |
dd-MMM-yyyy HH:mm:ss | 23-Apr-2017 11:42:35 |
dd-MMM-yyyy HH:mm:ss.SSS | 23-Apr-2017 11:42:35.883 |
dd MMM yyyy HH:mm:ss | 23 Apr 2017 11:42:35 |
dd MMM yyyy HH:mm:ss*SSS | 23 Apr 2017 10:32:35*311 |
MMdd_HH:mm:ss | 0423_11:42:35 |
MMdd_HH:mm:ss.SSS | 0423_11:42:35.883 |
MM/dd/yyyy hh:mm:ss a:SSS | 8/5/2011 3:31:18 AM:234 |
MM/dd/yyyy hh:mm:ss a | 9/28/2011 2:23:15 PM |
Unix エポック タイムスタンプ
Unix エポック タイムスタンプは、次の形式でサポートされています。
- 大かっこで囲まれた (またはその後にコンマが続く) 10 桁のエポック タイム形式。メッセージの先頭は、数桁の数字でなければなりません。たとえば、[1234567890] または [1234567890, (その他)] の後にメッセージの残りの部分が続きます。
- 13 桁のエポック時間。メッセージの先頭は、13 桁の数字でなければなりません。たとえば、1234567890123... の後にメッセージの残りの部分が続きます。
- 16 桁のエポック時間。メッセージの先頭は、16 桁の数字でなければなりません。たとえば、1234567890123... の後にメッセージの残りの部分が続きます。
- 19 桁のエポック時間。メッセージの先頭は、19 桁の数字でなければなりません。たとえば、1496756806.655123456…. の後にメッセージの残りの部分が続きます。
- Akamai のログ配信サービスの時刻形式も認識されます。この形式は 13 桁で、最後の 3 (ms) 桁の前にピリオドがあります (1234567890.123)。
- メッセージの先頭から 5 番目の値が 10 桁のエポック時間であるコンマ区切りの値。たとえば、フィールド 1、フィールド 2、フィールド 3、フィールド 4、1234567890
- "timestamp" という名前の JSON 形式のプロパティ。その後に、13 桁のエポック時間が続きます。たとえば、"timestamp":"123456789013"。
- Cisco Fortigate/Meraki ログ メッセージ形式:
<134>1 1439277406.903768018 Store_020026 flows src=<redact> dst=72.245.34.184 protocol=udp sport=62118 dport=53 pattern: 1 all
- Linux 監査メッセージ形式:
type=PATH msg=audit(1439992022.365:83931889): item=0 name="/usr/sbin/ss" inode=91193416 dev=08:02 mode=0100755 ouid=0 ogid=0 rdev=00:00
カスタム タイムスタンプ形式の指定
Sumo ではほとんどのタイムスタンプが問題なく自動的に parse されますが、タイムスタンプの parse に問題がある場合は手動で parse の形式を指定できます。新しい Source を設定する場合と、既存の Source のタイムスタンプ情報を編集する場合の手順は同じです。
カスタムの形式を指定するときは、タイムスタンプ形式と、必要に応じてログ行の形式で目的のタイムスタンプを見つけるための正規表現を指定します。ロケータを指定しない場合は、デフォルトの特定の形式と一致するタイムスタンプについてログ メッセージ全体がスキャンされます。サンプルのログ行をいくつかテストして、新しい形式を parse できるかどうかを確認することもできます。
複数のカスタム形式を指定するときは、最初に最も一般的な形式を指定します。Sumo は、指定された順序で各カスタム形式を処理します。タイムスタンプが特定されると、以降のタイムスタンプ チェックは実行されません。
カスタム フォーマットに一致するタイムスタンプが特定されない場合、Sumo は依然としてログのタイムスタンプを自動的に特定することを試みます。
Source のタイムスタンプ形式を手動で指定するには、次の手順を実行します。
- 次のいずれかを実行します。
- 新しい Source を設定する場合は、手順 2 に進みます。
- 既存の Source のタイムスタンプ設定を編集するには、[Manage Data (データの管理)] > [Collection (コレクション)] > [Collection (コレクション)] の順にクリックします。次に、Source 名の右側にある [Edit (編集)] をクリックして、手順 2 に進みます。
- [Advanced (詳細設定)] をクリックします (詳細設定がまだ表示されていない場合)。
- [Timestamp Format (タイムスタンプ形式)] で、[Specify a format (形式を指定)] を選択します。
- [Format (形式)] フィールドに、Sumo Logic によるログ内のタイムスタンプの parse に使用するタイムスタンプ形式を入力します。タイムスタンプの形式がエポック タイムの場合は、[Format (形式)] フィールドに「epoch」と入力します。カスタム タイムスタンプ形式は、サポートされるタイムスタンプの表記規則に従う必要があります。
- [Timestamp locator (タイムスタンプ ロケータ)] フィールドは、16 桁のエポックまたは 19 桁のエポックのタイムスタンプに対して必須です。それら以外の場合、このフィールドは省略可能です。指定された形式がいずれも一致しない場合、自動的にメッセージのタイムスタンプが決定されます。
タイムスタンプ ロケータは、以下の条件を満たす必要があります。- 有効な Java 正規表現を使用すること。そうでない場合は、次のエラー メッセージが表示されます。
Unable to validate timestamp formats. The timestamp locator regex your-regex is invalid. The timestamp locator regex your-regex uses matching features which are not supported.
- RE2 準拠の正規表現を使用すること。例:
\[time=(.*?)\].
そうでない場合は、次のエラー メッセージが表示されます。
Unable to validate timestamp formats. The timestamp locator regex your-regex uses matching features which are not supported.
- 名前のないキャプチャ グループを 1 つ含むこと。タイムスタンプを抽出するときは、このグループによってキャプチャされた各ログ メッセージの一部分だけをスキャンします。ログ メッセージがロケータの式と一致しない場合は、タイムスタンプ形式をそのメッセージに適用することはできません。正規表現に名前のないキャプチャ グループが 1 つも含まれていない場合は、次のエラー メッセージが表示されます。
Unable to validate timestamp formats. The timestamp locator regex your-regex does not contain a single unnamed capture group. The timestamp locator regex your-regex uses matching features which are not supported
- 有効な Java 正規表現を使用すること。そうでない場合は、次のエラー メッセージが表示されます。
- 追加するカスタム タイムスタンプ形式が複数ある場合は、[Add (追加)] をクリックします。
- すべてのカスタム タイムスタンプ形式を入力したら、[Test (テスト)] をクリックします。タイムスタンプ ロケータに有効な正規表現を入力した場合は、[Test Timestamp Parsing (タイムスタンプの parse のテスト)] ページが表示されます。サンプル ログ メッセージを入力して、抽出されるタイムスタンプ形式をテストします。
- [Test (テスト)] をクリックします。parse されたタイムスタンプと、形式の一致 (存在する場合) を含む結果が表示されます。
次のいずれかのメッセージが表示されます。- Format matched (形式が一致しました)。 この例では、yyyy/MM/dd HH:mm:ss の形式が一致し、緑色で強調表示されます。これは 1 番目の形式なので、1(形式: yyyy/MM/dd HH:mm:ss ロケータ: \[time=(.*?)\]) として返されます。[Effective message time (有効メッセージ時間)] は、2017-01-15 02:12.000 +0000 となります。
- None of the custom timestamp format was matched (どのカスタム タイムスタンプ形式も一致しませんでした)。 カスタム フォーマットはログで検出されませんでしたが、それでも自動検出された使用可能なタイムスタンプの 2017-06-01 02:12:12.259667 がオレンジ色で強調表示されています。[Effective message time (有効メッセージ時間)] は、2017-06-01 02:12:12.259 +0000 となります。
- Unable to parse any timestamp (タイムスタンプを parse できません)。サンプルのログ行の "This line shouldn't parse (この行は parse されません)" の部分には parse 可能なタイムスタンプがないため、タイムスタンプは現在の時刻になります。
- 省略可能。ログ行を変更する場合は、[Edit (編集)] をクリックして、テストする別のログ行を指定できます。
- [Done (完了)] をクリックして [Test Timestamp Parsing (タイムスタンプ parse のテスト)] を終了します。
- [Save (保存)] をクリックしてカスタム タイムスタンプ形式を保存します。
トラブルシューティングのための _format の使用
タイムスタンプがログ ファイルからどのように parse されるかを確認するには、_format を使用します。
_format の結果のフィールドは次のとおりです。
t:<parse type>,o:<offset>,l:<length>,p:<date_format>
<parse type> は、次の値を取ります。
- fail—タイムスタンプの検出に失敗。
- cache—成功、キャッシュされた形式。
- def—成功、デフォルト (ユーザ指定) の形式。
- full—成功、パターンのライブラリに対する " 完全 " な parse。
- none—ローカル/受信時間、この Source に対してタイムスタンプの parse が有効になっていないため。
- ac1—" ウィンドウ ベース " のヒューリスティックによって自動修正 (Sumo では現在 " 自動修正 " という名称を使用しています)。Sumo Logic では、特定の Source に含まれるすべてのログ メッセージには、近接しているタイムスタンプが含まれると想定します。メッセージが届いたのが、その Source に含まれる最近のメッセージより 2 日以上前または後だと思われる場合、メッセージは現在の時刻に合うように自動修正されます。この自動修正は、Source 上でカスタム タイムスタンプ形式を明示的に設定することによって停止できます。
- たとえば、Sumo が "Dec 2, 2017 2:39:58 AM" のタイムスタンプを parse するとします。Source から以前に受信したメッセージに "Dec 1, 2017 2:39:58 AM" より前または "Dec 3, 2017 2:39:58 AM" より後のタイムスタンプがある場合、Sumo によってタイムスタンプが現在の時刻に自動修正されます。
- ac2— -1y、+2d のヒューリスティックによって自動修正されます。Sumo Logic は、特定の Source から提供されるすべてのログ メッセージのタイムスタンプが、現在の時間と比較して -1 年から +2 日の範囲内になると仮定します。parse されたタイムスタンプがこの範囲から外れたログ メッセージは、自動的に現在の時刻で再スタンプされます。
- たとえば、Sumo が "Dec 2, 2017 2:39:58 AM" のタイムスタンプを parse するとします。Source から以前に受信したメッセージに "Dec 1, 2016 2:39:58 AM" より前または "Dec 4, 2017 2:39:58 AM" より後のタイムスタンプがある場合、Sumo によってタイムスタンプが現在の時刻に自動修正されます。
例
タイムスタンプに関する問題のトラブルシューティングを行っている場合は、次のようなクエリを実行してタイムスタンプの parse 方法を確認できます。
_sourceCategory=PaloAltoNetworks
| _format as timestampformat
結果は次のようになります。
メッセージ時間と受信時間に大きな差がある場合
メッセージ時間と受信時間の不一致に関するトラブルシューティングを参照してください。
タイムスタンプの表記規則
次の表記規則はトークンとしてサポートされており、カスタム タイムスタンプ形式で使用できます。
トークン | 日付または時間要素 | 例 |
yyyy | 4 桁の年 | 2012; 2016 |
yy | 2 桁の年 | 12; 16 |
MMM | 3 文字の月 | Jan; Mar; Dec |
MM | 1 または 2 桁の月 (年中の値) | 1; 01; 9; 09; 12 |
dd | 1 または 2 桁の日 (月中の値) | 1; 01; 16; 30 |
a | AM/PM (大文字小文字が区別されます) | AM; PM; am; pm |
HH | 1 または 2 桁の時間 (1 日中の 0 ~ 23) | 2; 02; 14; 23 |
hh | 1 または 2 桁の時間 (1 日中の AM/PM と 1 ~ 12) | 2; 02; 11; 12 |
mm | 1 または 2 桁の分 (1 時間内の値) | 8; 08; 55 |
ss | 1 または 2 桁の秒 (1 分内の値) | 5; 05; 35 |
SSS | 1 ~ 3 桁の 1 秒未満から 1000 分の 1 秒の時間 (小数点数) | 4; 58; 944 |
zzz | 3 文字のタイム ゾーン | UTC; PST; EDT |
ZZZZ | RFC 822 のタイム ゾーン | -0900; +0500 |
'Z' | Z の文字 | Z |
'T' | T の文字 | T |
epoch | 10、13、16、19 桁のタイムスタンプと、省略可能な 10 桁後の . (ピリオド)。 | 1496756806.655123456 |
タイム ゾーン
Source を設定するときは、次のいずれかのオプションを選択できます。
- ログ ファイルに存在するタイム ゾーンを使用し、次に、タイム ゾーン情報がログ メッセージにない場合のオプションを選択します。
- 特定のタイム ゾーンを強制することができ、この場合ログ内にあるタイム ゾーン情報は完全に無視されます。
どのオプションを選択した場合も、適切なタイムゾーンを設定することが重要です。ログのタイム ゾーンを特定できない場合は、UTC のスタンプが付けられます。
タイム ゾーンの考慮事項
タイム ゾーンについては、次の事項について考慮する必要があります。
- タイム ゾーンはすべての Source に明示的に設定することを強くお勧めします。Sumo Logic では、常に Source のタイム ゾーンの判定が試行されます。ただし、判定が可能でない場合は、タイム ゾーンが UTC に戻されます。この場合、タイム ゾーンが不正確になり、フォレンジック分析およびレポートに大きな影響を与える可能性があります。
- Sumo Logic で、利用可能な ISO 8601 タイム ゾーンがすべてサポートされているわけではありません。たとえば、-00 はサポートされていません。したがって、この形式で記述されたタイム ゾーンをシステムが検出することはありません。それらのサポートされていない形式の場合は、サービスによって検出されない場合に使用する適切なデフォルトのタイムゾーンを指定する必要があります。
UTC オフセットのリストについてはこの Wikipedia の記事を、タイム ゾーン コードのリストについてはこの Wikipedia の記事を参照してください。
デフォルトのタイム ゾーン
デフォルトでは、オペレーティング システムによって設定された Web ブラウザのタイム ゾーンを使用して、ユーザ インターフェイスの任意の場所に時間と分を表示できます。[Preferences (環境設定)] ページの [Default Timezone (デフォルトのタイムゾーン)] 設定を調整することで、ユーザ インターフェイスに表示されるデフォルトのタイム ゾーンを変更できます。このオプションは、Web ブラウザのタイム ゾーンを上書きし、UI に表示される時間と分の表示方法を変更します。ただし、これは個人用の設定で、組織内の他のどのユーザのタイム ゾーンも変更されません。
この設定の影響を受ける UI 要素には、[Search (検索)] ページの [Time Range (時間範囲)] フィールド、[Messages (メッセージ)] ペインの [Time (時間)] 列、[Dashboards (ダッシュボード)]、および [Anomaly Detection (異常検出)] があります。
[Default Timezone (デフォルトのタイムゾーン)] の設定を変更すると、UI のメッセージ表示方法に影響しますが、ログ メッセージの実際のタイムスタンプには影響しません。
たとえば、次のスクリーンショットは、UI の [Time (時間)] 列が PST (米国太平洋標準時国) に設定されたタイムゾーンを示しています。ログは、同じ PST タイム ゾーンを使用するように設定されたシステムから収集されたもので、PST タイム ゾーンが [Message (メッセージ)] 列のタイムスタンプに表示されています。両方の列のタイムスタンプは、同じタイム ゾーンに設定されているため一致します。
次のスクリーンショットは、[Default Timezone (デフォルトのタイムゾーン)] 設定を UTC に変更した後の同じ検索結果を示しています。[Time (時間)] 列が UTC で表示されるようになり、一方で [Message (メッセージ)] 列は元の PST のタイムスタンプのままです。
次の例では、自分のタイム ゾーンが UTC に設定されていて、タイム ゾーンが PST に設定されている他のユーザとダッシュボードを共有する場合について考えます。それぞれのダッシュボードはどのような表示になるでしょうか。
同じデータが、単純にカスタム設定のタイム ゾーンでそれぞれ表示されます。たとえば、時系列を使用するパネルがある場合、グラフの X 軸の時間は UTC のタイム ゾーンで表示されます。他のユーザのグラフに表示される X 軸の時間は、PST のタイム ゾーンで表示されます。ただし、グラフに表示されるデータはまったく同じものです。
時間範囲
[Search (検索)] ページの [Time Range (時間範囲)] フィールドには、Sumo Logic のユーザ インターフェイスに設定されているタイム ゾーンが使用されます。これは、オペレーティング システムで設定され、Web ブラウザで使用されるデフォルトのタイム ゾーンか、[Preferences (環境設定)] ページの [Default Timezone (デフォルトのタイムゾーン)] 設定 (このオプションを設定している場合) のいずれかになります。
[Scheduled Search (Scheduled Search)] または [Real Time Alert (リアル タイム アラート)] を作成したとき、保存した検索の時間範囲には、Sumo Logic のユーザ インターフェイスに設定されているタイム ゾーンが使用されます。[Default Timezone (デフォルトのタイムゾーン)] 設定を使用してタイム ゾーンを変更した場合、このタイム ゾーンは Scheduled Search およびリアル タイム アラートに使用されます。
[Default Timezone (デフォルトのタイムゾーン)] 設定によって、既存の [Scheduled Search (Scheduled Search)] や [Real Time Alert (リアル タイム アラート)] の設定が自動的に更新されることはありません。したがって、Scheduled Search とリアル タイム アラートでユーザ インターフェイスと同じタイム ゾーンを使用する場合は、それらを編集して同じタイム ゾーンになるように設定してから保存する必要があります。
時間範囲の詳細については、検索の時間範囲の設定についての説明を参照してください。
検索の時間範囲では、すべてのデータを任意のタイムスタンプまたはすべてのタイムスタンプで検索できます。詳細については、「受信時間の使用」を参照してください。
日付形式
Sumo Logic へのアクセスに使用されているブラウザが、月/日/年の形式ではなく、日/月/年の形式を使用する地域にある場合、日付がその形式で表示されます。