SimGrid  3.17
Versatile Simulation of Distributed Systems
Simulation Logging

Log4J-like logging system.

Using printf or println to display information is possible, but quickly unpractical, as the logs of all processes get intermixed in your program's output. As an answer, the SimGrid logging module allow you to sort and filter the logs by emitter, by module and by gravity level.

The SimGrid logging module is highly configurable: as in Log4J, the user can choose at runtime what messages to show and what to hide, as well as how messages get displayed. It is also easy to use, both to the programmer (using preprocessor macros black magic) and to the user (with command line options). And finally, its performance is highly optimized.

Main Concepts

There is three main concepts in SimGrid's logging mechanism: category, priority and appender. These three concepts work together to enable developers to log messages according to message type and priority, and to control at runtime how these messages are formatted and where they are reported.

Logging categories

In SimGrid, the logs are sorted by topics (called categories) so that the user can chose which topics to display and hide at runtime. These categories are organized as a hierarchy, following the architecture of modules in the simulator.

The full list of all categories that exist in the SimGrid base library is available in the documentation. You can also provide --help-logs on the command line of any SimGrid simulator to see the list of all existing categories that it contains.

Logging priorities

The user can also specify the desired level of details for each category. This is controlled by the priority concept (which should maybe be renamed to severity). For example, you may want to see every debugging message of MSG while only being interested into the messages at level "error" or higher about the XBT internals.

Message appenders

The message appenders are in charge of actually displaying the message to the user. For now, four appenders exist:

  • the default one prints stuff on stderr
  • file sends the data to a single file
  • rollfile overwrites the file when the file grows too large
  • splitfile creates new files with a specific maximum size

Message layouts

The message layouts are the elements in charge of choosing how each message will look like. Their result is a string which is then passed to the appender attached to the category to be displayed.

For now, there is two layouts: The simple one, which is good for most cases, and another one allowing users to specify the format they want. Configuration provides more info on this.

History of this module

Historically, this module is an adaptation of the log4c project, which is dead upstream, and which I was given the permission to fork under the LGPL licence by the log4c's authors. The log4c project itself was loosely based on the Apache project's Log4J, which also inspired Log4CC, Log4py and so on. Our work differs somehow from these projects anyway, because the C programming language is not object oriented.

C Programmer interface

Please also refer to the full API for more information.

Constructing the category hierarchy

Every category is declared by providing a name and an optional parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT is the category's parent.

A category is created by a macro call at the top level of a file. A category can be created with any one of the following macros:

The parent cat can be defined in the same file or in another file (in which case you want to use the XBT_LOG_EXTERNAL_CATEGORY macro to make it visible in the current file), but each category may have only one definition. Likewise, you can use a category defined in another file as default one using XBT_LOG_EXTERNAL_DEFAULT_CATEGORY

Typically, there will be a Category for each module and sub-module, so you can independently control logging for each module.

For a list of all existing categories, please refer to the Existing log categories section. This file is generated automatically from the SimGrid source code, so it should be complete and accurate. Also refer to the full API for more information.

Declaring message priority

A category may be assigned a threshold priority. The set of priorities are defined by the e_xbt_log_priority_t enum. All logging request under this priority will be discarded.

If a given category is not assigned a threshold priority, then it inherits one from its closest ancestor with an assigned threshold. To ensure that all categories can eventually inherit a threshold, the root category always has an assigned threshold priority.

Logging requests are made by invoking a logging macro on a category. All of the macros have a printf-style format string followed by arguments. If you compile with the -Wall option, gcc will warn you for unmatched arguments, ie when you pass a pointer to a string where an integer was specified by the format. This is usually a good idea.

Here is an example of the most basic type of macro. This is a logging request with priority warning.

XBT_CLOG(MyCat, xbt_log_priority_warning, "Values are: %d and '%s'", 5, "oops");

A logging request is said to be enabled if its priority is higher than or equal to the threshold priority of its category. Otherwise, the request is said to be disabled. A category without an assigned priority will inherit one from the hierarchy.

It is possible to use any non-negative integer as a priority. If, as in the example, one of the standard priorities is used, then there is a convenience macro that is typically used instead. For example, the above example is equivalent to the shorter:

XBT_CWARN(MyCat, "Values are: %d and '%s'", 5, "oops");

Checking if a particular category/priority is enabled

It is sometimes useful to check whether a particular category is enabled at a particular priority. One example is when you want to do some extra computation to prepare a nice debugging message. There is no use of doing so if the message won't be used afterward because debugging is turned off.

Doing so is extremely easy, thanks to the XBT_LOG_ISENABLED(category, priority).

Using a default category (the easy interface)

If XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the category, then the even shorter form can be used:

XBT_WARN("Values are: %s and '%d'", 5, "oops");

Only one default category can be created per file, though multiple non-defaults can be created and used.

Putting all together: the easy interface

First of all, each module should register its own category into the categories tree using XBT_LOG_NEW_DEFAULT_SUBCATEGORY.

Then, logging should be done with the XBT_DEBUG, XBT_VERB, XBT_INFO, XBT_WARN, XBT_ERROR and XBT_CRITICAL macros.

Under GCC, these macro check there arguments the same way than printf does. So, if you compile with -Wall, the following code will issue a warning: XBT_DEBUG("Found %s (id %d)", some_string, a_double)

If you want to specify the category to log onto (for example because you have more than one category per file, add a C before the name of the log producing macro (ie, use XBT_CDEBUG, XBT_CVERB, XBT_CINFO, XBT_CWARN, XBT_CERROR and XBT_CCRITICAL and friends), and pass the category name as first argument.

The TRACE priority is not used the same way than the other. You should use the XBT_IN, XBT_OUT and XBT_HERE macros instead.

Example of use

Here is a more complete example:

#include "xbt/log.h"

/ * create a category and a default subcategory * /
XBT_LOG_NEW_CATEGORY(VSS);
XBT_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS);

int main() {
       / * Now set the parent's priority.  (the string would typically be a runtime option) * /
       xbt_log_control_set("SA.thresh:3");

       / * This request is enabled, because WARNING >= INFO. * /
       XBT_CWARN(VSS, "Low fuel level.");

       / * This request is disabled, because DEBUG < INFO. * /
       XBT_CDEBUG(VSS, "Starting search for nearest gas station.");

       / * The default category SA inherits its priority from VSS. Thus,
          the following request is enabled because INFO >= INFO.  * /
       XBT_INFO("Located nearest gas station.");

       / * This request is disabled, because DEBUG < INFO. * /
       XBT_DEBUG("Exiting gas station search");
}

Please also refer to the full API for more information.

User interface

Configuration

Although rarely done, it is possible to configure the logs during program initialization by invoking the xbt_log_control_set() method manually. A more conventional way is to use the –log command line argument. xbt_init() (called by MSG_init() and friends) checks and deals properly with such arguments.

Threshold configuration

The most common setting is to control which logging event will get displayed by setting a threshold to each category through the threshold keyword.

For example,

--log=root.threshold:debug

will make SimGrid extremely verbose while

--log=root.thres:critical

should shut it almost completely off.

Note that the threshold keyword can be abbreviated here. For example, all the following notations have the same result.

--log=root.threshold:debug
--log=root.threshol:debug
--log=root.thresho:debug
--log=root.thresh:debug
--log=root.thres:debug
--log=root.thre:debug
--log=root.thr:debug
--log=root.th:debug
--log=root.t:debug
--log=root.:debug     <--- That's obviously really ugly, but it actually works.

The full list of recognized thresholds is the following:

  • trace: enter and return of some functions
  • debug: crufty output
  • verbose: verbose output for the user wanting more
  • info: output about the regular functionning
  • warning: minor issue encountered
  • error: issue encountered
  • critical: major issue encountered

Passing several settings

You can provide several of those arguments to change the setting of several categories, they will be applied from left to right. So,

--log="root.thres:debug root.thres:critical"

should disable almost any logging.

Note that the quotes on above line are mandatory because there is a space in the argument, so we are protecting ourselves from the shell, not from SimGrid. We could also reach the same effect with this:

--log=root.thres:debug --log=root.thres:critical

Format configuration

You can control the format of log messages through the fmt keyword. For example,

--log=root.fmt:%m

reduces the output to the user-message only, removing any decoration such as the date, or the process ID, everything.

Here are the existing format directives:

  • %%: the % char
  • %n: platform-dependent line separator (LOG4J compatible)
  • %e: plain old space (SimGrid extension)
  • %m: user-provided message
  • %c: Category name (LOG4J compatible)
  • %p: Priority name (LOG4J compatible)
  • %h: Hostname (SimGrid extension)
  • %P: Process name (SimGrid extension – note that with SMPI this is the integer value of the process rank)
  • %t: Thread "name" (LOG4J compatible – actually the address of the thread in memory)
  • %i: Process PID (SimGrid extension – this is a 'i' as in 'i'dea)
  • %F: file name where the log event was raised (LOG4J compatible)
  • %l: location where the log event was raised (LOG4J compatible, like '%F:%L' – this is a l as in 'l'etter)
  • %L: line number where the log event was raised (LOG4J compatible)
  • %M: function name (LOG4J compatible – called method name here of course).
  • %d: date (UNIX-like epoch)
  • %r: application age (time elapsed since the beginning of the application)

If you want to mimic the simple layout with the format one, you would use this format: '[%h:%i:(%i) %r] %l: [%c/%p] %m%n'. This is not completely correct because the simple layout do not display the message location for messages at priority INFO (thus, the fmt is '[%h:%i:(%i) %r] [%c/%p] %m%n' in this case). Moreover, if there is no process name (ie, messages coming from the library itself, or test programs doing strange things) do not display the process identity (thus, fmt is '[%r] %l: [%c/%p] %m%n' in that case, and '[%r] [%c/%p] %m%n' if they are at priority INFO).

For now, there is only two format modifiers: the precision and the width fields. You can for example specify %.4r to get the application age with 4 numbers after the radix, or %15p to get the process name on 15 columns. Finally, you can specify %10.6r to get the time on at most 10 columns, with 6 numbers after the radix.

Note that when specifying the width, it is filled with spaces. That is to say that for example %5r in your format is converted to "% 5f" for printf (note the extra space); there is no way to fill the empty columns with 0 (ie, pass "%05f" to printf). Another limitation is that you cannot set specific layouts to the several priorities.

Category appender

You can control the appender of log messages through the app keyword. For example,

--log=root.app:file:mylogfile

redirects the output to the file mylogfile.

For splitfile appender, the format is

--log=root.app:splitfile:size:mylogfile_%.format

The size is in bytes, and the % wildcard will be replaced by the number of the file. If no % is present, it will be appended at the end.

rollfile appender is also available, it can be used as

--log=root.app:rollfile:size:mylogfile

When the file grows to be larger than the size, it will be emptied and new log events will be sent at its beginning

Any appender setup this way have its own layout format (simple one by default), so you may have to change it too afterward. Moreover, the additivity of the log category is also set to false to prevent log event displayed by this appender to "leak" to any other appender higher in the hierarchy. If it is not what you wanted, you can naturally change it manually.

Category additivity

The add keyword allows to specify the additivity of a category (see Appenders). '0', '1', 'no', 'yes', 'on' and 'off' are all valid values, with 'yes' as default.

The following example resets the additivity of the xbt category to true (which is its default value).

--log=xbt.add:yes

Misc and Caveats

  • Do not use any of the macros that start with '_'.
  • Log4J has a 'rolling file appender' which you can select with a run-time option and specify the max file size. This would be a nice default for non-kernel applications.
  • Careful, category names are global variables.
  • When writing a log format, you often want to use spaces. If you don't protect these spaces, they are used as configuration elements separators. For example, if you want to remove the date from the logs, you want to pass the following argument on the command line. The outer quotes are here to protect the string from the shell interpretation while the inner ones are there to prevent simgrid from splitting the string in several log parameters (that would be invalid).
    --log="'root.fmt:%l: [%p/%c]: %m%n'"
    Another option is to use the SimGrid-specific format directive %e for spaces, like in the following.
    --log="root.fmt:%l:%e[%p/%c]:%e%m%n"

Internal considerations

This module is loaded of macro black magic, and when it goes wrong, SimGrid studently loose its ability to explain its problems. When messing around this module, I often find useful to define XBT_LOG_MAYDAY (which turns it back to good old printf) for the time of finding what's going wrong. But things are quite verbose when everything is enabled...

Performance

Except for the first invocation of a given category, a disabled logging request requires an a single comparison of a static variable to a constant.

There is also compile time constant, XBT_LOG_STATIC_THRESHOLD, which causes all logging requests with a lower priority to be optimized to 0 cost by the compiler. By setting it to xbt_log_priority_infinite, all logging requests are statically disabled at compile time and cost nothing. Released executables might be compiled with (note that it will prevent users to debug their problems)

-DXBT_LOG_STATIC_THRESHOLD=xbt_log_priority_infinite

Compiling with the

-DNLOG

option disables all logging requests at compilation time while the

-DNDEBUG

disables the requests of priority below INFO.

Appenders

Each category has an optional appender. An appender is a pointer to a structure which starts with a pointer to a do_append() function. do_append() prints a message to a log.

When a category is passed a message by one of the logging macros, the category performs the following actions:

  • if the category has an appender, the message is passed to the appender's do_append() function,
  • if additivity is true for the category, the message is passed to the category's parent. Additivity is true by default, and can be controlled by xbt_log_additivity_set() or something like –log=root.add:1 (see Category additivity). Also, when you add an appender to a category, its additivity is automatically turned to off. Turn it back on afterward if it is not what you wanted.

By default, only the root category have an appender, and any other category has its additivity set to true. This causes all messages to be logged by the root category's appender.

The default appender function currently prints to stderr.