Difference between revisions of "TCB:Logging Working Group"
Line 118: | Line 118: | ||
* FINEST - A message level providing ''very detailed'' tracing information. | * FINEST - A message level providing ''very detailed'' tracing information. | ||
* ALL (pseudo) - Indicates that all messages should be logged. | * ALL (pseudo) - Indicates that all messages should be logged. | ||
=== Logging level mapping === | === Logging level mapping === | ||
Line 202: | Line 195: | ||
| - | | - | ||
|} | |} | ||
== Logging domains == | |||
'''A suggestion of logging domains ''' | |||
* Security<br>(where is the distinction to service access?) | |||
* Service access | |||
* Service management | |||
== Logging message composition == | == Logging message composition == |
Revision as of 18:09, 30 January 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.
The WG shall have a lifetime of 6 months and regularly report progress to the TCB through written reports and presentations at TCB meetings.
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
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:
Apache Log4*
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 (plus one pseudo-level, "OFF", to turn logging off)
- OFF - The OFF has the highest possible rank and is intended to turn off logging.
- FATAL - The FATAL level designates very severe error events that will presumably lead the application to abort.
- ERROR - The ERROR level designates error events that might still allow the application to continue running.
- WARN - The WARN level designates potentially harmful situations.
- INFO - The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
- DEBUG - The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
- TRACE - The TRACE Level designates finer-grained informational events than the DEBUG
Python 2.7.2
Python logging levels ([1]), in descending order of levels:
Number of levels: 5
- CRITICAL
- ERROR
- WARNING
- INFO
- DEBUG
Oracle Java6
Oracle Java ([2]) provides symbolic names for common log levels. The numeric granularity allows for 1000 logging levels. In descending order:
Number of levels: 7 (plus two pseudo logging levels)
- OFF (pseudo level) - Turns off all logging when used as a configuration item
- SEVERE - Indicates a serious failure.In general SEVERE messages should describe events that are of considerable importance and which will prevent normal program execution.
- WARNING - Indicates a potential problem. In general WARNING messages should describe events that will be of interest to end users or system managers, or which indicate potential problems.
- INFO - Informational messages. Typically INFO messages will be written to the console or its equivalent.
- CONFIG - For static configuration messages. Intended to provide a variety of static configuration information, to assist in debugging problems that may be associated with particular configurations.
- FINE - A message level providing tracing information.
- FINER - A message level providing fairly detailed tracing information.
- FINEST - A message level providing very detailed tracing information.
- ALL (pseudo) - Indicates that all messages should be logged.
Logging level mapping
Relative order | EGEE JRA1 | Apache Log4* | Oracle Java 6 | Python 2.7.2 | Ruby 1.9.1 | PERL/Log4perl |
---|---|---|---|---|---|---|
1 | FATAL | FATAL | SEVERE | CRITICAL | FATAL | FATAL |
2 | ERROR | ERROR | - | ERROR | ERROR | ERROR |
3 | WARN | WARN | WARN | WARNING | WARN | WARN |
4 | INFO | INFO | INFO | INFO | INFO | INFO |
5 | - | - | CONFIG | - | - | - |
6 | DEBUG | DEBUG | FINE | DEBUG | DEBUG | DEBUG |
7 | - | TRACE | FINER | - | - | TRACE |
8 | - | - | FINEST | - | - | - |
Logging domains
A suggestion of logging domains
- Security
(where is the distinction to service access?) - Service access
- Service management