There is an extensive collection of logs across an OpenStack cluster, and they are your best friend. Often a good place to start when an API call succeeds but the end result is not as you expect is to tail the log files of a component that you're having trouble with. You can do this as, or right after, you execute the command that you are seeing failure with. For example, if you are having trouble connecting to Keystone, it might not be running properly or might be throwing errors for some reason. Start a tail on /var/log/keystone/keystone.log and rerun the command that is failing. This is shown in the following command:

$ tail -fn0 /var/log/keystone/keystone.log

In this command, -f indicates that we follow the log or show new entries as they are added. The -n0 means show the most recent zero lines; in other words, any previous content in the file is suppressed so that you only see new entries when you run the command. All of the OpenStack components are going to have logs in /var/log/{component_name}/ except Swift-proxy, which will be in /var/log/messages. Horizon will have extra logs in Apache's log files at /var/log/httpd/*log.

As another example, if Nova is not launching an instance properly, there could be a problem with the API collecting enough information or a problem with the scheduler finding a place to put the running instance. Sometimes, it is helpful to tail all the logs in the log directory instead of just one. Tailing more than one log will get you output from all the services that are related to a component. This is shown in the following command:

$ tail -fn0 /var/log/nova/*.log

Notice here that *.log is indicated and not an asterisk. This is because if logrotate is rotating logs, there could be .gz files that you do not want to tail because they are binary. The tail's initial output will indicate what file a new entry is coming from, which will help you narrow down the service that needs a little help.

Often, the case is that one component is showing an error in its log, but the error is being generated by another component, and the error that you are trying to debug was a result of a call being made from one component to another. To debug this kind of behavior, it is helpful to know how components interact with each other. In the following sections, let's take a look at the major components in OpenStack for you to get a better idea of how they interact with each other so that you can effectively debug them.