Skip to content
This repository has been archived by the owner on Jun 13, 2020. It is now read-only.

Latest commit

 

History

History
84 lines (58 loc) · 3.75 KB

config.md

File metadata and controls

84 lines (58 loc) · 3.75 KB

Configuration

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.

Command Line Options

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.

Accessing Configuration Values

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]

Notable Configuration Values

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.

Elasticsearch configuration

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.

Icinga Support

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.