Variable to show Time Received in email.

[Anon Anon]

All,

 

We have been having issues with alarm messages sent via emailgtw being interpreted ad delayed based on the "Time" and "Arrival Time" being the same. I want to edit the template, changing the Arrival Time variable ($arrival_exp) to the Received time.

 

1. Is there a variable for the Received Time?

2. Is it $received_exp?

 

Thanks.

[Anon Anon]

I think you'd want to use:

 

$nimts_exp

 

You may already know this, but if you hit "$" key in the emailgtw probe, you'll get a list of variables. In the help file for emailgtw probe, you'll see a list of all the variables and what they mean. Or in the probes help file in Infrastructure Manager, just search for "Variable substitution" and you'll see it there too.

 

Sachin

[Anon Anon]

Thanks Sachin, but the $nimts_exp is the time of Origin of the alarm. Here is the problem.

 

When the alarm is sent out, it is in the following format

<b>Time:</b> $nimts_exp, <b>Arrival Time:</b> $arrival_exp

 

So we have an email that lists the Time the offending behavior happened (Origin) and then the time it hit the NAS (Arrival). The problem being that the majority of cases, people think the Arrival time is the latest time that the alert came in. So in some cases, you have a problem occur on July 13th, the alarm shows as follows

 

Time: Tue Jul 13 10:05:52 2011, Arrival Time: Tue Jul 13 10:05:58 2011

 

Now, lets say the offending behavior does not clear until the next day (July 14), when the clear goes out, it shows the same information.

 

Time: Tue Jul 13 10:05:52 2011, Arrival Time: Tue Jul 13 10:05:58 2011

 

Then I get calls, "How come I am only getting this alert now? It is July 14th and the clear shows an Arrival of July 13th."

 

I am looking to replace the $arrival_exp with the actual received time of the message. I am trying the $aots_exp, but so far it enters

Recieved Time: Wed Dec 31 19:00:00 1969
 

[Anon Anon]

The trick here is that there is no such thing as received time. 

 

Okay, that does not make any sense because you see the received time in the alarm console. Right? Well, the problem is that the received time is just a construct of the alarm console. Alarms do not actually contain any such field in the NAS. And when the NAS forwards the alarms to the emailgtw, they almost certainly do not have a field for it either.

 

I should mention that I am not familiar with the internals of the NAS. These are my observations based on working with alarms in NAS scripts and on the NAS database schema documented in the whitepaper. I am also not a lawyer.

 

So how does the alarm console manufacture the received time? Well, if the alarm came in only once, the received time is the same as the arrival time. But if the alarm has repeated, the received time is the same as the suppression time (supptime). I think this leaves you with two options:

 

• You could change the template to use the supptime in the email. Then I think the field will be blank in the email if the alarm has occurred only once so far. (You may want to test; it might how an error message rather than be blank.)
• You could use a NAS script to format the email message however you want. Then you can have the script calculate the received time. The action.email() function would send the message using your custom formatting.

-Keith

[Anon Anon]

Keith,

 

Thank you for the information, as I am not script savvy I will try the first option and see where it takes me I will let you know.

[Anon Anon]

---

kruepke wrote:

...You could change the template to use the supptime in the email. Then I think the field will be blank in the email if the alarm has occurred only once so far. (You may want to test; it might how an error message rather than be blank.)

 

-Keith

---

Keith,

 

I used the $supptime_exp and it is doing exactly what we are looking for!

Time of Origin: Tue Aug 02 23:48:59 2011, Received Time: Wed Aug 03 09:42:31 2011, 

 

[Anon Anon]

Excellent!

 

What do you see when the email goes out for a new alarm that has not repeated? Maybe a blank, an error, or a date in 1969?

 

Just curious...

 

-Keith

[Jose Romero]

I have the same problem, could you tell me how they solved it?