Which Logs Should I Check When Things Go Wrong?

Editor's Note: Ruth Linehan has written an updated version of this post for Puppet Enterprise 3.7.

Perhaps you have seen the list of logs in the Puppet Enterprise docs, or you’ve gone rooting around in /var/log/ and have seen all the different logs PE has. If you have, you know: there are a lot. Figuring out which one to look in when something’s gone wrong can be difficult, so I hope this post will provide a little bit of insight into where you can look.

When Something Goes Wrong With the Console

• /var/log/pe-httpd/error.log — Check here if you’ve got a 500 error in the console, or if live management is behaving weirdly. Hopefully you’ll never encounter any of these problems, but if you've mis-typed a value in one of the config files for the console, this can happen. This log captures STDERR/STDOUT as well as where stack traces will show up for some console components.

• /var/log/pe-httpd/puppetdashboard.access.log — Along with error.log this can be useful for debugging issues in the console. It shows all the HTTP requests made with their status codes. Correlating the two might show you what HTTP request caused what issue.

• /var/log/pe-puppet-dashboard/production.log on the console node — If you’re having issues with reports uploading, using the ENC, or if you get a red box that says “Dashboard has encountered an error” when you try to reach the console.

When You're Having Problems With Authorization and Authentication

If you can’t log in to the console, or you’re having issues creating new users, or anything to do with users, you probably want to look in the /var/log/pe-console-auth directory. In here you’ll find 3 logs:

• auth.log shows users created/deleted/modified - any actions taken in the “My Account” or “Admin tools” pages
• cas_client.log is the RubyCAS client log. Its log level can be configured in /etc/puppetlabs/console-auth/config.yml
• cas.log is the RubyCAS server log. If you’re having any issues trying to configure external authentication options, this is where to check. You can set the debug level in /etc/puppetlabs/rubycas-server/config.yml.

When You're Having Problems With MCollective, Orchestration or Live Management

If you’re having any MCollective problems, look here to see whether MCollective is able to set up connections and handle messages:

• Check /var/log/pe-mcollective/mcollective.log or server.log on your puppet master. You can set the log level in /etc/puppetlabs/mcollective/server.cfg, and you should restart the pe-mcollective service after modifying that file.

• Check the MCollective client logs /var/lib/peadmin/.mcollective.d/client.log (on the puppet master, for command line user), and /var/log/pe-puppet-dashboard/mcollective_client.log (on the console node, for puppet-dashboard user, which is used by live management)

• Check /var/log/pe-activemq/activemq.log - pe-activemq log if you’re having any issues with configuring ActiveMQ. You can configure what is logged and at what level in /etc/puppetlabs/activemq/log4j.properties.

Check out Celia Cottle’s PuppetConf talk for more clues to help you troubleshoot problems with Puppet Enterprise.

Learn More

• Puppet Enterprise brings automation to configuration management. Learn how you can manage hundreds or thousands of nodes, eliminate configuration drift and manage every stage of your infrastructure lifecycle.
• Ready to give Puppet Enterprise a look? Download it and use it with 10 nodes for free.
• Are you using a CMDB or an inventory spreadsheet? Learn how to get rid of them and use Puppet Enterprise as your single source of infrastructure truth.