A distributed and coordination-free log management system | Hacker News Reader

A distributed and coordination-free log management system

github.com

100 pointsavitzurel25 comments

Here's the blog post describing the system

https://peter.bourgon.org/ok-log/

And the original HN post

https://news.ycombinator.com/item?id=13418125

He describes Heka (built by Mozilla) as abandoned. This is true, but we have a re-write in C that is significantly faster and in active development [0].

[0] https://github.com/mozilla-services/hindsight

Isn't it irresponsible to be writing infrastructure software like this in C nowadays?

On HN: yes. In the real world: no.

Regardless, it's weird coming from literally the company behind Rust…

Irresponsible: no. A curious decision: definitely. I mean, there are many other options in the middle. Mixing go and c modules is possible. Unless it was just the case of not having go experience.

Without much more info, it's silly to speculate though.

Wow! Is it possible you could do some write-up on what was behind switching from Go to C for you? Also, whether you evaluated Rust in the meantime? Or just a short HN reply with a summary? From the readme I assume some performance arguments, but how did you predict that C will be faster, what were the pain points with Go in Heka?

While super-interesting (and something that I wish I had time to really evaluate against Elasticsearch/Solr), I feel like it's missing one of the most useful things about Loggly/ES/Solr - the ability to quickly visualize log trends. And despite the statement that it's a "distributed and coördination-free log management system for big ol' clusters", I'm confused why you would want a "big ol' cluster" without visualization or field searches more complex (and less computationally expensive) than regexes. Am I missing something?

e: To be fair, I'm not attempting at all to defend Elasticsearch/Solr, just slightly confused about the actual use cases in prod.

What does "the ability to quickly visualize log trends" mean concretely?

In my mind, some sort of graphical user interface that would allow you to query data and have the log system return results that are easily parsed. At the very least, have some sort of API that allows you to do this. The /query endpoint exists, but doesn't seem to return anything that's really fundamentally useful from a large-scale perspective.

I agree that the nice graphical tools available for Elasticsearch are super useful, but it seems to me that those are not a feature of the logs storage or query interface, but rather one of an external app (e.g. kibana) that queries the system.

It would actually be somewhat concerning to me if a system like Oklog had all those graphing and visualization features built-in; that would be quite some scope creep for a distributed storage engine :-P

TL;DR

So, can I run Kibana against OKlog?

Totally agree on the separation of concerns: visualization vs storage and management.

I disagree. Elasticsearch itself is doing most of the heavy lifting. Kibana is developed in sync with Elasticsearch so that it always has the ability to use most of the features of Elasticsearch.

The nice visualization methods are a direct result of the aggregation abilities of Elasticsearch

Ways to query the data are important and on this newly launched pkg probably need some work (haven't looked at that side of it), but visualisation does not belong in a logging tool, it belongs in external tools querying that tool.

There are trends over the long run, and there are trends in the short span.

Something like glTail (http://www.fudgie.org/ ) or even with a sonification, those would be nice complements, if well tuned, to give some sort of a sense of what is happening.

I found those were not many. Is that there is actually little benefit to use these sort of vis/sonification, or that there's just not many projects that tried to scratch the surface in this area?

Could it be used in combination with something like GoAccess.io?

The thought process that went into the design is very enlightening. Thanks for writing that up.

This looks pretty slick. There's a well done explanation of the architecture process in the blog.

There is actual a fair amount of coordination in this logging system -- with the combination of redirects and gossip to handle them -- but it does seem to be the right kind of coordination.

'Coordination' in English ;)

Coördination is proper English also :)

yeah, I guess the oklog folks have drunk the kool-aid put out by the New Yorker: http://www.newyorker.com/culture/culture-desk/the-curse-of-t...

Diaeresis: a typographical accent used to remind you that you are reading the New Yorker.

I'm not offended by co-ordination either.

The diaeresis and the umlaut both are two dots; but are different. The diaeresis indicates hiatus -- a pause between vowels, resulting in two syllables where we might otherwise be inclined to use one. This is the classical (and rare) use of this marker in English.

Reply on news.ycombinator.com