Highlighted
toe Absent Member.
Absent Member.
766 views

Access Timestamp attributes

Hi all!

I intend to collect particular event counts per day (or hour) and have these events directly grouped within the ActiveList or Trend. The original timestamp fields like $endTime are not suitable for my purpose because these are too precise (-> second based). The interval based timestamps from the Trend are also not suitable because they contain the time the Trend ran, not the time the respective events occured. Since several feeds have delays between Manager Receipt Times and the original End Times, this is not reliable enough and may confuse the report's results.

What I need is information (which might be a string field) like e.g. "2012-06-18 09" for all the matching events between 09:00 and 09:59 yesterday.

On Logger queries I can achieve this directly by selecting DATE_FORMAT(DATE_SUB(events.arc_endTime,INTERVAL -1 HOUR),"%Y-%m-%d %H") and use the respective aliased field as a group-by condition. This will collect grouped data in time slice buckets of one hour each. This would easily allow for time slice based graphing similar to the Active Channel's Radar.

I tried to bring the Timestamp data in the right format by doing something like $endTime.getYear()-endTime.getMonth()-... or $endTime.format("%Y-%m-...") in a VTL, but this does not work so far. As I understand the Java datetime classes, a separate SimpleDateFormat object needs to be created to achieve proper formatting of date objects. But this does by far extend VTL's capabilities, as I understand it.

Has anyone been able to format DateTime variables within ESM when referencing them? Or do you have a hint for me, how to achieve my required time slice based reports through an alternative way I haven't thought of yet?

Labels (2)
0 Likes
Reply
3 Replies
Acclaimed Contributor.. Volker Michels Acclaimed Contributor..
Acclaimed Contributor..

Re: Access Timestamp attributes

Hello Tammo,

maybe interesting for you, on the smart connector in the default tab navigate to the section "Processing" and the you can enable a field "Store original time in" with "Flex Date 1".

Volker

0 Likes
Reply
toe Absent Member.
Absent Member.

Re: Access Timestamp attributes

Thanks for hinting, but sadly that doesn't help here.

When I wrote about the Trend execution time being saved in the Trend's timestamp field, I accidentally referred to that as the Manager Receipt Time. What I meant was that the execution time is saved here and the field is not populated with date information from the respective event.

Therefore if I schedule an hourly Trend as recommended > 1 day in the past (e.g. hourly from $Now - 1d - 1h till $Now - 1d), the values in the Trend's timestamp field will be shifted by exactly this day. So events which were received by the ESM on 2012-06-18 7:32:12 will have their timestamp fields populated with 2012-06-19 07:00

0 Likes
Reply
toe Absent Member.
Absent Member.

Re: Access Timestamp attributes

My workaround: I have a global variable which itself has three local variables: var_year, var_month and var_day. These variables are populated with the respective Timestamp functions (get_year and such) and concatenated together with the following VTL:

${var_year}-#if($var_month < 10)0#end${var_month}-#if($var_day < 10)0#end${var_day}

Its kind of an ugly workaround but helps me to populate my reports based on the originating events' End Times instead of (possibly faulty) Manager Receipt Times or Trend Execution Times. Having more precise information (e.g. the respective hour of occurence) works analogously.

0 Likes
Reply
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.