Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-17237

Implement a logging subsystem

    XMLWordPrintableJSON

Details

    • Epic
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 3.0.0-beta1
    • general
    • Logging

    Description

      Motivation

      One of the most important parts of any running application is its logs. The operations team uses them to make sure the application runs smoothly. Developers use the log for troubleshooting. So we need to provide a uniform way to log any important event related to the system.

      Requirements

      • Implementation should not rely on any particular 3rd-party logging framework
      • Implementation should support 5 base logging severities: TRACE, DEBUG, INFO, WARN, ERROR
      • Implementation should provide a uniform API for server-side use as well as for clients
      • For clients there should be an ability to specify logger programmatically through the client builder
      • Implementation should provide seamless integration with majority of popular logging frameworks
      • Implementation should support parameters' substitution to avoid wrapping with ifEnabled for very simple cases

      Proposed solution

      We could take an advantage of System.Logger frameworks. This implies a two level architecture with uniform frontend which should be used throughout our system, and interchangeable backends. Besides, System.Logger framework have already integrated with such 3rd-party frameworks as SLF4j and Log4j.

      Proposed guidelines

      Message layout

      Nowadays so many deployments have an automated logging preprocessing, that it's important not only make the logs human readable, but make them machine friendly. With that said, we need to get sure that all arguments are easy to locate and parse. To achieve this, the proposed log format is follow:

      <Log message> [argKey1=argVal1, argKey2=argVal2]
      

      For example:

      Table has been created [id=0xaabbccdd, tName=my_table, sName=my_schema]
      

      Perhaps, the structured logs fits better, but this is currently out of scope.

      Arguments inlining

      We need to avoid string concatenation to inline arguments into the message because logging subsystem should provide arguments' substitution

      On choosing the level

      We must come from an understanding that both levels WARN and ERROR requires an attention of an operation team, so those levels should be used only when the cluster is in (or about to move to) invalids state.

      INFO is a normal level that is used to log regular unfrequent events. Avoid to use this level for frequent events like TABLE INSERT

      Attachments

        Activity

          People

            Unassigned Unassigned
            korlov Konstantin Orlov
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: