Pulling Strings With Puppet - James Turnbull [42]
• Applied: Total resources that were applied
• Failed: Total resources that were not successfully applied
• Restarted: Total resources that were restarted through dependency changes
• Failed Restarts: Total resources that failed to be restarted after dependency changes
• Change metric showing the total number of changes that occurred in the transaction
In Listing 5-1, you can see an example of a Puppet transaction report.
In Listing 5-1, you can see the YAML file is divided into sections. The first section contains any log messages, and the following sections detail the value of each metric that Puppet collects. Each metric has a label, name, and values that make it easy to parse the data if you wish to make use of it for reporting or manipulation. The YAML format is very well supported by Ruby and can be easily utilized in Ruby to make use of Puppet reporting data.
Configuring Reporting
In order to get Puppet to output the reports we want, we need to configure it correctly. By default, each client is configured not to report back to the master, and reporting needs to be enabled. The first step to doing this is to ensure that the puppetd daemon on the client is started with the -- report option like so:
This will cause the puppetd daemon to start creating and sending reports to the master. You could also set the report option in the puppet. conf configuration file:
Tip - By default, the client will send the reports back to the master configuring it. You can set up a separate Puppet master for reports only, if you like. You can then direct all reports to this server by using the reportserver option on the client. We'll discuss this in more detail in Chapter 6.
By default, the reports generated by the client will be sent to the master and stored as YAML-formatted files in the report directory. These files are the output of the default report processor, store. Reports are written into subdirectories under the report directory and a directory created for each client that is reporting. Report file names are the date stamp when the report was generated and are suffixed with . yaml, for example, 200710130604. yaml.
The report directory is $vardir/reports (usually /var/puppet/reports on most distributions), but you can override this by configuring the reportdir option on the master puppet.conf configuration file, like so:
Here we've set the new report directory to /etc/puppet/reports. You can specify whichever directory suits your environment.
Report Processors
There a number of different report processors available on the master server. The default report, store, simply stores the report file on the disk. There is also the log processor that sends logs to the local log destination, for example, to syslog. Also available is the tagmail report processor that sends e-mail messages based on particular tags in transaction reports. Lastly, the rrdgraph report processor converts transaction reports into RRD-based graphs.
Selecting which report processors will run is done using the reports configuration option in the puppet. conf configuration file.
Each report processor you want to enable should be listed in the reports option with multiple processors separated by commas. By default, only store is enabled. You can also enable report processors on the command line.
log
The log report processor sends the log entries from transaction reports to syslog. It is the most simple of the report processors. The syslog destination facility is controlled by the syslogfacility configuration option, which defaults to the daemon facility.
On the previous line, we've directed all syslog output to the user facility.
Note - The log report processor only logs entries if the Puppet master is running in daemon mode. If you keep it running in the foreground, no syslog messages will be generated.
tagmail
The tagmail report sends log messages via e-mail based on the tags that are present in each log message. Remember, as we discussed in Chapter 3, tags allow you to set context for your resources; for example,