DX Unified Infrastructure Management

 View Only
Expand all | Collapse all

time_origin not consistent in lua auto-operator script

Jump to Best Answer
  • 1.  time_origin not consistent in lua auto-operator script

    Posted Aug 18, 2015 06:54 PM

    I am attempting to set several pieces of information in the custom fields of alarms and am having a difficult time getting the time_origin to work reliably.  Unfortunately I need to put the origin time in one of the custom fields as that is the only way for me to pass the origin time through the automated ticket creation probe (restsd_gtw) unless I want it as an epoch time.  I have been able to set several other values in the custom fields, but the origin time is not working.

     

    This is the portion of the script that should be adding the origin time:

    local al = alarm.get() local update = ()  update.nimid = al.nimid  update.custom_1 = al.time_origin  alarm.set(update)

     

    If I run a similar script that just prints the values to the console, it always prints the time_origin properly.  The difference being that I am running the script manually and setting an alarmid that already exists instead of the auto-operator picking up the alarm on arrival.

     

    I am calling the script from an auto-operator  profile that is configured as follows:

    • Action type: script
    • Action mode: On message arrival
    • Severity Level: all except green
    • Message Counter: Equals to 1

     

    I need to have these custom_* values set as early as possible, as this is the groundwork necessary to start automating ticket creation upon alarm arrival.  I suspect that the time_origin field is not set immediately and my script is firing before it is set.  Is there a better way for me to get the origin time inserted to the custom_1 field?  Or is there a better profile configuration that I should be using to fire off my script?



  • 2.  Re: time_origin not consistent in lua auto-operator script
    Best Answer

    Posted Aug 18, 2015 08:13 PM

    I figured it out, but in case anyone else runs into this I wanted to post the solution.

     

    I realized that I could leave print statements in my script and they write the output to the nas.log file so I can view the live data.  In doing so, I printed the full alarm table and realized that all of the time-related objects are in epoch time, and time_origin is not one of them.  Below is a full dump on a live alarm for example.  I'm not sure how time_origin works in my test scripts that are run manually, but not in auto-operator triggered scripts, but I'll leave that for another day.

     

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:  root:

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    robot:hub-01

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    source:10.20.30.40

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    origin:HUB-01

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    arrival:1439940148

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    hostname:HUB-01

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    level:3

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    aots:1439940573

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    profile:Set Custom3-5

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    visible:1

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    sid:1.1.15

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    severity:minor

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    domain:LAB-UIM

    Aug 18 16:29:33:841 [6808] nas: Set Custom3-5:    nimts:1439940147

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    subsys:Other

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    message:This is a test message

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    tz_offset:25200

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    nas:HUB-01

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    hub:HUB-01

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    suppcount:0

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    nimid:LD32845607-94999

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    event_type:2

    Aug 18 16:29:33:842 [6808] nas: Set Custom3-5:    rowid:1

     

    So, I modified my logic to use the nimts element and converted it to local time.

    local al = alarm.get()
    local update = ()
    
    update.nimid = al.nimid
    
    update.custom_1 = os.date("%c", al.nimts)
    
    alarm.set(update)