Observability is the ability to derive a state of a system from output data. Or is it the sum of logs, metrics and tracks? Well, both actually. The former is a qualitative and abstract expression, while the latter is more quantitative and specific.
Both are definitions that people seem to subscribe to, according to DevOps Pulse 2020 survey. DevOps Pulse is an annual survey conducted by logz.io, a company active in the field of observability. As of 2019, over 1000 people participated in the survey, providing interesting insights into the state of DevOps.
Similar to 2019, we had a connection to a logz.io director to discuss the results of the study. Unlike 2019, DevOps Pulse 2020 was released towards the end of 2020 rather than the beginning of 2021. The main reason is that it is timed to coincide with a product announcement from logz.io around the next step in observability and the most important finding of the study: tracking.
Obervability’s maturity curve
ZDNet associated with Jonah Kowall, logz.io CTO, to discuss DevOps Pulse 2020, observability in general and tracking in particular. Kowall, who is relatively new to logz.io but experienced in the observation room, said what attracted him to logz.io was the dynamics of its open source offering.
As we have seen before, logz.io offers observability-related frameworks, such as Elastik / the EVERYTHING and Grafana as a service. It’s a familiar pattern and offer: Instead of taking the open source software and running it yourself, many organizations find that having a third party do it for them makes sense.
When discussing “what are we talking about, when we are talking about observability”, we noticed that 1 in 3 respondents said it was “using logs, measurements and traces”, and another 1 in 3 said that it was “the measure of how well a state of a system was can be deduced from output data”. Different ways of saying the same thing, Kowall noted, but none of them actually focus on why you do it.
The reason is not only to discover and diagnose problems, but also to gain an understanding of how your digital business works. There is a maturity curve of sorts that you see around observability, Kowall continued to add. Companies that do not have observability often do not see their problems until users complain – the reactive state.
Slightly more advanced companies are starting to say – “now that we see a problem, how do we solve it? Who is the best person to fix it”? Then the most advanced users, and this is a very small percentage, use this data to drive their business decisions: “how can I derive or observe my business based on the data coming from my applications and infrastructure”?
This pointed to two further interesting findings in DevOps Pulse 2020. One, respondents seemed to be unsure of what it is they are doing exactly, or whose job observability actually is. This is in line with the results in 2019 – not much has changed. Kowall believes much of this is about names, or what people think of themselves.
Some teams previously called this job they may have renamed themselves DevOps, but has otherwise not changed much. The real sign of DevOps in action, Kowall continued to add new ways to build and release software – continuous implementation and continuous change. When this happens, it really is DevOps – a shared responsibility that requires shared shared data and shared roles between the Dev and Ops teams.
Two, about 70 percent of respondents said they use between two and four observation tools. Trying to figure out what this might mean, we also looked at how people reacted when asked to share what types of observation tools they use.
The vast majority of respondents use tools for log management and analysis as well as infrastructure monitoring (approximately 90 and 80 percent, respectively). Approx. 1 in 3 uses application performance monitoring tools and 1 in 4 uses distributed tracking tools. In other words, people use the best racing gear, and that’s another reason why open source also makes sense in observability.
Open source observation tools is in the mix for about 80 percent of respondents, with the majority of users relying on open source for the majority of their operations. The reasons for them are typical for open source users – easy integration, community, avoidance of vendor lock, lower ownership costs.
Distributed tracking as a service with Jaeger
When it comes to integrating various observable tools, Kowall highlighted OpenTelemetry. The idea behind OpenTelemetry, a CNCF (Cloud Native Computing Foundation) project, which is the second largest Kubernetes in popularity is to create a standards-based way of collecting data and sending them to various tools.
Through OpenTelemetry, one can find support from vendors such as Microsoft Azure and Google, in addition to a who is who of vendors active in the observability area. OpenTelemetry has good traction and is closing in on a first release, which is likely to happen in 2020, Kowall said:
“This shows that the industry or at least the leaders in the industry are moving towards this open way of sharing information. And the proprietary nature of tools from before is becoming less accepted by the general community.”
Returning to the maturity curve in observability, Kowall noted that tracking is less popular because it is more difficult to implement. But open standards and open source projects will change over time, he continued to add. The reason Cloud Native is so important for observability is that many of the cloud-native stack technologies are automatically integrated with tracking.
When Kubernetes e.g. If implemented, a kind of service network or proxy system will probably also be implemented. Many of these systems are built on an open source tool called Envoy, which integrates with tracking systems. As these cloud native tools continue to be implemented, it will be easier to collect this data.
Today, however, implementing tracking is not very easy. In some languages, like Java, there are very easy ways to do this automatically that do not require code changes, but this is not the case everywhere.
What logz.io is announcing today is the general availability of Hunter as a service to exploit this potential. Jaeger along with Zipkin, are the most popular open source tracking tools. logz.io has been working on Jaeger, hardening its code for bug fixes and new features, and adding machine learning on top of the data it collects to make it easier to troubleshoot and isolate problems.
Jaeger was started and donated to CNCF by Uber, and Red Hat is another major contributor. Kowall said logz.io has been heavily involved in the project over the past few months, and they also plan to improve the user interface and usability with releases around what is planned for early 2021.
Kowall also mentioned a new view of dependency mapping, such as that logz.io has contributed back to Jaeger and integration with Kibana, making it possible to move from tracks to log files. This may also have contributed to open source Jaeger at some point.
Last but not least, logz.io also advertises a Prometheus as a private beta service offering. This is an offer that integrates naturally with Prometheus and allows people to use Prometheus in a standard way integrated with the ELK stack and with Grafana.
Utilizes open source
logz.ios strategy is typical when it comes to capitalizing on open source projects: harden them and offer them as a service in the cloud with the aim of lowering the barrier to adopting and using them. Kowal mentioned the hidden cost of running open source, which is something we have also highlighted, and claimed logz.io makes it much more economical for users to run observability frames.
This is quite difficult to quantify, but it is an interesting offer. In any case, as far as we know, there is no distributed tracking as a service offering in the market at this time. Respondents from DevOps Pulse stated that there are plans for the coming years to get started. So it looks like an investment that pays off for logz.io.