Livelli di logging e consigli per usarli

Non tutti sono soliti loggare cosa sta succedendo durante l’esecuzione di un’applicazione. E questo e’ il MALE, c’e’ poco da dire! Altri invece, pur loggando, non sanno mai quando loggare come trace, debug, info oppure warning, e spesso si ritrovano ad usare uno solo di questi valori, assieme al canonico error per segnalare l’accadimento di disastri.

Ho trovato su questo post una guida che puo’ aiutare a decidere “dove va cosa”:

ERROR: something terribly wrong had happened, that must be investigated immediately. No system can tolerate items logged on this level. Example: NPE, database unavailable, mission critical use case cannot be continued.

WARN: the process might be continued, but take extra caution. Actually I always wanted to have two levels here: one for obvious problems where work-around exists (for example: “Current data unavailable, using cached values”) and second (name it: ATTENTION) for potential problems and suggestions. Example: “Application running in development mode” or “Administration console is not secured with a password”. The application can tolerate warning messages, but they should always be justified and examined.

INFO: Important business process has finished. In ideal world, administrator or advanced user should be able to understand INFO messages and quickly find out what the application is doing. For example if an application is all about booking airplane tickets, there should be only one INFO statement per each ticket saying “[Who] booked ticket from [Where] to [Where]”. Other definition of INFO message: each action that changes the state of the application significantly (database update, external system request).
DEBUG: Developers stuff. I will discuss later what sort of information deserves to be logged.

TRACE: Very detailed information, intended only for development. You might keep trace messages for a short period of time after deployment on production environment, but treat these log statements as temporary, that should or might be turned-off eventually. The distinction between DEBUG and TRACE is the most difficult, but if you put logging statement and remove it after the feature has been developed and tested, it should probably be on TRACE level.

Concludo dicendo che piu’ di una volta mi e capitato di constatare che l’analisi di log ben scritti puo’ davvero fare la differenza in termini di tempo impiegato per riprodurre, capire e risolvere un problema.

Se poi i log per Android sono colorati, esaminarli e’ ancora piu’ facile! ;)

4 Comments

  1. Mi pare che le RFC [1] prevedano dei livelli di log ben definiti, non conviene seguire le indicazioni che danno (non è polemica, ma solo una considerazione)? Consideriamo anche la possibilità di avere strumenti di gestione dei log centralizzati che prelevano dati da più dispositivi, se si uniformano per lo meno i livelli le cose potrebbero essere più semplici da gestire ;)


    0 Emergency: system is unusable
    1 Alert: action must be taken immediately
    2 Critical: critical conditions
    3 Error: error conditions
    4 Warning: warning conditions
    5 Notice: normal but significant condition
    6 Informational: informational messages
    7 Debug: debug-level messages

    [1] http://www.faqs.org/rfcs/rfc3164.html

  2. Pur dandoti ragione (se c’e’ la RFC perche’ non seguirla), pero’ in Android ed in altri sistemi i livelli di log si chiamano in maniera diversa e non c’e’ neanche una diretta mappatura con quelli della RFC.

    Inoltre la RFC non fornisce indicazioni sul loro reale significato: “debug-level”, ad esempio, e’ molto generico e puo’ significare tutto, persino troppo…

    D’accordo con te che se ci fosse una RFC ben definita, sarebbe da seguire quella di sicuro!

  3. Bhè, debug level è il livello usato per le attività di debug, probabilmente non riesco a capire cosa intendi dire.

    A parte questo, se altri non seguono gli standard, possiamo almeno nel nostro piccolo tentarci, chissà che un giorno… ;)

  4. Volevo intendere che spesso diversi sviluppatori hanno diversi “livelli di sensibilita'” su cosa mettere nei log in base al livello. Non mi sembra che l’RFC definisca cosa mettere nei log, se non con una sintetica indicazione che non aiuta ad indirizzare questa sensibilita’ comune… Giusto non definire troppo, ma un’indicazione di massima io l’avrei data…

    E che nell’RFC i livelli sono un po’ diversi rispetto a quelli proposti da Android: quindi mapparli 1:1 non sarebbe possibile.

    Io, ad esempio io apprezzo la differenza tra debug e trace: nel primo ci metto una serie di cose che mi vengono comode durante il debug e che mi servono a risolvere il 90% dei problemi, mentre per problemi piu’ ostici passo a trace, dove loggo tutto, ma proprio tutto (tipo il risultato di una chiamata al servizio, lo stato di alcuni dati, query sql moooolto verbose ecc), con un leggero rallentamento dall’applicazione. Ma meglio vederla funzionare piano e bene, che vederla andare veloce e male ;)

Leave a Reply