patterndb parser: PROGRAM and MSG should be configurable about syslog-ng

[algernon]

template() is meant to allow you to tell syslog-ng what to treat as $MESSAGE, pretty much. That it is not documented, is a bug towards the docs team (I'll let them know).

Adding a program template is something to consider. I'll check the code.

[faxm0dem]

I believe template() is not a very comprehensive name, especially in this case where we need one for each macro. This is why I proposed message_template (which is not the best either ;-)) in the first place. Thanks for looking into this!

[algernon]

The thing with template() is that it has been used to change syslog-ng's idea of what $MESSAGE is since the dawn of time, and it is everywhere. It is, of course, possible to add an alias to make that clear, especially in cases when there are other templatable fields.

[faxm0dem]

deal!

[ihrwein]

I just checked this. The template() parameter should be supported by dbparser and it's the same as your message_template(). Aliasing it is easy.

The program_template() doesn't exists, yet. Do you think this is dbparser specific or general enough to be supported by all parsers?

[faxm0dem]

program_template seems very specific to dbparser, as others only use one template.
If one were to generalize this, it would probably make more sense to allow for template to be passed an array, e.g. [$MSG, $PROGRAM, ...]

[bazsi]

I think this is a good short term feature. I originally wanted to make
db-parser n dimensional, each making it possible which nvpair it would use
for matching.

But I think we don't want that but rather add this kind of filtering into
the config.
On Dec 2, 2015 4:22 PM, "Fabien Wernli" [email protected] wrote:

program_template seems very specific to dbparser, as others only use one
template.
If one were to generalize this, it would probably make more sense to allow
for template to be passed an array, e.g. [$MSG, $PROGRAM, ...]

—
Reply to this email directly or view it on GitHub
#141 (comment).

[hadret]

I'm not 100% sure whether my case apply here as well, but by the overall look of it it seems so. I'm having a structured way of $PROGRAM name that I need to parse in order to aggregate logs the way I want to. Logs themselves can originate from the same and/or different hosts (multiple instances per host) at the same time, so I went with the following pattern for the $PROGRAM: app_part1/app_part2/app_part3. The first two parts are the same for every instance, the differentiating factor is the third part. I wanted to have the following structure in the logs tree: /var/log/app_part1/app_part2.log -- but in order to be able to do that, I would need to be able to parse $PROGRAM, which is, to my understanding, currently impossible.

[bazsi]

No, its not. The ruleset level pattern refers to the program name and you can use the same pattern language there. On Jun 21, 2017 12:03 PM, "Filip Chabik" <[email protected]> wrote: I'm not 100% sure whether my case apply here as well, but by the overall look of it it seems so. I'm having a structured way of $PROGRAM name that I need to parse in order to aggregate logs the way I want to. Logs themselves can originate from the same and/or different hosts (multiple instances per host) at the same time, so I went with the following patter for the $PROGRAM: app_part1/app_part2/app_part3. The first two parts are the same for every instance, the differentiating factor is the third part. I wanted to have the following structure in the logs tree: /var/log/app_part1/app_part2.log -- but in order to be able to do that, I would need to be able to parse$PROGRAM`, which is, to my understanding, currently impossible. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArldtLvwLB-kHfZpyUUa_mQASqlOraXks5sGOpVgaJpZM4CFTJF> .