Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "TCB:Logging Working Group"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{TOC_right}}
{{TOC_right}}


= WG Charter =
= WG Charter =
Line 5: Line 6:
With the [[https://www.egi.eu/indico/conferenceDisplay.py?confId=672 TCB-9 Face to Face]] meeting the TCB members agreed to set up a Working Group to address short-term and long-term issues related to logging infrastructure and log messages across Technology Providers.
With the [[https://www.egi.eu/indico/conferenceDisplay.py?confId=672 TCB-9 Face to Face]] meeting the TCB members agreed to set up a Working Group to address short-term and long-term issues related to logging infrastructure and log messages across Technology Providers.


The WG shall have a lifetime of 6 months and regularly report progress to the TCB through written reports and presentations at TCB meetings.
Since there was no interest by TCB members to further pursue the Logging Working Group, the TCB decided at the [http://go.egi.eu/TCB-10 TCB-10] conference call to close this working group even before it had constituted itself.
 
Representatives shall be sourced from EGI operations and Technology Providers currently contributing software deployed (or planned to be deployed) onto the EGI produciton infrastructure.
 
= Representatives =
 
{| border="1"
|-
! Role
! Name
! Affiliation
|-
| WG coordinator
| Michel Drescher
| Technical Manager, EGI.eu
|-
| EGI Operations representative
|
|
|-
| EGI SPG representative
|
|
|-
| Technology Provider
|
| EMI (European Middleware Initiative)
|-
| Technology Provider / Platform integrator
|
| IGE (Initiative for Globus in Europe)
|-
| Technology Provider
|
| SAGA (Simple API for Grid Applications)
|-
| Technology Provider
|
| StratusLab
|}
 
= Roadmap =
 
WG duration: 6 months
 
Rough timeline:
 
==== Short term ====
* Define taxonomies
 
==== Medium/long term ====
* Config file harmonisation
* Default configuration (EGI Ops/Security policy)
* Common service configuration interface
* Fabric management integration
 
= Logging taxonomy =
 
== Logging levels ==
 
Logging levels indicate the severity of the logged incident. As the name indicates logging levels are implicitly ordered, in a filtering, or threshold model.
 
Logging levels are used in two components of a logging framework:
* When a log message is assembled in software code and sent ''at a defined level'' to the logging framework 
* In a logging related configuration that controls the actual behaviour of the logging framework
 
When a specific logging level is configured for a given logging domain, then all messages of that level ''and of all higher levels'' are realised (e.g. printed to the console, a log file, etc.)
 
=== Available frameworks ===
 
Logging frameworks define different log level granularity, and at times even mixing the scope (or domain). For example:
 
===== Oracle Java6 =====
 
[http://docs.oracle.com/javase/6/docs/ Oracle Java 6] contains a default logging system for Java since the inception of Java 4. Since the logging subsystem is located in the java.lang namespace, it MUST be implemented in any compliant Java VM (OpenJDK, etc.) as well, and therefore is ubiquitously available on all Java platforms.
 
Number of levels: 7 (SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST) [http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html]
 
===== Apache Log4* / Apache Commons =====
 
Apache Log4* used to be a separate Logging module (for Java), but has recently replaced the [http://commons.apache.org/logging/ Apache Commons] implementation for Java logging. Apache Log4* is available with a multitude of language bindings, e.g. C, C++, Java. It defines logging levels (in order of descending order) as follows:
 
Number of levels: 6 (FATAL, ERROR, WARN, INFO, DEBUG, TRACE) [http://commons.apache.org/logging/apidocs/org/apache/commons/logging/Log.html]
 
===== Python 2.7.2 =====
 
[http://docs.python.org Python 2.7.2], just as Java, provides a default platform-wide [http://docs.python.org/library/logging.html logging subsystem] and therefore will be available anywhere where Python is available.
 
Number of levels: 5 (CRITICAL, ERROR, WARNING, INFO, DEBUG) [http://docs.python.org/howto/logging.html#logging-basic-tutorial]
 
===== Ruby 1.9.3 =====
 
[http://www.ruby-doc.org/stdlib-1.9.3/ Ruby 1.9.3] also provides a [http://www.ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html standard library] for logging in Ruby, therefore available on all platforms where Ruby will be provided for.
 
Number of levels: 5 (CRITICAL, ERROR, WARNING, INFO, DEBUG) [http://www.ruby-doc.org/stdlib-1.9.3/libdoc/logger/rdoc/Logger.html]
 
===== GNOME glibc 2.30.2 =====
 
Loggers are available for C and C++. Apart from multi-language binding loggers (e.g. [[TCB:Logging_Working_Group#Apache_Log4.2A_.2F_Apache_Commons|Apache Commons]]) the very popular [http://developer.gnome.org/glib/stable GNOME glibc]] provides a widely available logging subsystem.
 
Number of levels: 5 (CRITICAL, ERROR, WARNING, MESSAGE, DEBUG) [http://developer.gnome.org/glib/stable/glib-Message-Logging.html]
 
=== Logging level mapping ===
 
The following table correlates the various logging level definition and semantics from the analysed frameworks.
 
{| border="1"
|- style="text-align:center;"
! Relative order
! EGEE JRA1
! Apache Log4*
! Oracle Java 6
! Python 2.7.2
! Ruby 1.9.1
! PERL/Log4perl
! glibc 2.30.2
|- style="text-align:center;"
| 1
| FATAL
| FATAL
| SEVERE
| CRITICAL
| FATAL
| FATAL
| CRITICAL
|- style="text-align:center;"
| 2
| ERROR
| ERROR
| -
| ERROR
| ERROR
| ERROR
| ERROR
|- style="text-align:center;"
| 3
| WARN
| WARN
| WARN
| WARNING
| WARN
| WARN
| WARNING
|- style="text-align:center;"
| 4
| INFO
| INFO
| INFO
| INFO
| INFO
| INFO
| MESSAGE
|- style="text-align:center;"
| 5
| -
| -
| CONFIG
| -
| -
| -
| -
|- style="text-align:center;"
| 6
| DEBUG
| DEBUG
| FINE
| DEBUG
| DEBUG
| DEBUG
| DEBUG
|- style="text-align:center;"
| 7
| -
| TRACE
| FINER
| -
| -
| TRACE
| -
|- style="text-align:center;"
| 8
| -
| -
| FINEST
| -
| -
| -
| -
|}
 
 
It seem apparent that many frameworks adopt a common logging granularity of five different logging levels, with large overlap in their respective definitions. Moreover, the naming reflects this overlap except for the most critical impact (severe, critical as opposed to fatal), and debugging levels (fine, as opposed to debug).
 
Tracing is often folded into the debugging area of logging; ideally, a production infrastructure system admin should never worry to configure the systems on a debugging log level.
 
A "config" debug level is an interesting concept for an initial emitting of static configuration (i.e. read off a static configuration file at startup) but is not supported on any other examined logging frameworks. It can easily map to logging these on INFO level.
 
A more serious issue is the widespread support - and distinction! - between FATAL and ERROR situations. The common understanding seem that FATAL describes an unrecoverable situation and the service may shut down, or may behave entirely unpredictable, and ERROR describing a situation where a requested function or behaviour was not carried out. The difference between FATAL and ERROR seem the difference in the assessment whether the incident/situation/context is permanent (--> fatal) or transient (--> error). However, this distinction is not made in the default Oracle Java logging subsystem, and that needs to be taken care of.
 
== Logging domains ==
 
'''A suggestion of logging domains '''
* Security<br>(where is the distinction to service access?)
* Service access
* Service management
 
== Logging message composition ==
 
= Logging infrastructure =
 
= Configuration =
 
== Config file vs. service management integration ==
 
== Supported solutions ==


== Fabric management integration ==
The history of this Wiki entry provides more information on the initial setup of the working group.

Revision as of 17:12, 30 November 2012



WG Charter

With the [TCB-9 Face to Face] meeting the TCB members agreed to set up a Working Group to address short-term and long-term issues related to logging infrastructure and log messages across Technology Providers.

Since there was no interest by TCB members to further pursue the Logging Working Group, the TCB decided at the TCB-10 conference call to close this working group even before it had constituted itself.

The history of this Wiki entry provides more information on the initial setup of the working group.

Retrieved from "https://wiki.egi.eu/w/index.php?title=TCB:Logging_Working_Group&oldid=46649"