Last updated at Mon, 06 Nov 2017 17:56:44 GMT
I love a good buzzword…cloud, big data, analytics …And even more than the buzzwords, I love the liberties people tend to take applying these buzzwords to their new systems and services. Such buzzwords regularly get abused and often get washed into marketing material and product websites in an attempt to hoodwink and woo new unsuspecting customers. One of my (least) favorite buzzwords, that I’ve noticed popping up more recently in particular in the logging space is “real-time.”
So what does real-time mean anyway? Like with all good computer science questions, it really depends on the context. John Stankovic, in his seminal 1988 article in IEEE Computer entitled ‘Misconceptions of real-time computing’ describes a real time system as follows:
“A real-time system is one in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are generated.”[1]
An example is, what are referred to as, “hard-real-time systems” [2], where computation must meet stringent timing constraints and one must guarantee that those computations must be completed before specified deadlines. Failure to do so can lead to intolerable system degradation and can in some applications lead to catastrophic loss of life or property.
Many safety-critical systems are hard-real-time systems, and include embedded tactical systems for military applications, flight mission control, traffic control, production control, nuclear plant control etc. and in many cases the real-time properties need to be guaranteed and proven – often using techniques such as formal methods [3] for example.
Near real-time is often defined as not having any hard constraints, but implies that there are no significant delay in processing of the event. In many cases this means within a few milliseconds or seconds of the event – again this really depends on the context. From a system monitoring perspective (of non-safety critical applications) near real-time, i.e. within a few seconds, is usually sufficient when it comes to alerting for example. And by non-safety critical, I mean, your site/app might be down, but it will not lead to loss of life. That being said it could be resulting in serious loss of $$$.
In such scenarios if there is something awry with one of system components you want to be notified about this immediately, so that right away you can go about rectifying the issue. A few minutes is usually unacceptable however, as generally this means that users/customers of your system/service are being effected without you knowing anything about this, resulting in damage to your brand and business top line.
This is what really surprises me when I see so many log management solutions that run their alerting as background jobs or saved searches which run periodically every 5, 10 or 15 mins. In my opinion this doesn’t really cut it when it comes to alerting and is NOT real- time/near real-time by any standard. Consider this, if there was an emergency at home do you think it would be acceptable to wait 5, 10 or 15 minutes before you picked up the phone and called the emergency services. A few seconds, yes, a few minutes NO!
A further observation by Stankovic in his 1988 article was that another common misconception in relation to real-time systems is that throwing hardware at the problem can solve this issue – however as Stankovic rightly points out, throwing hardware at the problem is not the answer – it’s all about the architecture.
That’s why we have built a very different architecture to any other logging provider. In short, most log management solutions work as follows:
- data is sent to the log management service
- it is indexed and written to disk
- you can make use of their (complex) search language to dig into your data
- if you want to create notifications you need to set up saved searches (using the complex search language) that you can schedule to run every 5, 10 or 15 mins.
At Logentries we have flipped this approach on its head and have built a unique pre-processing layer as part of our system architecture that allows for real-time processing of your data such that the analysis of your log events is done up front and in near real-time. And, when we say real-time, we mean real-time.
It works as follows:
- data is sent to Logentries
- it passes through our pre-processing layer which analyzes each event for defined patterns(i.e.keywords,regular expressions,defined search expressions) in real-time
- notifications can be generated from our pre-processing layer such that you receive them within seconds of the important events occurring (e.g. exceptions, errors, warnings…)
The end result is that you get notified in seconds as opposed to minutes. In a world where time is money, and where buzzwords are only as useful as the architecture behind them, I vote for REAL real-time alerting – as it is an important requirement in any logging service!
[1] J. Stankovic, Misconceptions of real-time computing’, IEEE Computer, 1988
[2] Jia Xu and David Lorge Parnas, ‘On Satisfying Timing Constraints in Hard-Real-Time Systems’ IEEE Transactions on Software Engineering, Vol 19, No. 1, Jan 1993
[3] ‘Formal methods for the design of Real Time Systems’, Springer, International School on Formal Methods for the Design of Computer, Communication and Software Systems, September 2004
