TWiki> LCG Web>WLCGMonitoringConsolidation>NagConf (revision 2)EditAttachPDF


This page documents the tools we use for configuring Nagios headnodes. There are two specific usecases
  • Configuring Nagios for a single VO (ie those instances managed by IT-SDC-MI).
  • Configuring Nagios at a grid site (quite possibly for more than one VO).



This script does the main work of configuring a Nagios instance. In production environments, this will most likely be executed by a cronjob, but can be called on the command line with the following parameters.
  • --vo: (Mandatory). Specify a single VO or list of comma separated VOs (e.g. atlas,cms)
  • --poem: (Optional). The POEM URL is hardcoded into parser.rb, but can be overridden with this command line option
  • --site: (Optional). If provided, Nagios will only be configured for the specified site's nodes. Use the GOCDB-registered name for the site.
  • --confdir: (Optional). Location to store Nagios configuration. Defaults to /etc/nagios/nagconf

Execution logic

  1. From getPOEM(), get the POEM XML data and store it in a nested hash (@poem_hash). An md5 checksum is calculated of the XML data (and the XML itself stored in a temporary file) so we know if it has changed since the last execution.
  2. For each VO that we want to configure
    1. With getVOfeed(), get the VO feed (as before, calculating an md5 checksum and storing the XML in a file) and create two lists and a hash:
      • The list @all_sites contains a simple list of all sites in the VO feed or, if the --site parameter was passed on the command line, the single site that we're configuring Nagios for. This is only used by template_host.groups.erb file to create the Nagios host.groups.cfg file.
      • The list @all_flavours contains all service flavours for the site(s) we're interested in. It is used to create hostgroups and servicegroups (ie by template_host.groups.erb and template_service.groups.erb).
      • @atp_hash is a nested hash. Each top-level key is a site name, which points to a sub-hash containing mappings between hostnames and their corresponding service flavours. This is used by all .erb files in one way or another.
    2. Run buildNagios() which is responsible for reading in the configuration files provided by the ncg-metric-config and grid-monitoring-probes rpms. This function is also responsible for running the .erb template files to generate the Nagios config.
  3. Once all config files have been generated, the temporary files containing XML are renamed, so that their md5 checksums can be calculated the next time parser.rb runs. This allows us to decide whether the POEM or VO feed data have changed since last execution.

*.erb files

*.templates.cfg files

To do

  • Hard-code the cms.conf etc locations, rather than use current directory
  • Write to and then validate before restarting nagios - not sure if this is possible (nagios.conf would need to have entry?) How about: move old config to nagconf.old; write new config in nagconf; if nagios -v succeeds great! else move nagconf -> broken and move nagconf.old -> nagconf...
  • Recently implemented multiple VOs. This is probably going to result in duplicated configuration objects in the *.host.cfg files, but will likely only affect site-specific installations.
Edit | Attach | Watch | Print version | History: r7 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2013-10-17 - MikeKenyon
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback