Parser extension vs. modify parser ?

[BGREEN900913]

I have an existing parser that is working fine, but doesn't contain UDM mappings for a few RAW fields. 

This is actually a custom parser that was 'cloned' from the prebuilt/default version (which is now disabled).

I need to leave the prebuilt/default parser alone even though it's disabled (for support/warranty reasons). And as we're already using a customer parser, I can't create another clone - Chronicle seems to be limited to 1 custom parser per data type.

My options for adding these field mappings seem to be:

1) Modify the customer parser

2) Create a parser extension

What are the pros and cons of each method? I need to be cautious as the custom parser is in use 24/7.

[DanHansen]

They should both work in this case you are correct. Since the parser is already custom there should be no issue going in and adding the field mappings you want. Probably the biggest advantage to extensions is the ability to change mapping on pre-existing parsers. Since this is a custom you have options but depending on how much new mapping you're doing it may just be easier to attach an extension to your parser.  You've already done it before so you know the process of integrating a custom parser. Adding and removing extensions is relatively easy.

[gcptom]

Hi BGREEN900913,

I agree with DanHansen here and just wanted to add one thing - with a Parser Extension you have the ability to validate the changes before moving it to live. Please see further details on the Parser Extension Lifecycle here: https://cloud.google.com/chronicle/docs/event-processing/using-parser-extensions#lifecycle_of_a_pars...

Thanks for your question!

[citreno]

I would go with parser extension in this case, but agreed, you could go with either. It's usually healthy to merge your updates with the original parser updates occasionally in case you're missing something but that's a manual process. Extension is great except in two very specific cases: 1) if the underlying parser drops a log due to error or explicit drop and there's no baseline parsing, extensions don't work and you have to customize the parsers 2) If you are merging into a repeated field (most commonly security_result), you will override that entire repeated field and lose any data from the original parser. So avoid repeated fields essentially. Strong +1 for google to fix and make extensions apply recursively so that the repeated fields don't get nulled out, but for now that's the situation, just use unused repeated fields if you go the extension route. 

[ion_]

One other thing that hasn't been mentioned: If you want to try out your modified custom parser and are worried about downtime, you can just set it up on any unused log label. You'll need to configure your logs to go to both log labels, so if this is possible in your infrastructure you can really easily test the new parser side-by-side.

Obviously you can also download historic logs and fire them at the custom parser through cbn run, but this has a lot more limitations than running both parsers together for X amount of time and seeing if anything breaks.

If you just want to map fields that aren't mapped and your team is already maintaining a custom parser, i'd add that into the custom parser instead of adding an extension into the mix. As was mentioned above you will need want to merge in changes from the default parser periodically, so future proof yourself by doing the following:
* Leave an easily searchable string so you can identify all of your comments. This is more valuable if its a large parser
* Leave a clear comment for what you're doing and why you're doing it so that someone else in the team can evaluate if these changes are still required at each merge.

Obviously this impacts the custom parser in general, not only your changes, so perhaps this is a good step towards making the custom parser easier to manage. Default parser updates are semi frequent and are usually good, so you will be missing out by not using them.