Logging has changed a lot in the past few years. It went from being something that you only do when there’s an error – to now logging every little bit of information you can. Why has this changed? Well, for starters, we now have better tools to read logs. Previously, we used to just store them as text somewhere. Maybe if you’re fancy, you’d store it in a database. Can you imagine combing through these files – looking for that one error that customer X reported? No, probably not. Especially when files ended up being 1GB or more. Having to open that file in a text editor was hell. But things change.
Debug/Info/Warning/Exception
Most languages or logging frameworks come with built-in levels for logging. Debug is usually the lowest level of logging that most people won’t need and you won’t need to send to your log database. Here is where you store things like “Method reached this point” – if you’re so inclined. I don’t think I’ve needed debug except for testing (or JS debugging). The next level is info. This is stuff you may want to keep. You might store here important calls or tasks. A warning is the next level. You’ll probably want to store exceptions or errors that you handle and recover from easily. The last level is an error. This may either by an unrecoverable exception/error or just a really bad error.
Along came Elastic Search
Over the past few years, I’ve been hearing a lot about Elastic Search. From how I understand it (being a more front-end guy – rather than dev-ops/backend focused), Elastic Search is a place where you can store all of your log messages and read them quickly. They provide a dashboard (Kibana) to visualise and drill down on your exceptions. Now, in .NET this is really easy if you use something like Serilog. All you need to do is add the ElasticSearch sink and configure it and you’re done. No need to write extra code! So you can just swap over your file-based log to a more sophisticated setup easily.
Logging as a Service
I’ve only had experience with Raygun, but I’m sure there are more sites that offer to log as a service. My experience with Raygun was pretty positive (I can’t say what it costed though as I wasn’t in charge of the budget). Raygun made logging quite smart. What it did was it grouped similar exceptions together – so that in the end – you would have an overview of what your most common exceptions are. This provided much-needed information to make decisions about what bugs to tackle or what would make the most impact or how often a bug was impacting customers.
How much is too much?
With the above changes in mind, I think we can safely say that you can’t really log too much. All this data that you collect – what is clicked and what is not – will be useful to your data scientists. You’ll be able to determine with data what works and doesn’t. This will give you a competitive edge. So, to answer the title question – there is no such thing as too much logging. Obviously – I don’t mean PII (Personal Identifying Information). You should avoid logging PII – especially things like credit cards or passwords. Avoid logging those at all costs.
And that’s it. You can log just about every interaction, every click or every error. What will come from this? Information. Information that your business can use now or in the future to make informed decisions. Because without the data – you’re just guessing.
Leave a Reply