Teach you to read the OpenStack logs-5 minutes a day to play OpenStack (29)

The entire life cycle of instance from creation to deletion is managed by Nova.
In the following sections, we take the different operational scenarios in the instance life cycle as an example to analyze in detail how the different Nova components work together and deepen your understanding of Nova through log analysis.

Before we study Nova's operations, let's start by learning one important thing: the OpenStack logs.
OpenStack's log records very detailed details and is a powerful tool for learning and troubleshoting.

Location of the log

Our experimental environment uses DEVSTACK, logs are unified in the/opt/stack/logs directory, each service has its own log files, from the name is easy to distinguish.

For example, nova-* each sub-service log begins with "n":
N-api.log is Nova-api's log.
N-cpu.log is a log of nova-compute.

The Glance log file is preceded by "G":
G-api.log is Glance-api's log.
G-reg.log is a log of glance-registry.

The logs of Cinder and Neutron begin with "C" and "Q" respectively.

For OpenStack that is not devstack installed, the log is typically placed in the/var/log/xxx/directory.
For example, Nova placed under the/var/log/nova/, Glance placed under the/var/log/glance ...

The log files for each sub-service are also saved separately, and the naming is also very canonical and easy to distinguish.
For example, Nova-api's log is generally named/var/log/nova/api.log, and other logs are similar.

Format of the Log

The log format for OpenStack is uniform, as follows

The following examples illustrate

This log we can learn:

1. The code module is nova.virt.libvirt.config, so it should be Hypervisor Libvirt related operations
2. Log content is generated by XML
3. If you want to trace the source code, you can go to the/opt/stack/nova/nova/virt/libvirt/config.py 82 line, by To_xml

Another example is the following log:

This log we can learn:

1. This is an ERROR log
2. Specific content is "No compute node record for host Devstack-controller"
3. The log does not indicate the source code location

A few notes about the log

1. Do I need to read the logs to learn OpenStack? The answer to this question depends on who you are.
   If you are only an OpenStack end user, then the log is not important to you. You only need to operate on the GUI, if the problem directly to find the administrator.
   But if you're an OpenStack operations and Management officer, the logs are very important to you. Since OpenStack operations are error-prone, the error messages given on the GUI are very general and concise, and the logs provide a lot of clues, especially when the debug option is turned on.
   If you are in the learning phase of OpenStack, as we are now, it is highly recommended that you look at the logs too. Logs can help you gain a deeper understanding of how OpenStack works.

2. Logs can help us learn more about OpenStack and troubleshoot problems. But there is a premise to using logs efficiently:
   The operating mechanism of OpenStack must be mastered before you can view the logs in a targeted direction.
   Take Instance Launch operation, if previously did not understand the nova-* sub-services in the operation of the collaborative relationship, if not understand the flowchart, faced with so many and scattered log files, we are very difficult to start.

3. For OpenStack operations and administrators, in most cases, we don't need to look at the source code.
   Because OpenStack logs are detailed enough to help us analyze and locate the problem.
   But there are still some detail logs that are not documented and can be understood more clearly by looking at the source code if necessary.
   Even so, the log will provide us with clues to source code, and we don't need to find a needle in the haystack.
   This is what we'll see in the operational analysis that follows.

Teach you to read the OpenStack logs-5 minutes a day to play OpenStack (29)