[libvirt] [PATCH 4/5] Add detailed error information to journal

[Daniel P. Berrange]

On Wed, Oct 17, 2012 at 08:17:17PM +0200, Miloslav Trmač wrote:
> When logging an error, don't throw away the detailed information.
> Example record when using the journald output:
> 
>         MESSAGE=Domain not found
>         PRIORITY=4
>         LIBVIRT_SOURCE=error
>         CODE_FILE=../../src/test/test_driver.c
>         CODE_LINE=1405
>         CODE_FUNC=testLookupDomainByName
>         DOMAIN=12
>         CODE=42
>         STR1=Domain not found
>         STR2=
> 
> The format used in other output destinations (e.g. "syslog", "file") is
> still unchanged.
> 
> The "domain" and "code" numbers are part of the libvirt ABI in
> <libvirt/virterror.h>; therefore log processing tools can rely on them,
> unlike the text log string (which is translated depending on locale,
> and may be modified for other reasons as well).
> 
> Alternatively, the "domain" and "code" fields could contain strings
> instead of numbers, but it's not clear that it's worth it:
> Advantages of numbers:
> * the numbers are shorter
> * the ABI guarantees that the numbers won't change
> Disadvantages of strings:
> * adding a ABI-stable string mapping for virErrorNumber would result
>   in additional work each time a new error number is added
>   (note that virErrorMsg cannot be used for this because it is
>   translated)
> * a change in the string mapping would be less likely to be noticed
> The advantage of using strings is more readability, but note that the
> "msg" field above already contains a readable description of the
> error.

Agreed, the numeric values are the only part we want to consider
ABI stable. We have often changed the string values, even for
the error codes.

> @@ -676,10 +678,39 @@ virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED,
>      priority = virErrorLevelPriority(level);
>      if (virErrorLogPriorityFilter)
>          priority = virErrorLogPriorityFilter(to, priority);
> +
> +    i = 0;
> +#define META_ADD_STRING(KEY, VALUE)             \
> +    do {                                        \
> +        meta[i].key = (KEY);                    \
> +        meta[i].s = (VALUE);                    \
> +        i++;                                    \
> +    } while (0)
> +#define META_ADD_INT(KEY, VALUE)                \
> +    do {                                        \
> +        meta[i].key = (KEY);                    \
> +        meta[i].s = NULL;                       \
> +        meta[i].i = (VALUE);                    \
> +        i++;                                    \
> +    } while (0)
> +
> +    META_ADD_INT("DOMAIN", domain);
> +    META_ADD_INT("CODE", code);
> +    if (str1 != NULL)
> +        META_ADD_STRING("STR1", str1);
> +    if (str2 != NULL)
> +        META_ADD_STRING("STR2", str2);
> +    if (str3 != NULL)
> +        META_ADD_STRING("STR3", str3);
> +    if (int1 != -1)
> +        META_ADD_INT("INT1", int1);
> +    if (int2 != -1)
> +        META_ADD_INT("INT2", int2);

At this point in time, I would like us to leave out the str1, str2,
str3, int1 and int2 values. These are a badly defined part of our
error reporting system. My goal is that for each error code, we
will define explicit semantics for the str1/str2/str3/int1/int2
fields (or defined them to be unused).

For example, with VIR_ERR_SYSTEM_ERROR, we'll declare that 'int1'
is always the errno values. Once we have this kind of stuff defined,
then we can make the structured error reports contain the appropriate
extra fields for the code in question. So for VIR_ERR_SYSTEM_ERROR,
the structured error log would contain an 'errno' field instead
of an 'int1' field.

Can you re-submit, just this patch in the series, with those parts
commented out or removed.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|