OM 4.0.2 question/r
2013-05-07 01:19 PM
Can the timestamp from "dfm event list" output be made consistent for events? Right now once an event is > 6 months old the event doesn't list the hours and minutes and we have to go into "dfm detail" output to get that time.
We have a performance threshold setup and it is tied to various filers. Over the years the number of alerts from this threshold being breached have accumulated, and we can get an idea on which filer is generating the alerts, and when. We rely on the time stamp from dfm event list output for this, and I see that the timestamp scheme changes once the event is > 6months old. Can this be made consistent? I'll give you an example:
|777901 25329 perf:new_50ms_and_10MBs:breached Error||26 Nov 18:21|
|773266 25329 perf:new_50ms_and_10MBs:breached Error||14 Nov 07:15|
|758609 25329 perf:new_50ms_and_10MBs:breached Error||04 Nov 2012|
How we use data is that that we graph the number of alerts by the hour, so we know that volume 25329 generated one alert between 07:00-08:00, another one between 18:00-19:00, and so on. Once we get enough of these alerts and then we can map out the hours on which the largest number of alerts are generated(11pm-1am, for example).
Today being 5/7/2013, Nov 14 is less than 6 months old so it shows the time, and Nov 04 is more than 6 months old so the hh:mm part goes away and we see "2012" This is generally fine with generating a graph like this since older data points are less valuable than the more recent data for this purpose, but if it the output format stayed consistent like "yyyy-mm-dd hh:mm:ss", then the it is more predictable and would help us map out the problem periods more accurately.
Re: OM 4.0.2 question/r
2013-05-08 08:47 PM
Firstly, I suggest you move to version 5.0.2P1 or 5.2. In 5.0 and later we have view for Events which can give you what you are looking for.
Also instead of using dfm event list, use the report cli instead.
dfm report view events-history <volume id>