AnsweredAssumed Answered

How to order parser in Log Decoder 10.6.x

Question asked by Maximiliano Cittadini on Feb 19, 2018
Latest reply on Feb 20, 2018 by Maximiliano Cittadini

Like • Show 0 Likes0
Comment • 5

I have a customer running NW 10.6.3 and we have several parsers enabled like:

rhlinx, bigip, mcafeegw, solaris, aix, hpux and several unix flavor parsers...

The problem that I'm facing is the following:

I have several event sources that produce events with ntp and there are parsed as McAfee Web Gateway instead other unix/linux OS (as result, the customer sees over 200 devices labeled as McAfee Web Gateway when in reality he has onlye 4 Mcafee Proxies). There is any method that I can use to order/priorize for example solaris, rhlinux or aix parser over mcafee web gateway? (I think the alphabetic order of the device name is used in the decoder to priorize the parser wich is used)

Regards,

Max

No one else has this question

Outcomes

5 Replies

Dave Glover Feb 19, 2018 11:24 AM
Mark Correct
Correct Answer
There is no way to order the way parsers are evaluated. However for the situation you describe the best course would be to map those devices to only use a specific parser.
Like • Show 1 Like1
Actions
- Maximiliano Cittadini @ Dave Glover on Feb 19, 2018 12:28 PM
  Mark Correct
  Correct Answer
  Thank for your reply Dave, in 10.6.x I can only map parsers that are enabled in the decoder, right?
  Like • Show 0 Likes0
  Actions
  - Eric Partington @ Maximiliano Cittadini on Feb 20, 2018 8:43 AM
    Mark Correct
    Correct Answer
    Parsers are matched to devices based on internal scoring from header matches. This is what is exposed and enhance in NW11 event source discovery to help provide visual indication of the confidence of a match and allow the admins to force match ones that are very weak matches (rhlinux and others).
    In your case, using the device parser option (depending on your version) to map the rhlinux devices to that parser (enabled on the log decoder) to avoid weak matches to other device types. There is a file on the file system that you can edit manually (xml) or using the rest interface (early versions) and then in the UI on each decoder/ config (later 10.6 versions).
    
    forcing a match to a parser should be to ones that are enabled (you want to force matches to a devicetype so that its parsed properly.) Order of the file is important, the parser will match the first one before the second if you have multiple parsers per device forced (rhlinux + apache etc.)
    
    Also make sure that if you start using this force match then you should check regularly for
    device.type exists && word exists
    which would indicate that you have a forced match but the parsers cant extract useful information and most likely the device.type changed or the parser list is incorrect. (the parser is forcing the device.type but no matching messages exist).
    1 person found this helpful
    Like • Show 1 Like1
    Actions
    - Dave Glover @ Eric Partington on Feb 20, 2018 10:17 AM
      Mark Correct
      Correct Answer
      Another Query that I use a lot is 'device.type = {your device} && msg.id !exists' That will show you all the messages that we do not parse for a given device
      Like • Show 0 Likes0
      Actions
    - Maximiliano Cittadini @ Eric Partington on Feb 20, 2018 10:20 AM
      Mark Correct
      Correct Answer
      Thank you very much Eric!
      I'm currently disabling the mcafeewg parser from the Config of the decoder and map the device type to the 4 proxies IPs. That works fine for me. I have also an ESA rule to check whenever a device type and word metas exists on the same event to alert me whenever there is a miss parsed event.
      I'm planning to do the same with other linux based products like bigip because a simple "cron job" event is matched as bigip instead of a rhlinux device, causing the ESM groups and monitoring policies a little bit noisy.
      
      thank you again for the explanation
      regards,
      Max
      Like • Show 0 Likes0
      Actions

How to order parser in Log Decoder 10.6.x

Outcomes

Related Content

Recommended Content