Query Regarding Creating Multiple Custom Parsers for the Same Log Source

[harshwardhan16]

I created a custom parser for OCSF and made it active. When I tried to create a new custom parser, I received the message, "A custom parser already exists for this log source. Do you want to inspect that?"

Can I have multiple custom parsers for the same log source, or is it restricted to just one?

Any guidance or help would be greatly appreciated.

[JeremyLand]

You can have 1 main parser (default or custom) and 1 parser extension per logtype. 
If you need fields parsed differently based on logsource for the same logtype there are two routes:

1: If the data required to decide on different field parsing is contained in the rawlog you can build control logic up inside the parser to route down different paths based on that data.  The parser logic cannot access the metadata added during ingestion like labels or feed-id so the differentiator must be contained in the rawlog itself.
2: Submit a GCP support request for a new logtype be created, once that is created you can modify your ingest process to send logs for the 2nd parser new logtype.

[harshwardhan16]

Hi @JeremyLand,

Thank you for your response.

Is there a way to have three different extension parsers of the same type that I can call based on different field parsing from my custom parser?

For example, I'd like to have a main parser for OCSF that contains all the logic for different scenarios and three extension parsers that would be triggered based on specific conditions.

Thanks again for your help!

[JeremyLand]

@harshwardhan16 You'll need to build out the control logic and additional conditional field mappings in a single place. It sounds like you've already started this work in custom parser, but you may be able to achieve what you need in an extension if the default OCSF parser does most of what you need.

You can have 1 parser extension per logtype, they start from rawlog, and can't reference the memory state or any of the fields extracted by the main parser.  The parser extension runs anytime the main parser produces UDM output (is not run if the main errors or drops the event). If there are any conflicting values when the UDM output of the extension is merged with the UDM output from the main parser, the values from the extension take precedence.

The use case for extensions would be the main parser gets all but a few fields you need, or you would like a different value in a particular field based on your environment. Then you could write an extension for just those few fields which would allow you to stay on the default parser but have your additional fields.

If you need to write a custom main parser, you are probably best off by including all your customizations in there. This will be easier to develop and maintain since you'll just be looking in one file for any issues and won't need to maintain two separate instances of your initial data prep/field extraction logic.