Humio — Logging for Systems That You Care About
With modern multi-host software systems, we are missing this feeling for normal (or lack thereof) coming from subconscious sensing — we are missing a way to touch our systems. Modern software runs in datacenters that are far away and disconnected from the developers who are creating applications. We have lost that connection.
Metrics dashboards provide visibility, and it is a great place to start, but they are limited as they only provide a view. They provide means to know that something is wrong, but usually not what is wrong. And dashboards are only really good for known problems, new unknown issues are harder. To do that, you need to interact with your system — touch it in real-time and do ad-hoc analytics to see what is going on. Logs are a great place to start because they are already there but in many cases it is just too difficult to get useful information quickly out of large volumes of logs.
Touch your logs
We learned the value of these matters being part of building a large highly available system for the Danish health care system. And we have realized that a lot can be gained by enabling developers and operations teams to easily interact with the logs. Enabling people to explore, iterate and understand their logs — and thereby applications, datacenters, and devices — makes a huge difference. We built Humio from a wish list of things we wanted to be able to do with logs:
Observe and Monitor
To begin, we want to make it simple to look at logs — and just see how many there are? Then begin to ask questions and dig deeper — search for errors or filter by certain parameters. This provides a super low friction way to get a feel for the health of a system because the logs are already there. Real-time live queries and monitoring are extremely critical and we want to be able keep an eye on a particular area of our system in an up-to the second view.
Understand and Debug
Most of you have used tail -f and grep, but when you have a lot of logs, it is difficult to search and find out what is happening quickly. We wanted to be able to have an easy way to get through massive amounts of logs and be able to troubleshoot with a easy to use query language.
Make it possible to have lots of logs
We have experienced log systems with a strict quota on logs, with organization policies prohibiting developers to log, and in turn logging systems breaking down when you need them the most — in the middle of some system capacity situation. Text logs by nature are easy to compress and store, and going far back in time to understand history is extremely useful. So, we wanted to build a system that would make it cost-effective to keep lots of log around for future reference, and at the same time be able to absorb large spikes in ingest.
When developing Humio, we wanted to create a product that does things differently. The user experience and performance of the product goes hand in hand to deliver a very different feel.
We wanted interactions with the logs to feel live, it should feel interactive like Excel and you should be able to play with and explore your data. You should be able to try different ad-hoc queries and then quickly be able to view them in a graph, timechart, or in a dashboard.
We wanted to be able to do stream processing as data comes in, not just looking at old data. Avoid heavy up-front indexing as that will leave users with a sytem where they can only look into the past.
Schema on Read
How many times have you wished you had indexed or saved something in your database after it is too late. Humio is text based you can use Ad-Hoc Schema on Read and you can just go back in time and ask questions when they come up without worry.
Keep it simple
The last thing you want is that the logging systems ends up being a major headache. So, we stretched ourselves to make a system that is simple and robust.
You can touch your logs too!
We encourage you to try Humio out — we have a free individual user plan for 60 GB/month, or try Humio on-premise. Sign up, let us know what you think.