|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| | This page is obsolete, for information about the EGI Cloud Federation please refer to: |
| | [[Fedcloud-tf:Main| EGI Federated Cloud]] |
| | |
| {{TOC_right}} | | {{TOC_right}} |
| | [[Category: Technology Coordination Board (TCB)]] |
|
| |
|
| = WG Charter = | | = WG Charter = |
| Line 5: |
Line 9: |
| 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:
| |
| | |
| ==== 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 ([http://docs.python.org/library/logging.html]), in descending order of levels:
| |
| | |
| Number of levels: 5
| |
| | |
| * CRITICAL
| |
| * ERROR
| |
| * WARNING
| |
| * INFO
| |
| * DEBUG
| |
| | |
| ==== Oracle Java6 ====
| |
| | |
| Oracle Java ([http://docs.oracle.com/javase/6/docs/api/java/util/logging/Level.html]) 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 ===
| |
| | |
| {| 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
| |
| |- style="text-align:center;"
| |
| | 1
| |
| | FATAL
| |
| | FATAL
| |
| | SEVERE
| |
| | CRITICAL
| |
| | FATAL
| |
| | FATAL
| |
| |- style="text-align:center;"
| |
| | 2
| |
| | ERROR
| |
| | ERROR
| |
| | -
| |
| | ERROR
| |
| | ERROR
| |
| | ERROR
| |
| |- style="text-align:center;"
| |
| | 3
| |
| | WARN
| |
| | WARN
| |
| | WARN
| |
| | WARNING
| |
| | WARN
| |
| | WARN
| |
| |- style="text-align:center;"
| |
| | 4
| |
| | INFO
| |
| | INFO
| |
| | INFO
| |
| | INFO
| |
| | INFO
| |
| | INFO
| |
| |- style="text-align:center;"
| |
| | 5
| |
| | -
| |
| | -
| |
| | CONFIG
| |
| | -
| |
| | -
| |
| | -
| |
| |- style="text-align:center;"
| |
| | 6
| |
| | DEBUG
| |
| | DEBUG
| |
| | FINE
| |
| | DEBUG
| |
| | DEBUG
| |
| | DEBUG
| |
| |- style="text-align:center;"
| |
| | 7
| |
| | -
| |
| | TRACE
| |
| | FINER
| |
| | -
| |
| | -
| |
| | TRACE
| |
| |- style="text-align:center;"
| |
| | 8
| |
| | -
| |
| | -
| |
| | FINEST
| |
| | -
| |
| | -
| |
| | -
| |
| |}
| |
| | |
| == 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. |
The wiki is deprecated and due to be decommissioned by the end of September 2022.