Glasnostic Expands Observability to Kubernetes
Glasnostic, a provider of an observability platform for application traffic, is making available an instance of its platform that supports Kubernetes via a private beta program.
Tobias Kunze, Glasnostic CEO, says Glasnostic’s observability platform is different in that it monitors subnet traffic to identify issues that are having a negative impact across a range of distributed applications. In contrast, other observability tools focus more on analyzing the performance attributes of one single application at a time, Kunze says.
In many cases, IT teams are employing Glasnostic to monitor and control application traffic across an entire IT environment before using other tools to drill deeper into specific application issues, Kunze adds.
In the case of Kubernetes, IT teams will be able to discover which pod, or group of pods, are communicating with each other, and how often. That capability will make it simpler to discover which services are running, observe runtime behaviors and apply policies to better control application traffic, says Kunze.
The Glasnostic approach provides the added benefit of not requiring IT teams to instrument every application with agents to discover that behavior, Kunze notes. That whole process is designed to be transparent to application development teams.
Currently, the most widely employed tool to monitor Kubernetes environments is open source Prometheus software, being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). A version of Prometheus must be installed on each Kubernetes cluster. It will be up to each IT team to decide the degree to which they employ a tool, such as Glasnostic, to observe the overall IT ‘forest’ in addition to employing tools to investigate a specific proverbial application ‘tree,’ says Kunze.
Observability is, of course, a core tenet of any DevOps workflow. However, achieving observability is challenging. Historically, most organizations have required developers to add agents to their software that need to deployed and updated. Those agents have allowed DevOps teams to monitor monolithic applications, but usually lacks the context to automatically resolve an issue. Instead, developers are simply armed with more data whenever a war room meeting is convened with IT operations teams to solve an issue.
With the rise of cloud-native applications with many dependencies on distributed microservices, collecting insights has become even more problematic. Applications may not fail outright as traffic is re-routed, but it’s more difficult than ever to ascertain the root cause of an issue. In fact, Kunze notes, to one degree or another, every application is being adversely impacted by some level of degradation. The challenge is determining to what degree, Kunze adds.
Glasnostic is making a case for network packets to be the most reliable source of the true state of the application environment. It’s not quite clear, however, who, within an IT organization, might drive adoption of tools that collect data about applications at the network level, rather than from the application itself.
Regardless of how observability is achieved, the need for it is becoming more apparent. The distinction between observability and simple monitoring may not be fully appreciated yet, but as IT environments become increasingly complex, it’s clear that the way IT has been traditionally managed is no longer sustainable.
