Google Testing Blog: Optimal Logging

Optimal Logging

piatok, júna 14, 2013

by Anthony ValloneChanneling Goldilocks

Important startup configuration

Errors

Warnings

Changes to persistent data

Requests and responses between major system components

Significant state changes

User interactions

Calls with a known risk of failure

Waits on conditions that could take measurable time to satisfy

Periodic progress during long-running tasks

Significant branch points of logic and conditions that led to the branch

Summaries of processing steps or events from high level functions - Avoid logging every step of a complex process in low-level functions.

Function entry - Don’t log a function entry unless it is significant or logged at the debug level.

Data within a loop - Avoid logging from many iterations of a loop. It is OK to log from iterations of small loops or to log periodically from large loops.

Content of large messages or files - Truncate or summarize the data in some way that will be useful to debugging.

Benign errors - Errors that are not really errors can confuse the log reader. This sometimes happens when exception handling is part of successful execution flow.

Repetitive errors - Do not repetitively log the same or similar error. This can quickly fill a log and hide the actual cause. Frequency of error types is best handled by monitoring. Logs only need to capture detail for some of those errors.

There is More Than One Level

Debug - verbose and only useful while developing and/or debugging.

Info - the most popular level.

Warning - strange or unexpected states that are acceptable.

Error - something went wrong, but the process can recover.

Critical - the process cannot recover, and it will shutdown or restart.

Production - Every level is enabled except debug. If something goes wrong in production, the logs should reveal the cause.

Development & Debug - While developing new code or trying to reproduce a production issue, enable all levels.

Test Logs Are Important Too

Test execution environment

Initial state

Setup steps

Test case steps

Interactions with the system

Expected results

Actual results

Teardown steps

Conditional Verbosity With Temporary Log QueuesFailures and Flakiness Are OpportunitiesMight As Well Log Performance Data

Significant system calls

Network requests

CPU intensive operations

Connected device interactions

Transactions

Following the Trail Through Many Threads and ProcessesMonitoring and Logging Complement Each Other

10 komentárov :

Unknown15. júna 2013 o 11:54:00 GMT-7
Lucid and enlightening. Thank you for this
OdpovedaťOdstrániť
Odpovede
Unknown17. júna 2013 o 5:34:00 GMT-7
Awesome information about logging. Thanks Anthony!
OdpovedaťOdstrániť
Odpovede
Unknown19. júla 2013 o 15:11:00 GMT-7
I'm gonna log this.
OdpovedaťOdstrániť
Odpovede
Anonymný22. augusta 2013 o 6:43:00 GMT-7
Thanks!
OdpovedaťOdstrániť
Odpovede
Khaled Mosarof17. septembra 2013 o 3:19:00 GMT-7
Very informatics.
OdpovedaťOdstrániť
Odpovede
spccdt17. septembra 2013 o 4:34:00 GMT-7
Very helpful yet concise. Thanks!
OdpovedaťOdstrániť
Odpovede
Unknown21. septembra 2013 o 0:09:00 GMT-7
Very helpful for me，tks
OdpovedaťOdstrániť
Odpovede
Shanethatech2. októbra 2013 o 4:06:00 GMT-7
Thanks for publish.
OdpovedaťOdstrániť
Odpovede
Anonymný6. mája 2014 o 6:23:00 GMT-7
Hi folks,

we just open sourced our logging library which implements the Temporary Log Queues concept in this blog post:
https://github.com/egymgmbh/log-queue

Would be nice to get some feedback on that.

All the best,
Michael
OdpovedaťOdstrániť
Odpovede
Unknown5. októbra 2020 o 1:15:00 GMT-7
Very helpful, thanks a lot. Why have you not sensitive user data like passwords as a bad thing to log?
OdpovedaťOdstrániť
Odpovede

Pridať komentár

The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.

Testing Blog

Optimal Logging

10 komentárov :

Labels

Archive

Feed