paint-brush
Visualising logs matters more than searching themby@stklog
118 reads

Visualising logs matters more than searching them

by stklog teamJune 6th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Having switched from a full-stack web background to managing the infrastructure myself, I had a number of occasions to manage the setup of logging infrastructure.
featured image - Visualising logs matters more than searching them
stklog team HackerNoon profile picture

Having switched from a full-stack web background to managing the infrastructure myself, I had a number of occasions to manage the setup of logging infrastructure.

I’ve installed Graylog, ElasticSearch and integrated a few nicely built SAAS as well.

The stories leading to a logging platform are always very similar. Something breaks in production, a retrospective meeting is organised on how to deal with the situation and the status-quo situation where no logs were stored is now broken, something HAS to be done!

Going forward for a few month after the platform is setup, developers and product owners inevitably start to realise that logging is half of the problem and having overviews and alerting is the other half of it.

Logging platforms (both open-source and SAAS) are generally good at storing and searching into logs, the standard stack is a classic ElasticSearch-Logstash-Kibana. Visualising logs always seems harder for some reason, you need to store a list of events you count and create a dashboard with it. Grouping logs is also not a straightforward task, you need to assign some sort of contextId on every request and pass it to each log so you need to know what is associated with what.

I started to realize that nobody is really looking at the logs themselves, I never once went to the platform and looked into individual logs.

Logging platforms are built like Google, you need to know what you are searching for.

Most of the time I have no idea what to search for so I start to filter events by errors and bind alerts into it. That still not help me much to understand if the application is actually working or not, lots of problems are still silent issues but it’s already the first step.

I then group logs by URL, try to make graphs out of it and set some manual thresholds on how the application should behave which is always a lot of tweaking.

I use Sentry a lot, it’s a product I personally love, it’s built with the UNIX principles in mind, it does one thing (exception monitoring) and does it well. I don’t have anything against logging platforms myself, they are good at what they do: searching logs. However, for having an overview of what is going on, you need lots of manual tweaks. Tools like New Relic can be used for that but they have way more features than what I need. New Relic is an equivalent of Office where I just need a minimalist Wordpad.

Unable to find a “Sentry for logs” kind of software, we built a new platform for our personal needs which would be a minimalist hybrid between monitoring and logging.

I would be interested in getting feedback on how other developers are using logs so feel free to send us also feedback.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!