- Introduction
- Deployment
- Configuration
- 23. Configuration overview
- 24. NXLog language
- 25. Reading and receiving logs
- 26. Processing logs
- 26.1. Parsing various log formats
- 26.2. Alerting
- 26.3. Using buffers
- 26.4. Character set conversion
- 26.5. Detecting an inactive agent or log source
- 26.6. Event correlation
- 26.7. Extracting data
- 26.8. Filtering logs
- 26.9. Format conversion
- 26.10. Log rotation and retention
- 26.11. Log classification
- 26.12. Parsing multi-line logs
- 26.13. Rate limiting and traffic shaping of logs
- 26.14. Rewriting and modifying logs
- 26.15. Timestamps
- 27. Forwarding and Storing Logs
- 28. Centralized Log Collection
- 29. NXLog failover mode
- 30. High Availability (HA)
- 31. Encrypted transfer
- 32. Reducing bandwidth and data size
- 33. Reliable message delivery
- 34. Compression and Encryption
- OS Support
- Integration
- Troubleshooting
- Enterprise Edition Reference Manual
- NXLog Manager
- NXLog Add-Ons
26.2. Alerting
NXLog can be configured to generate alerts when specific conditions are met. Here are some ways alerting could be implemented.
26.2.1. Sending messages to an external program
The om_exec module can pipe messages to an external program or script, which will be executed once the om_exec module has started. The external script is required to run continuously until the om_exec module is stopped and the pipe is closed. This functionality can be used for alerting.
In this example Output, all messages not matching the regular
expression are dropped, and remaining messages are piped to a custom
alerter script.
![[Download file]](images/icons/download_icon.png "Download file"){kind=icon}
1
2
3
4
5
6
<Output out>
Module om_exec
Command /usr/local/sbin/alerter
Arg -
Exec if not ($raw_event =~ /alertcondition/) drop();
</Output>
See also Sending to Executables.
26.2.2. Invoking a program for each message
The xm_exec module provides two procedures, exec() and exec_async(), for spawning an external program or script. The script is executed once for each call, and is expected to terminate when it has finished processing the message.
In this example Input, each message matching the regular expression is
piped to a new instance of alerter, which is executed asynchronously
(does not block additional processing by the calling module).
1
2
3
4
5
6
7
8
9
10
11
12
13
<Extension _exec>
Module xm_exec
</Extension>
<Input in>
Module im_tcp
Host 0.0.0.0
Port 1514
<Exec>
if $raw_event =~ /alertcondition/
exec_async("/usr/local/sbin/alerter");
</Exec>
</Input>
In this example, an email is sent using exec_async() when the regular expression condition is met.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Extension _exec>
Module xm_exec
</Extension>
<Input in>
Module im_tcp
Host 0.0.0.0
Port 1514
<Exec>
if $raw_event =~ /alertcondition/
{
exec_async("/bin/sh", "-c", 'echo "' + $Hostname + '\n\nRawEvent:\n' +
$raw_event + '"|/usr/bin/mail ' +
'-a "Content-Type: text/plain; charset=UTF-8" ' +
'-s "ALERT" user@domain.com');
}
</Exec>
</Input>
26.2.3. Generate an internal NXLog log message
NXLog can be configured to generate an internal log event when a specific condition is met. Internal log events can be generated with various severity levels using the log_error(), log_warning(), log_info(), and log_debug() procedures. Internal log messages will be written to the file specified by the global LogFile directive (according to the configured LogLevel) and will be generated by the im_internal module.
|
Note
|
DEBUG level events are not generated by the im_internal module. |
If a message matches the regular expression, an internal log event is generated with level WARNING.
1
2
3
4
5
<Input in>
Module im_file
File "/var/log/app.log"
Exec if $raw_event =~ /alertcondition/ log_warning("ALERT");
</Input>