How guarantee CUCM CDR Timestamps parsing in my timezone ?

[radw62]

Hello, How can I guarantee that Splunk parse the CUCM CDR Timestamps in my timezone (UTC -5) ? (As CUCM CDR raw timestamps come in UTC)

Regards.

[radw62 · Accepted solution]

Hello, let me explain again my concern:

Suppose that I want to query all calls (initiated or terminated) on July , in my time zone (i.e UTC -5). How Splunk (or your app) could really query that calls in this time range in my time zone? Or where can I define correctly the time range (on my timezone) in my query ? (like CUCM CAR Tool or RTMT where both require that I define the time zone besides the time range for query calls).

Thanks and regards.

[sideview]

The Splunk framework itself will always interpret the timerange arguments within your search in the timezone that the Splunk server is located in. Likewise it displays times localized into that same timezone that the Splunk server is located in.
That is usually what people want. In rare cases it becomes necessary to override that behavior and that can be done in the conf.

So, to use your example here. If the Splunk server is installed on a host where the timezone is set to "GMT", all the timerange arguments of your searches and reports (eg 10/1/2015 16:00:00) will be interpreted within that TZ.

[radw62]

Hello, thanks for your answers.

Yes, in fact, I installed "Cisco CDR Reporting and Analytics" app inside Splunk and I parsed the CDRs with it. However, I remained in doubt, if it really parsed the CDRs in my timezone (different from UTC), and I want to make sure of that, with the props.conf file or with something else within the CDR app.

Regards.

[sideview]

That's great. OK well Callmanager CDR lists all timestamps in epochtime, and in that format there is no concept of any associated timezone nor is any needed, so there's kind of no way to get this part wrong.

To give an example, let's say callmanager says a call originated at 1469800000.
That one number is sufficient to completely determine the time, without any need for any associated timezone.

That epochtime value of "1469800000", if written out as a string, in GMT would be Fri, 29 Jul 2016 13:46:40 GMT
and in US Pacific time that same instant in time is 7/29/2016, 6:46:40 AM GMT-7:00 DST

Those strings need tz information to determine what time they're talking about, but epochtime timestamps don't.

[sideview]

I think the Timezone part of this question is a bit of a red herring.
Callmanager CDR reports its timestamps in epochtime, which is often confused with UTC. UTC is technically a timezone, sort of like GMT without any Daylight Saving Time shenanigans. Epochtime on the other hand is simply the number of seconds since midnight on 1/1/1970 gmt. Despite the odd gmt reference there at the end, the number of seconds itself entirely determines the time, no TZ info is necessary or needed by Splunk.

As to how to display this time and date as a string, Splunk by default uses the timezone that it is located in. This can be changed in user-prefs.conf but it's not often done.

You might also take a look at the Splunk app "Cisco CDR Reporting and Analytics". Although it's not free, it is available as a free 90 day trial.

I'm certainly biased as it's owner and creator, but it enables a very wide range of reporting use cases on Callmanager CDR and you may find it very useful. ( http://sideviewapps.com/apps/cisco-cdr-reporting-and-analytics/ ) There are several timestamps in Callmanager CDR data and although dealing with them correctly isn't particularly difficult, it's one of many things that the app would handle for you.

[TStrauch]

Hi radw,

take a look at the props.conf documentation. There is a parameter called "TZ" you can set it for the sourcetype. Hope this will help you.

Kind regards