mmsequence has no details on *how* to use global variables instead

[OrangeDog]

Do not use this module for newly crafted config files. Use global variables instead.

A link to some examples on equivalent configuration should be provided.
How do you generate random variables?
How do you generate incremental sequences?
How to you access the generated numbers in templates?

In fact, I don't think there's any documentation on global variables at all.
They're not mentioned in Variable (Property) types.

[orgads]

Any progress on this?

[rgerhards]

no - it's an open source project with limited ressources. Feel free to submit a PR. Or consider professional services if you need it very quickly ;-)

[rgerhards]

as a side-note: reading up on global variables really helps. Set the var e.g. to zero and then increment it whenever you need. There is also a random function which you can use to init.

[OrangeDog]

Feel free to submit a PR.

We don't know how to do it in the first place, so we can't write the documentation

reading up on global variables

Where?

[rgerhards]

you have a point here. I thought we had a section on variables, but quick search just brought me to https://www.rsyslog.com/doc/master/rainerscript/variable_property_types.html?highlight=variables# (and more than quick search should not be required). I'll see if I can do anything against it, but as I said, there is unfortunately much to do :-(

[OrangeDog]

I think I managed to set something up, but I'm not convinced that the increment is atomic.

[rgerhards]

global variable updates are guarded by a mutex. So they are atomic. If you have a case where it is not, it's a bug. A good bug report together with diagnostic information would help solve it then.

[atc0005]

Potentially related (re doc coverage of variables): #592

[OrangeDog]

global variable updates are guarded by a mutex

That's exactly the sort of thing that should be documented.

[davidelang]

in a nutshell (and far too brief for docs) Initially, there were message properties, that look like variables, but cannot be changed by the admin. These still exist, and some can be altered via parser configs. when variables were first introduced, there were only $! variables, so they are the default for many things. $! variables are stored as a json tree (log with the tempalte RSYSLOG_DebugFormat to see all the variables) the need was identified for variables that will not show up in the body of the message, so $. variables were introduced. Other than not being the default, they are able to do anything that $! variables can. both of these variables classes exist separately for each message, nothing done when processing one log message can affect any other log message. Global variables were introduced to cover the case where you need to have something in one message affect other messages. Access to global variables is done within a lock, which makes them safe but slow to use (and can be a source of congestion if you have many threads using them. David Lang On Mon, 17 Jun 2019, James Howe wrote:

…

Date: Mon, 17 Jun 2019 09:40:55 -0700 From: James Howe ***@***.***> Reply-To: rsyslog/rsyslog-doc ***@***.***> To: rsyslog/rsyslog-doc ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [rsyslog/rsyslog-doc] mmsequence has no details on *how* to use global variables instead (#799) > global variable updates are guarded by a mutex That's exactly the sort of thing that should be documented.