Better syslog message handling for Zabbix

[alixen]

Hi,

We are releasing under GPL a program that provides better integration of syslog messages with Zabbix.
(This is not a ZABBIX SIA official development).

Currently, Zabbix cannot process messages in syslog format.
It can only process messages stored in flat files by standard syslog programs on Unix/Linux systems.

It has two drawbacks:

1. It can process logfiles only on hosts where Zabbix agent can be installed.
   Logs from devices such as routers or firewalls cannot be processed.
2. syslog protocol defines several informations associated to messages that are lost : timestamp, facility and severity.

This project adds support in Zabbix for a new kind of item:

syslog[<facility>,<regexp>,<severity>,<maxlines>]

Main program is a syslog server that receives syslog messages from local or remote hosts and send them to corresponding items in Zabbix.
It uses zabbix agent protocol in active mode to send syslog messages to zabbix server.
It takes advantage of existing timestamp, source and severity fields associated in Zabbix to eventlog items (used for Windows logs):
- syslog timestamp is stored in zabbix event "timestamp";
- syslog facility is stored in zabbix event "source";
- syslog severity is stored in zabbix event "severity".

It has been collecting syslog messages from

• Linux (syslog and rsyslog)
• FreeBSD/pfSense firewall
• APC SmartUPS
• Dell Powerconnect switch

for more than 2 weeks.

A detailed explanation is included in README (http://www.alixen.org/svn/zbxlog/tags/r0.1/README)

It has been tested on Zabbix 1.8.2 and 1.8.3.

You can download release 0.1 from : http://www.alixen.org/attachments/do...bxlog-r0.1.tgz

Feel free to download and test it.
Any feedback is welcome.

Regards,
Alixen

[whisky]

great works !

Do you think you'll have a chance to settle for the added severity levels that are in par with syslog severity (and I think RFC) as an Official Zabbix numbering ?

note : it would be great to have in one of your settings file a way to add a dictionnary that could match for a source

a regexp to match
optionaly a replacement part for that regexp if matched
so that only the log entries for the given facility will be passed to zabbix when there is a match.

Doing so could simplify the way to write triggers in Zabbix as we will already have some powerfull filtering on the machine running the proxy (guess it has more power to spare than a charged Zabbix server). As it run as a daemon pre-compiling the regexp will be a performance boost also.

[zalex_ua]

Feel free to download and test it.
Any feedback is welcome.

ha-ha.
You're faster than me I finish my similar solution for several months.
Your solution is very, very interesting. Private syslog server - this is very cool. I use Syslog-NG.
Maybe I'll borrow you some ideas
I assure all Zabbix community that this is the first such solution, which is available publicly.

Congratulations.

[alixen]

Do you think you'll have a chance to settle for the added severity levels that are in par with syslog severity (and I think RFC) as an Official Zabbix numbering ?

There are 8 severity levels as defined by RFC.
I have chosen to use a range outside of Zabbix official severity levels since the ones used by Zabbix are Windows specific.
If you apply patches supplied for Zabbix frontend, you will get correct labels and colors for severity levels instead "Unknown".

As for official Zabbix numbering, I have no contact with Zabbix team. If one of them could comment on this it is more than welcome.

note : it would be great to have in one of your settings file a way to add a dictionnary that could match for a source

You can filter on syslog source by specifying it in item definition:

syslog[mail]

will match logs coming from mail facility only.

a regexp to match

Done !

syslog[mail,^postfix]

will match messages from mail facility starting with "postfix" string (Perl regular expressions are used).

optionaly a replacement part for that regexp if matched

This is not possible.
I have defined a syntax as close as possible to eventlog as defined by Zabbix agent.

so that only the log entries for the given facility will be passed to zabbix when there is a match.

Doing so could simplify the way to write triggers in Zabbix as we will already have some powerfull filtering on the machine running the proxy (guess it has more power to spare than a charged Zabbix server). As it run as a daemon pre-compiling the regexp will be a performance boost also.

The whole syntax is:

syslog[<facility>,<regexp>,<severity>,<maxlines>]

so you can filter on

• facility
• severity
• regular expression

and limit the maximum numbre of lines per second.

Regards,
Alxen

[zalex_ua]

Any feedback is welcome.

So let's go.
Firstly thank you for the work done.

Secondly the right standard RFC 3164 and RFC 3124 does not


Why did you decide to use the abbreviated names?
+ 'S_SYSLOG_DEBUG' => 'debug',
+ 'S_SYSLOG_INFO' => 'info',
+ 'S_SYSLOG_NOTICE' => 'notice',
+ 'S_SYSLOG_WARN' => 'warn',
+ 'S_SYSLOG_ERR' => 'err',
+ 'S_SYSLOG_CRIT' => 'crit',
+ 'S_SYSLOG_ALERT' => 'alert',
+ 'S_SYSLOG_EMERG' => 'emerg',

in the interface so accurately use full like this and with a capital letter

+ 'S_SYSLOG_DEBUG' => 'Debug',
+ 'S_SYSLOG_INFO' => 'Info',
+ 'S_SYSLOG_NOTICE' => 'Notice',
+ 'S_SYSLOG_WARN' => 'Warning',
+ 'S_SYSLOG_ERR' => 'Error',
+ 'S_SYSLOG_CRIT' => 'Critical',
+ 'S_SYSLOG_ALERT' => 'Alert',
+ 'S_SYSLOG_EMERG' => 'Emergency',

And in general I would recommend to use full names everywhere instead of truncated, including names of keys. It will be better for users.
Why do you all decided to use truncated names?
http://www.ietf.org/rfc/rfc3164.txt used this way. I recommend not to use http://tools.ietf.org/html/draft-ietf-syslog-tc-mib-08

testlog.sh without input parameters do not stop - need to fix. It is necessary to generate an error.

some example for optimization

#$datalen = pack('q',$bytes); simple 64-bit conversion, but compatible if perl compiled witn PERL_64BITINT  Use 64 bit integers (on i386)
$datalen = pack("l",$bytes)."\x00\x00\x00\x00"; #32-bit and attached 32-bit ZERO is more compatible that 64-bit 'q'
$header = "ZBXD\x01";                   # \x01

You would not want to abandon Cron scripts and implement all inside zbxlog.pl, also does not use text files and keep everything in an array inside zbxlog.pl?

No support for "Wildcard" hosts - the host is not defined in Zabbix, but syslog messages from him come.

I sent you a mail my script. Maybe you'll find something that useful. I know that the script is written not very professionally, i have only half a year of experience programming in Perl. And as a programmer, I never was

It is not easy, but perhaps I confess that I may refuse to continue their development and switch to your decision.

To be continued ...


added:
you solution:
"debug = 10, info = 11, ... , emerg = 17."
is very similar to my last post

https://support.zabbix.com/browse/ZBXNEXT-470

I propose in the field of Event ID to write a number combination Facilities and Severities as in my real example https://support.zabbix.com/secure/at...yslog_DEMO.png This is March 2010!

[zalex_ua]

And I think you can paint a different 8 colors (probably need to patch CSS styles), but not group the existing 4 colors. We will ask developers to include it in the source code.

[alixen]

So let's go.
Firstly thank you for the work done.

Secondly the right standard RFC 3164 and RFC 3124 does not

Typo corrected.

Why did you decide to use the abbreviated names?
+ 'S_SYSLOG_DEBUG' => 'debug',
+ 'S_SYSLOG_INFO' => 'info',
+ 'S_SYSLOG_NOTICE' => 'notice',
+ 'S_SYSLOG_WARN' => 'warn',
+ 'S_SYSLOG_ERR' => 'err',
+ 'S_SYSLOG_CRIT' => 'crit',
+ 'S_SYSLOG_ALERT' => 'alert',
+ 'S_SYSLOG_EMERG' => 'emerg',

in the interface so accurately use full like this and with a capital letter

+ 'S_SYSLOG_DEBUG' => 'Debug',
+ 'S_SYSLOG_INFO' => 'Info',
+ 'S_SYSLOG_NOTICE' => 'Notice',
+ 'S_SYSLOG_WARN' => 'Warning',
+ 'S_SYSLOG_ERR' => 'Error',
+ 'S_SYSLOG_CRIT' => 'Critical',
+ 'S_SYSLOG_ALERT' => 'Alert',
+ 'S_SYSLOG_EMERG' => 'Emergency',

And in general I would recommend to use full names everywhere instead of truncated, including names of keys. It will be better for users.
Why do you all decided to use truncated names?
http://www.ietf.org/rfc/rfc3164.txt used this way. I recommend not to use http://tools.ietf.org/html/draft-ietf-syslog-tc-mib-08

I use truncated names because they are also used in syslog configuration files and syslog/rsyslog man pages.
However, I agree that long names would be better in Web interface.
I have integrated your suggestion in en_gb.inc.php.patch.
Severities in keys are checked using pattern matching, 'warn' and 'warning' will both match.
So you can write syslog[,,warn] or syslog[,,warning]
I have completed README file.

testlog.sh without input parameters do not stop - need to fix. It is necessary to generate an error.

This is a quick and dirty test program that needs some documentation.
It does not need a parameter but generates all combinations of (facility, severity) sources in string and numeric formats.
It takes some time to run.

some example for optimization

#$datalen = pack('q',$bytes); simple 64-bit conversion, but compatible if perl compiled witn PERL_64BITINT  Use 64 bit integers (on i386)
$datalen = pack("l",$bytes)."\x00\x00\x00\x00"; #32-bit and attached 32-bit ZERO is more compatible that 64-bit 'q'
$header = "ZBXD\x01";                   # \x01

Thank you, for this optimization, I will include it in next release (after some testing).

You would not want to abandon Cron scripts and implement all inside zbxlog.pl, also does not use text files and keep everything in an array inside zbxlog.pl?

I have kept it separated from zbxlog.pl because I don't have a "good" solution yet.
Should I use direct DB access, Zabbix API or extend Zabbix agent protocol ?
Current solution (DB access) is mysql specific and should be made DB independant.
I am not very familiar with Zabbix API and I don't know if I could efficiently retrieve all syslog items this way.
Extending Zabbix protocol would be the best way but, not beeing a Zabbix core developer, I am reluctant to touch zabbix_server code.
Or maybe there is a better solution I have not imagined yet...
This first release is a "proof of concept" that needs some improvements.

No support for "Wildcard" hosts - the host is not defined in Zabbix, but syslog messages from him come.
I sent you a mail my script. Maybe you'll find something that useful. I know that the script is written not very professionally, i have only half a year of experience programming in Perl. And as a programmer, I never was

The concept of "wildcard" or "catchall" host would be interesting in Zabbix not only for syslog messages but also for SNMP traps or Zabbix traps.
I'll look at your script and I will try to find a way to add "wildcard" to zbxlog.

It is not easy, but perhaps I confess that I may refuse to continue their development and switch to your decision.

To be continued ...

Glad to see that zbxlog can be useful !

added:
you solution:
"debug = 10, info = 11, ... , emerg = 17."
is very similar to my last post

https://support.zabbix.com/browse/ZBXNEXT-470

I propose in the field of Event ID to write a number combination Facilities and Severities as in my real example https://support.zabbix.com/secure/at...yslog_DEMO.png This is March 2010!

Thank you for your comments.
Alixen

[alixen]

Hi,

And I think you can paint a different 8 colors (probably need to patch CSS styles), but not group the existing 4 colors. We will ask developers to include it in the source code.

I agree that it would be better to differentiate all 8 levels. But, at first glance, it would need patches not only in CSS but also in PHP code.
My first goal was to make it useful enough without patching too much code.

Regards,
Alixen

[whisky]

...
This is not possible.
I have defined a syntax as close as possible to eventlog as defined by Zabbix agent.


The whole syntax is:

syslog[<facility>,<regexp>,<severity>,<maxlines>]

so you can filter on

• facility
• severity
• regular expression

and limit the maximum numbre of lines per second.

Regards,
Alxen

I understand the need to closely match the documentation for documented
eventlog agent key

but my suggestion was that you take profit of the fact that if you run the regexp then you have a matched context right at end.

So rewriting it to look more closely to the eventlog you can have a syntax similar to that :

syslog[<name>,<regexp>,<severity>,<facility|source>,<eventid><maxlines>,<mode>]

where

• name is one of your zabbix key item of type 'log'
• severity could be either a string or a regexp group match ($<n>)
• facility could be either the default facility, a string, a $<n>
• eventid could be a string or a $<n> group match

and the big thing will be that the <regexp> could be expressed as a
/RE/SUBSTITUTION/ Perl expression

Let apply to an example (Asterisk based)

a syslog line like :

NOTICE[6728] chan_sip.c: Failed to authenticate on REGISTER to '0123456789@domain' (Tries 3)

could get inside a Zabbix Server as a log entry like this :
Key : Asterisk (supposing such a zabbix item of type Log exists)
Value : REGISTER(0123456789@domain) Failed 3 times
Severity : NOTICE
Source : chan_sip.c
EventID : 6728

with a line like :

syslog[Asterisk,<regexp>,$1,$3,$2<maxlines>,<mode>]

where <regexp> would be :

/^(\w+)\[(\d+)\] ([^:]+): Failed to authenticate on (\w+) to '((\d+)@(\w+))' \(Tries (\d+)\)/$4($5) Failed $8 times/

such a regexp could be referenced by a name from a configuration file
with a simple interpolation scheme.

What do you think about this ?

[zalex_ua]

I use truncated names because they are also used in syslog configuration files and syslog/rsyslog man pages.
However, I agree that long names would be better in Web interface.
I have integrated your suggestion in en_gb.inc.php.patch.
Severities in keys are checked using pattern matching, 'warn' and 'warning' will both match.
So you can write syslog[,,warn] or syslog[,,warning]
I have completed README file.

I see only one advantage in shorter names - shorter triggers expression. Again, that i would recommend to start using the full names everywhere (including in source code of Zbxlog).

I have kept it separated from zbxlog.pl because I don't have a "good" solution yet.
Should I use direct DB access, Zabbix API or extend Zabbix agent protocol ?
Current solution (DB access) is mysql specific and should be made DB independant.
I am not very familiar with Zabbix API and I don't know if I could efficiently retrieve all syslog items this way.
Extending Zabbix protocol would be the best way but, not beeing a Zabbix core developer, I am reluctant to touch zabbix_server code.
Or maybe there is a better solution I have not imagined yet...
This first release is a "proof of concept" that needs some improvements.

I think that few people use Zabbix API so it's even worse than direct queries to the DB.
Do not even aware et a possibility to get something you need by using the API, and if in the future you want to do something better or differently, but the API will not have these functions - then there will be a dead end.
Those who need - can change the code of several queries according to their type of database.
Extend Zabbix agent protocol - precisely for these purposes I think this is unrealistic (meaning the inclusion of this in the original source).

Glad to see that zbxlog can be useful !

It is possible that I still finished their development. It will certainly be much easier, but perhaps it will be an advantage
I think the more worthy of such decisions - the better. The more I started to do this for a long time, but in connection with participation in other areas to improve Zabbix, I can not finish until the end.
Not the last moment will be testing the performance and workload of the physical server with intensive flow of events.

Hi,
I agree that it would be better to differentiate all 8 levels. But, at first glance, it would need patches not only in CSS but also in PHP code.
My first goal was to make it useful enough without patching too much code.

I think that we will prove to Zabbix core developers that these changes need to be included in the source code, including pick up eight individual colors (add 4 more colors to the 4 existing). So prepare patches for this I think is right. I do not see any need to patch the source of zabbix_server, need patching frontend only.

but my suggestion was that you take profit of the fact that if you run the regexp then you have a matched context right at end.

So rewriting it to look more closely to the eventlog you can have a syntax similar to that :

syslog[<name>,<regexp>,<severity>,<facility|source>,<eventid><maxlines>,<mode>]

where

• name is one of your zabbix key item of type 'log'
• severity could be either a string or a regexp group match ($<n>)
• facility could be either the default facility, a string, a $<n>
• eventid could be a string or a $<n> group match

I do not agree with you, at first I also thought about the fact that Alixen has not chosen the most accurate line adopted by the logic and syntax, but then I still agreed with him. That's the best. First parameter Facility (stored in zabbix as "source") - is very good solution IMHO.
Most did not understand what "group match ($ <n>)" as well as the "eventid"
You forgot to suggest that would <mode>

Let apply to an example (Asterisk based)

a syslog line like :

NOTICE[6728] chan_sip.c: Failed to authenticate on REGISTER to '0123456789@domain' (Tries 3)

could get inside a Zabbix Server as a log entry like this :
Key : Asterisk (supposing such a zabbix item of type Log exists)
Value : REGISTER(0123456789@domain) Failed 3 times
Severity : NOTICE
Source : chan_sip.c
EventID : 6728

with a line like :

syslog[Asterisk,<regexp>,$1,$3,$2<maxlines>,<mode>]

You're probably not very closely work with Sylog, you probably are not familiar with its structure of communications under the RFC. Of the syslog UDP-packet impossible to know what Asterisk is, or what else, there is only facilities according to RFC.

[alixen]

Hi zalex_ua and whisky,

I have just released v0.2 of zbxlog (http://www.alixen.org/attachments/do...bxlog-r0.2.tgz)

It contains only a few enhancements as suggested by zalex_ua (use full names for severity levels in Web interface and optimize request to zabbix server).

Before discussing the other suggestions you have made, I need to clarify the goals of this project:

• Raise the level of support of syslog messages by Zabbix to the same level as Windows events (with eventlog).
• Make it as easy to use as possible : once zbxlog is setup and running, all configuration is done through Zabbix Web interface.
• Since this project is not an official Zabbix project, limit patches to Zabbix code in order to avoid problems in future releases of Zabbix.

zalex_ua, a "wildcard" host is an interesting suggestion, it may be a way to not miss important messages from a misconfigured host. However, zbxlog currently does not modify the data it receives; it just sends it (or not) to Zabbix. If these data are sent to a wildcard host, zbxlog needs to at least append host name or IP to message detail in order to identify its origin.
I currently use a simple template with one item (syslog[]) that I have linked to all hosts via mass update as a "catchall" item.
I'm still thinking on a way to define a wildcard host that will be easy to setup (no extra configuration in zbxlog, only in Zabbix Web interface).
Maybe I can add a new item (we may call it sysloglost ) that will receive all messages that don't match any other item. You'll then get your wildcard host by adding that item to some host.

whisky, your idea of using patterns to rewrite syslog message is very interesting but goes far beyond what a syslog item is. A 'syslog' item provides a very simple mapping between syslog message original content and Zabbix log item.
syslog message as defined by RFC has four elements:

• timestamp
• facility
• severity
• detail

zbxlog just maps them to zabbix log fields. I think it should keep this simple mapping.
As for wildcard host, I think that adding a new item type will make it easier to understand that they have different goals:

• syslog[] => simple mapping, no rewrite
• newitem[] => complex mapping, content rewriting

However, I would like to avoid the use of an auxiliary configuration file. The more we can do through Web GUI, the better.

Thank you for your comments,
Alixen

[alixen]

Hi zalex_ua,

I was answering to your previous post while you posted this one.

I see only one advantage in shorter names - shorter triggers expression. Again, that i would recommend to start using the full names everywhere (including in source code of Zbxlog).

Currently (in release 0.2), full names can be used as item parameter.
I have also replaced short names in Web GUI with full names.
I don't think I need to do more changes in the code.

I think that few people use Zabbix API so it's even worse than direct queries to the DB.
Do not even aware et a possibility to get something you need by using the API, and if in the future you want to do something better or differently, but the API will not have these functions - then there will be a dead end.
Those who need - can change the code of several queries according to their type of database.
Extend Zabbix agent protocol - precisely for these purposes I think this is unrealistic (meaning the inclusion of this in the original source).

I agree with you, I think that my next step will be to move database access to Perl code and get rid of crontab and shell scripts. We will even win some DBMS independence with Perl DBI.

It is possible that I still finished their development. It will certainly be much easier, but perhaps it will be an advantage
I think the more worthy of such decisions - the better. The more I started to do this for a long time, but in connection with participation in other areas to improve Zabbix, I can not finish until the end.
Not the last moment will be testing the performance and workload of the physical server with intensive flow of events.

In case of heavy load due to syslog processing, Zbxlog can be installed on a dedicated server.
My test environment is a VM with Zabbix server, DB and Zbxlog collecting syslog messages from 6 hosts. Load average is 0.0

I think that we will prove to Zabbix core developers that these changes need to be included in the source code, including pick up eight individual colors (add 4 more colors to the 4 existing). So prepare patches for this I think is right. I do not see any need to patch the source of zabbix_server, need patching frontend only.

I agree with you, I don't think that zabbix_server needs to be patched only CSS and PHP.

I do not agree with you, at first I also thought about the fact that Alixen has not chosen the most accurate line adopted by the logic and syntax, but then I still agreed with him. That's the best. First parameter Facility (stored in zabbix as "source") - is very good solution IMHO.
Most did not understand what "group match ($ <n>)" as well as the "eventid"
You forgot to suggest that would <mode>

You're probably not very closely work with Sylog, you probably are not familiar with its structure of communications under the RFC. Of the syslog UDP-packet impossible to know what Asterisk is, or what else, there is only facilities according to RFC.

As I answered in my previous post, message handling as suggested by whisky is interesting but should be dealt by a different kind of item.

Regards,
Alixen

[zalex_ua]

I think that my next step will be to move database access to Perl code and get rid of crontab and shell scripts.

After that, I'll try in a real work of your decision.

My test environment is a VM with Zabbix server, DB and Zbxlog collecting syslog messages from 6 hosts. Load average is 0.0

0.0 is nice number , but need to make special testing (manually generated bulk of syslog message, for example 100-500 per second)

I agree with you, I don't think that zabbix_server needs to be patched only CSS and PHP.

I want to try to select additional colors and make patches for CSS. You have not yet done?

[*]Since this project is not an official Zabbix project, limit patches to Zabbix code in order to avoid problems in future releases of Zabbix.

When we work it out all the details, I hope developers will agree to include patches in the original code. This does not prevent anything, only extends some of the capabilities of the Web interface.
By the way, speaking to the developers, would like to hear at least what it your opinion. The most important thing - you're willing to add severity levels in the new range, ie add 10-17? It is now the most important for proper development of ideas and to avoid remaking the future.
Give the answer please.

If these data are sent to a wildcard host, zbxlog needs to at least append host name or IP to message detail in order to identify its origin.

This is absolutely the right decision. In my script for snmp-traps i do some like this:

 if ($zabbix_host eq $wildcard_host) {
            $str = "--------- Unknown HOST ---------  ($ipaddress)".$str;

I think is no need to resolve and include Hostname.

I'm still thinking on a way to define a wildcard host that will be easy to setup (no extra configuration in zbxlog, only in Zabbix Web interface).
Maybe I can add a new item (we may call it sysloglost ) that will receive all messages that don't match any other item. You'll then get your wildcard host by adding that item to some host.

hmm... Very good and fresh idea. But item Key maybe somthing like: syslog_homeless, syslog_outcast ? "lost" is not the most precise definition IMHO.

However, I would like to avoid the use of an auxiliary configuration file. The more we can do through Web GUI, the better.

I agree with you.


Alixen, and lastly, do you plan to fill EventID as I suggested above?
This can be very useful for simple construction of triggers, as it includes both value of the parameter Severity and Facility in one numeric.
Of course after the closing here of the simple my future request https://support.zabbix.com/browse/ZBXNEXT-448

heh... more quoted topics than this for the entire forum, I have not seen

[alixen]

Hi,

After that, I'll try in a real work of your decision.


0.0 is nice number , but need to make special testing (manually generated bulk of syslog message, for example 100-500 per second)

I agree with you, as soon as the core of the code is stabilized, I'll start load testing.

I want to try to select additional colors and make patches for CSS. You have not yet done?

No, I'am currently working on integrating DB access in Perl.

When we work it out all the details, I hope developers will agree to include patches in the original code. This does not prevent anything, only extends some of the capabilities of the Web interface.
By the way, speaking to the developers, would like to hear at least what it your opinion. The most important thing - you're willing to add severity levels in the new range, ie add 10-17? It is now the most important for proper development of ideas and to avoid remaking the future.
Give the answer please.

I would be really happy if all these patches code be integrated in original code and 10-17 range reserved for syslog severity levels.

This is absolutely the right decision. In my script for snmp-traps i do some like this:

 if ($zabbix_host eq $wildcard_host) {
            $str = "--------- Unknown HOST ---------  ($ipaddress)".$str;

I think is no need to resolve and include Hostname.



hmm... Very good and fresh idea. But item Key maybe somthing like: syslog_homeless, syslog_outcast ? "lost" is not the most precise definition IMHO.

Next release will integrate DB access in Perl only.
I don't plan to add new item types in the short term but I keep this idea in the roadmap.

Alixen, and lastly, do you plan to fill EventID as I suggested above?
This can be very useful for simple construction of triggers, as it includes both value of the parameter Severity and Facility in one numeric.
Of course after the closing here of the simple my future request https://support.zabbix.com/browse/ZBXNEXT-448

heh... more quoted topics than this for the entire forum, I have not seen

Yes !
It will be a simple modification.

Regards,
Alixen

[whisky]

Hi zalex_ua and whisky,

I have just released v0.2 of zbxlog (http://www.alixen.org/attachments/do...bxlog-r0.2.tgz)

great work thanks again for your time.

.......


However, I would like to avoid the use of an auxiliary configuration file. The more we can do through Web GUI, the better.

This last sentence make me thinks that we are perhaps not talking on the same place of zblog in an architecture, for me it is on a client machine that this process is taking place, so the added configuration burden (and I admit mismatch could happen here -- your goal is of higher quality here).

That’s also why its important to choose a different item for filtering/transforming those events and keep the zabbix server configuration untouched (but for the added severity level to be conformant to industry standards).

The transformation is important because you can then do some site configuration mapping different because those site settings are different but the need for log and trigger could be the same on the Zabbix server.