<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Zoom logs and Timestamps in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Zoom-logs-and-Timestamps/m-p/514180#M87145</link>
    <description>&lt;P&gt;Looking at Zoom log timestamps... I'm trying to figure out timestamps (and accuracy of _time).&lt;/P&gt;&lt;P&gt;The Zoom 'add-on' scene is a little confusing: There is the "Splunk Connect for Zoom" app (&lt;A href="https://splunkbase.splunk.com/app/4961/" target="_blank" rel="noopener"&gt;https://splunkbase.splunk.com/app/4961/&lt;/A&gt;)&amp;nbsp; which is listed as an 'add-on', but it has no timestamp recognition config (no props.conf at all).&amp;nbsp;&lt;/P&gt;&lt;P&gt;Looking at&amp;nbsp;Splunk Add-on for RWI - Executive Dashboard (&lt;A href="https://splunkbase.splunk.com/app/5063/" target="_blank" rel="noopener"&gt;https://splunkbase.splunk.com/app/5063/&lt;/A&gt;) - this *does* have a props.conf and zoom-specific configurations... but... the only thing related to timestamps are some search-time field extractions. No timestamp recognition configs. The search-time extractions are date-time strings, not epoch-time values... and are not exhaustive.&amp;nbsp; (See SPL below for analysis / comparison of timestamp values -- including these extracted fields.)&lt;/P&gt;&lt;P&gt;I'm seeing that timestamp=none is getting assigned to every event, so that means timestamp recognition is being attempted and, presumably, failing. Which suggests that the _time value (when recognition fails) is the same as _indextime.&lt;/P&gt;&lt;P&gt;I'm also seeing 'min' latency values of ~-18000 seconds (suggesting Splunk is occasionally successfully recognizing a timestamp, but not getting the timezone right); and positive latency of ~74,000 seconds. More evidence that Splunk is occasionally recognizing a timestamp... but not accurately.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Zoom timestamp / latency diagnostic" style="width: 999px;"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/10265iF951FBC915CFDADB/image-size/large?v=v2&amp;amp;px=999" role="button" title="Screen Shot 2020-08-14 at 1.34.11 PM.png" alt="Zoom timestamp / latency diagnostic" /&gt;&lt;span class="lia-inline-image-caption" onclick="event.preventDefault();"&gt;Zoom timestamp / latency diagnostic&lt;/span&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;My question: Given the issues we're seeing, and the variation in timestamps in events (see analysis below), what do the developers of the add-ons (or Splunk or Zoom) recommend as an approach to accuracy of _time?&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;See SPL to drive analysis of your events based on grouping (stats) by event_type type event:&lt;BR /&gt;index="&amp;lt;yourzoomindex&amp;gt;"&lt;BR /&gt;| regex _raw = "time|start|end"&lt;BR /&gt;| eval indextime = strftime(_indextime,"%+")&lt;BR /&gt;`comment("NOTE: timestamp=none is a result of Splunk's timestamp parsing; occurs when it can't find (parse) a timestamp. ")`&lt;BR /&gt;| fillnull value="-" event_type type event&lt;BR /&gt;| stats count count(payload.time_stamp) AS payload.time_stamp count(payload.object.date_time) AS object.date_time count(payload.object.start_time) AS object.start_time count(start_time) AS start_time count(payload.object.end_time) AS object.end_time count(end_time) AS end_time count(update_time) AS update_time count(payload.object.timezone) AS object.timezone count(payload.object.occurrences{}.start_time) AS occurrences.start_time count(payload.object.recurrence.end_date_time) AS recurrence.end_date_time count(payload.object.participant.join_time) AS participant.join_time count(join_time) AS join_time count(payload.object.participant.leave_time) AS participant.leave_time count(leave_time) AS leave_time count(payload.object.participant.sharing_details.date_time) AS participant.sharing_details.date_time count(payload.object.recording_file*.recording_start) AS recording_file*.recording_start count(payload.object.recording_file*.recording_end) AS recording_file*.recording_end first(_raw) AS sample_event by event_type type event&lt;/P&gt;</description>
    <pubDate>Fri, 14 Aug 2020 18:38:15 GMT</pubDate>
    <dc:creator>wryanthomas</dc:creator>
    <dc:date>2020-08-14T18:38:15Z</dc:date>
    <item>
      <title>Zoom logs and Timestamps</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Zoom-logs-and-Timestamps/m-p/514180#M87145</link>
      <description>&lt;P&gt;Looking at Zoom log timestamps... I'm trying to figure out timestamps (and accuracy of _time).&lt;/P&gt;&lt;P&gt;The Zoom 'add-on' scene is a little confusing: There is the "Splunk Connect for Zoom" app (&lt;A href="https://splunkbase.splunk.com/app/4961/" target="_blank" rel="noopener"&gt;https://splunkbase.splunk.com/app/4961/&lt;/A&gt;)&amp;nbsp; which is listed as an 'add-on', but it has no timestamp recognition config (no props.conf at all).&amp;nbsp;&lt;/P&gt;&lt;P&gt;Looking at&amp;nbsp;Splunk Add-on for RWI - Executive Dashboard (&lt;A href="https://splunkbase.splunk.com/app/5063/" target="_blank" rel="noopener"&gt;https://splunkbase.splunk.com/app/5063/&lt;/A&gt;) - this *does* have a props.conf and zoom-specific configurations... but... the only thing related to timestamps are some search-time field extractions. No timestamp recognition configs. The search-time extractions are date-time strings, not epoch-time values... and are not exhaustive.&amp;nbsp; (See SPL below for analysis / comparison of timestamp values -- including these extracted fields.)&lt;/P&gt;&lt;P&gt;I'm seeing that timestamp=none is getting assigned to every event, so that means timestamp recognition is being attempted and, presumably, failing. Which suggests that the _time value (when recognition fails) is the same as _indextime.&lt;/P&gt;&lt;P&gt;I'm also seeing 'min' latency values of ~-18000 seconds (suggesting Splunk is occasionally successfully recognizing a timestamp, but not getting the timezone right); and positive latency of ~74,000 seconds. More evidence that Splunk is occasionally recognizing a timestamp... but not accurately.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Zoom timestamp / latency diagnostic" style="width: 999px;"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/10265iF951FBC915CFDADB/image-size/large?v=v2&amp;amp;px=999" role="button" title="Screen Shot 2020-08-14 at 1.34.11 PM.png" alt="Zoom timestamp / latency diagnostic" /&gt;&lt;span class="lia-inline-image-caption" onclick="event.preventDefault();"&gt;Zoom timestamp / latency diagnostic&lt;/span&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;My question: Given the issues we're seeing, and the variation in timestamps in events (see analysis below), what do the developers of the add-ons (or Splunk or Zoom) recommend as an approach to accuracy of _time?&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;See SPL to drive analysis of your events based on grouping (stats) by event_type type event:&lt;BR /&gt;index="&amp;lt;yourzoomindex&amp;gt;"&lt;BR /&gt;| regex _raw = "time|start|end"&lt;BR /&gt;| eval indextime = strftime(_indextime,"%+")&lt;BR /&gt;`comment("NOTE: timestamp=none is a result of Splunk's timestamp parsing; occurs when it can't find (parse) a timestamp. ")`&lt;BR /&gt;| fillnull value="-" event_type type event&lt;BR /&gt;| stats count count(payload.time_stamp) AS payload.time_stamp count(payload.object.date_time) AS object.date_time count(payload.object.start_time) AS object.start_time count(start_time) AS start_time count(payload.object.end_time) AS object.end_time count(end_time) AS end_time count(update_time) AS update_time count(payload.object.timezone) AS object.timezone count(payload.object.occurrences{}.start_time) AS occurrences.start_time count(payload.object.recurrence.end_date_time) AS recurrence.end_date_time count(payload.object.participant.join_time) AS participant.join_time count(join_time) AS join_time count(payload.object.participant.leave_time) AS participant.leave_time count(leave_time) AS leave_time count(payload.object.participant.sharing_details.date_time) AS participant.sharing_details.date_time count(payload.object.recording_file*.recording_start) AS recording_file*.recording_start count(payload.object.recording_file*.recording_end) AS recording_file*.recording_end first(_raw) AS sample_event by event_type type event&lt;/P&gt;</description>
      <pubDate>Fri, 14 Aug 2020 18:38:15 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Zoom-logs-and-Timestamps/m-p/514180#M87145</guid>
      <dc:creator>wryanthomas</dc:creator>
      <dc:date>2020-08-14T18:38:15Z</dc:date>
    </item>
  </channel>
</rss>

