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].
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?
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.
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.
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?
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
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 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.
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.
https://peter.bourgon.org/ok-log/
And the original HN post
https://news.ycombinator.com/item?id=13418125