nagios-herald
supports a YAML-based configuration file. The configuration file is named
config.yml
and lives in the etc/
directory of this project. This project provides
an example configuration file that you can use to get started.
nagios-herald
provides several command line options, some of which can override values
in the configuration file. During runtime, nagios-herald
merges the configuration
and command line options into a single hash available through the code.
Command line options always override configuration file values, when there is a conflict.
All configuration file values and command line options are available in a single, globally
available hash named Config.config
. See below for an example configuration file.
# define the FQDN of servers we call on to provide context in notifications
servers:
ganglia: ganglia.example.com
graphite: graphite.example.com
splunk:
url: https://splunk.example.com:8089/services/search/jobs
username: splunkuser
password: splunkpass
elasticsearch:
url: http://logstash.example.com:9200
result_field_truncate: 200
To access the value for the Ganglia server URI, one would write code similar to the below:
ganglia_uri = Config.config[:servers][:ganglia]
Two of the most important configuration values are formatter_dir
and logfile
.
formatter_dir
(equivalent to the --formatter-dir
command line option) tells nagios-herald
where to locate your custom formatters. It will load those in addition to the built-in formatters.
Custom formatters are given precedence allowing formatter authors to override the built-in formatters.
logfile
tells nagios-herald where to log its output. This is especially critical to catch errors
should they arise. If nagios-herald isn't sending notifications, it's a bug; consult logfile
for
details. Optionally, setting trace
to true (equivalent to --trace
on the command line) will
provide a backtrace to aid in debugging.
Similar to the formatter_dir
option, message_dir
and helper_dir
can be used to specify
locations of your custom message classes and helper classes, respectively. These classes will get
loaded in addition to default messages and helpers.
The check_elasticsearch
formatter makes alerts generated by elasticsearch results more readable by including relevant information in emails like links to Kibana.
Here are some configuration options you can place under elasticsearch
in config.yml
.
url
- The URL of your elasticsearch API server (usually port 9200 on one of your elasticsearch nodes).
frontend_url
- The URL of your elasticsearch frontend (usually kibana).
fields_in_email
- Fields from an elasticsearch document that show up in alert emails. These fields give you a quick view of the log lines in your email inbox before you click through to your frontend.
result_field_truncate
- Truncate fields in elasticsearch to this length.
num_results
- The number of results to show in one alert email.
See config.yml.example for an example configuration file.
nagios-herald
relies on the environment variables set when a notification is sent.
Those variables are prefixed with NAGIOS_
. Icinga, a popular variant of Nagios,
prefixes those variables with ICINGA_
. To enable support for Icinga, set the
icinga
configuraion value:
icinga: true
If that value is set, calling Util#get_nagios_var
will replace NAGIOS_
with ICINGA_
in the environment variable's name.