logging.html.in 8.9 KB
Newer Older
1 2 3 4 5 6
<?xml version="1.0"?>
<html>
  <body>
    <h1 >Logging in the library and the daemon</h1>
    <p>Libvirt includes logging facilities starting from version 0.6.0,
       this complements the <a href="errors.html">error handling</a>
7
       mechanism and APIs to allow tracing through the execution of the
8
       library as well as in the libvirtd daemon.</p>
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
    <ul>
      <li>
        <a href="#log_library">Logging in the library</a>
      </li>
      <li>
        <a href="#log_config">Configuring logging in the library</a>
      </li>
      <li>
        <a href="#log_daemon">Logging in the daemon</a>
      </li>
      <li>
        <a href="#log_syntax">Syntax for filters and output values</a>
      </li>
      <li>
        <a href="#log_examples">Examples</a>
      </li>
    </ul>
    <h3>
      <a name="log_library">Logging in the library</a>
    </h3>
29 30 31 32
    <p>The logging functionalities in libvirt are based on 3 key concepts,
       similar to the one present in other generic logging facilities like
       log4j:</p>
    <ul>
33
      <li><b>log messages</b>: they are information generated at runtime by
34
          the libvirt code. Each message includes a priority level (DEBUG = 1,
35 36
          INFO = 2, WARNING = 3, ERROR = 4), a category, function name and
          line number, indicating where it originated from, and finally
37
          a formatted message.  In addition the library adds a timestamp
38 39
          at the beginning of the message</li>
      <li><b>log filters</b>: a set of patterns and priorities to accept
40
          or reject a log message.  If the message category matches a filter,
41 42 43
          the message priority is compared to the filter priority, if lower
          the message is discarded, if higher the message is output. If
          no filter matches, then a general priority level is applied to
44 45 46
          all remaining messages. This allows, for example, capturing all
          debug messages for the QEmu driver, but otherwise only allowing
          errors to show up from other parts.</li>
47
      <li><b>log outputs</b>: once a message has gone through filtering a set of
48 49 50
          output defines where to send the message, they can also filter
          based on the priority, for example it may be useful to output
          all messages to a debugging file but only allow errors to be
51
          logged through syslog.</li>
52
    </ul>
53 54 55 56 57 58 59 60 61 62
    <p>Note that the logging module saves all logs to a <b>debug buffer</b>
       filled in a round-robin fashion as to keep a full log of the
       recent logs including all debug. The debug buffer can be resized
       or deactivated in the daemon using the log_buffer_size variable,
       default is 64 kB. This can be used when debugging the library
       (see the virLogBuffer variable content).</p>

    <h3>
      <a name="log_config">Configuring logging in the library</a>
    </h3>
63
    <p>The library configuration of logging is through 3 environment variables
64 65 66 67 68 69 70 71 72 73
    allowing to control the logging behaviour:</p>
    <ul>
      <li>LIBVIRT_DEBUG: it can take the four following values:
      <ul>
        <li>1 or "debug": asking the library to log every message emitted,
            though the filters can be used to avoid filling up the output</li>
        <li>2 or "info": log all non-debugging informations</li>
        <li>3 or "warn": log warnings and errors, that's the default value</li>
        <li>4 or "error": log only error messages</li>
      </ul></li>
74 75
      <li>LIBVIRT_LOG_FILTERS: defines logging filters</li>
      <li>LIBVIRT_LOG_OUTPUTS: defines logging outputs</li>
76
    </ul>
77 78 79 80
    <p>Note that, for example, setting LIBVIRT_DEBUG= is the same as unset. If
       you specify an invalid value, it will be ignored with a warning. If you
       have an error in a filter or output string, some of the settings may be
       applied up to the point at which libvirt encountered the error.</p>
81 82 83
    <h3>
      <a name="log_daemon">Logging in the daemon</a>
    </h3>
84
    <p>Similarly the daemon logging behaviour can be tuned using 3 config
E
Eric Blake 已提交
85
    variables, stored in the configuration file:</p>
86 87 88 89 90 91 92 93
    <ul>
      <li>log_level: accepts the following values:
      <ul>
        <li>4: only errors</li>
        <li>3: warnings and errors</li>
        <li>2: informations, warnings and errors</li>
        <li>1: debug and everything</li>
      </ul></li>
94 95
      <li>log_filters: defines logging filters</li>
      <li>log_outputs: defines logging outputs</li>
96
    </ul>
97 98 99
    <p>When starting the libvirt daemon, any logging environment variable
       settings will override settings in the config file. Command line options
       take precedence over all. If no outputs are defined for libvirtd, it
100 101
       defaults to logging to /var/log/libvirt/libvirtd.log (before 0.9.0
       it was using syslog) when it is running as a daemon, or to
102 103 104 105 106
       stderr when it is running in the foreground.</p>
    <p>Libvirtd does not reload its logging configuration when issued a SIGHUP.
       If you want to reload the configuration, you must do a <code>service
       libvirtd restart</code> or manually stop and restart the daemon
       yourself.</p>
107 108 109 110 111 112 113 114
    <p>Starting from 0.9.0, the daemon can save all the content of the debug
       buffer to the defined error channels (or /var/log/libvirt/libvirtd.log
       by default) in case of crash, this can also be activated explicitly
       for debugging purposes by sending the daemon a USR2 signal:</p>
       <pre>killall -USR2 libvirtd</pre>
    <h3>
      <a name="log_syntax">Syntax for filters and output values</a>
    </h3>
115 116
    <p>The syntax for filters and outputs is the same for both types of
       variables.</p>
117 118 119 120
    <p>The format for a filter is one of:</p>
    <pre>
  x:name  (log message only)
  x:+name (log message + stack trace)</pre>
121 122 123 124 125 126
    <p>where <code>name</code> is a string which is matched against source
    file name, e.g., <code>remote</code>, <code>qemu</code>, or
    <code>util/json</code>, the optional <code>+</code> prefix tells libvirt
    to log stack trace for each message matching <code>name</code>, and
    <code>x</code> is the minimal level where matching messages should
    be logged:</p>
127 128 129 130 131 132
    <ul>
      <li>1: DEBUG</li>
      <li>2: INFO</li>
      <li>3: WARNING</li>
      <li>4: ERROR</li>
    </ul>
133
    <p>Multiple filters can be defined in a single string, they just need to be
134 135
    separated by spaces, e.g: <code>"3:remote 4:event"</code> to only get
    warning or errors from the remote layer and only errors from the event
E
Eric Blake 已提交
136
    layer.</p>
137 138 139 140
    <p>If you specify a log priority in a filter that is below the default log
       priority level, messages that match that filter will still be logged,
       while others will not. In order to see those messages, you must also have
       an output defined that includes the priority level of your filter.</p>
141 142 143 144 145
    <p>The format for an output can be one of those 3 forms:</p>
    <ul>
      <li><code>x:stderr</code> output goes to stderr</li>
      <li><code>x:syslog:name</code> use syslog for the output and use the
      given <code>name</code> as the ident</li>
146
      <li><code>x:file:file_path</code> output to a file, with the given
147 148 149 150 151 152 153 154 155
      filepath</li>
    </ul>
    <p>In all cases the x prefix is the minimal level, acting as a filter:</p>
    <ul>
      <li>1: DEBUG</li>
      <li>2: INFO</li>
      <li>3: WARNING</li>
      <li>4: ERROR</li>
    </ul>
156
    <p>Multiple output can be defined, they just need to be separated by
157
       spaces, e.g.: <code>"3:syslog:libvirtd 1:file:/tmp/libvirt.log"</code>
158
       will log all warnings and errors to syslog under the libvirtd ident
159
       but also log all debug and information included in the
160
       file <code>/tmp/libvirt.log</code></p>
161 162 163
    <h3>
      <a name="log_examples">Examples</a>
    </h3>
164 165
    <p>For example setting up the following:</p>
    <pre>export LIBVIRT_DEBUG=1
166
export LIBVIRT_LOG_OUTPUTS="1:file:virsh.log"</pre>
167 168 169 170 171 172 173 174 175
    <p>and then running virsh will accumulate the logs in the
    <code>virsh.log</code> file in a way similar to:</p>
    <pre>14:29:04.771: debug : virInitialize:278 : register drivers
14:29:04.771: debug : virRegisterDriver:618 : registering Test as driver 0</pre>
    <p>the messages are timestamped, there is also the level recorded,
    if debug the name of the function is also printed and then the formatted
    message. This should be sufficient to at least get a precise idea of
    what is happening and where things are going wrong, allowing to then
    put the correct breakpoints when running under a debugger.</p>
176 177
    <p>To activate full debug of the libvirt entry points, utility
    functions and the QEmu/KVM driver, set:</p>
178 179
    <pre>log_filters="1:libvirt 1:util 1:qemu"
log_outputs="1:file:/var/log/libvirt/libvirtd.log"</pre>
180 181 182 183 184 185 186
    <p>in libvirtd.conf and restart the daemon will allow to
    gather a copious amount of debugging traces for the operations done
    in those areas.</p>
    <p>On the other hand to deactivate the logbuffer in the daemon
    for stable high load servers, set</p>
    <pre>log_buffer_size=0</pre>
    <p>in the libvirtd.conf.</p>
187 188
  </body>
</html>
反馈
建议
客服 返回
顶部