![]() If I know something started, and don't even know the result - what can I do?.I decided to not refer the user when the operation starts and succeeds because it's irrelevant (so it's noise), see: I should be able to see the error's stack trace to dive into the "why" it failedįor both cases, I can track when something happened (logs have timestamps), what happened, and who got affected. Log attributes should allow me to find who got positively affectedĬonsider that retrieving instances from region af-south-1 failed due to some random issue over that region.įailed to retrieve instances from regions af-south-1 when connecting to AWS for user XĪWS operation didn't finish, region af-south-1 failed, Let's use our example instead.Ĭonsider the AWS integration from our example, It would be great to have: Successful logs example To keep logs "descriptive" and "contextual", you need to provide the correct set of information, and that's impossible to tell you which are they without knowing your case. ![]() Logs should tell you a story, every story has a beginning, middle, and end.īe strict with "relevant", it's easier to add logs than to remove them, anything below relevant is noise. At the conclusion of an operation (e.g.Authentication successful, got a valid response code, etc) At the start of relevant operations or flows (e.g.Logs should be the same.Īs a rule of thumb consider logging: When to log Make them as clear and easy to read as this blog post, maybe you didn't read every single line I wrote above, but you can still follow up, skip sections you don't want, and focus/read what caught your attention. To keep logs "reactive" you need to log "events". Any log that can't give you this ability is pure noise. Logs are private intel from your software to keep you aware and react to situations. So, yes, it's possible to ruin the core nature of a log. By reading it I can't even consider the impact of an error, because I don't know WHAT failed. It can be easily done by giving shallow messages with no context at all like: "An error happened", or "An unexpected exception was raised". Oh, also don't underestimate a developer's capacity to ruin the descriptive characteristic. If you give it a description like "operation connect failed", but don't give context, it's hard to understand which integration failed, who was affected, what step of the connection it failed, thus you can't react! You'll end up digging into more logs and having no clue but just guesses on what could be the issue. Here, take some examples based on the system we defined together: If you don't respect the nature of a log, you're going to produce only noise, which decreases your performance. They're descriptive in the sense that they give you a piece of information, they're contextual because they give you an overview of the state of things at the moment, and finally, they're reactive because they allow you to take action only after something happened (even though your logs are sent/consumed real-time, there's not really something you can do to change what just happened). (Google SEO, please, don't relate this post to forests □).įirst, let's analyze the log characteristics. □ The nature of logging: good logging matters I won't be focusing on the challenges of maintaining such integrations but only observing them. Authentication invalid, resource does not exist, etc.) Each integration may produce different errors at any time (e.g. ![]()
0 Comments
Leave a Reply. |