While many IT and engineering leaders understand the benefits of a comprehensive observability practice, achieving full visibility still presents some challenges. For example, instrumentation for new applications or off-the-shelf software often can be a time-consuming and complex process. As a result, engineering teams can be led to avoid observability in certain parts of their environments. When hurdles to observability exist and subsequently halt these efforts, systems are in more danger of disruptions or going completely dark. This can lead to serious business consequences such as financial losses, legal issues, and damage to brand reputation.
OpenTelemetry eBPF Instrumentation (OBI) makes getting this data a cinch. It allows engineering teams to confidently lean into observability without any manual setup steps. Consequently, teams can rapidly gain visibility into their services and infrastructure.
The Challenges to Complete Visibility
There are several hurdles related to comprehensive observability, ranging from instrumentation effort to setting up the correct alerts, dashboards, and more. While automatic instrumentation solutions have existed for language runtimes like the JVM, .Net CLR, and others, traditional auto-instrumentation approaches usually have trouble with compiled languages such as Go, Rust, and C++. With certain legacy services, the source code may be so old that it is extremely difficult to modify. Furthermore, with commercial-off-the-shelf applications, the source may not be accessible at all.
Today’s IT environments are also more complex than they’ve ever been, which can lead to observability complications. In enterprise-level organizations, there is commonly a mix of apps that were heavily instrumented with proprietary observability vendor software development kits (SDKs) and some apps that lack instrumentation altogether. This complex mix results in duplicate metrics and fragmented or missing data, making it harder for organizations to translate observability into actionable insights.
Lastly, security concerns can slow the implementation of a proper observability practice. Many observability agents require high-level permissions to function, which can raise concerns if they are closed source and the organizations deploying them can’t validate their software supply chain.
While these challenges are real for many organizations, the combination of eBPF and OpenTelemetry equally presents real solutions to break through these barriers.
Why eBPF and OpenTelemetry Are a Great Match
Combined, eBPF and OpenTelemetry offer instrumentation that strategically pulls back the obstacles to full-scale observability. OBI removes the requirement for code updates or application configuration changes. Thanks to eBPF, instrumentation occurs at the kernel level and provides instant, zero-code, visibility into an organization’s Kubernetes cluster or Linux environment. Removing the need to touch existing code or introduce new code to the application itself removes a whole class of code-related issues that businesses encounter when instrumenting their applications.
OBI is language agnostic. Regardless of the language an application is using, network traffic observability takes place at the protocol layer. There, organizations can gain insights from traces and metrics for any application. This is even true for legacy applications and applications where the source is unavailable.
Through eBPF, OpenTelemetry can also help organizations navigate some of the complexity and black box nature existent within modern IT systems. If an organization leverages an SDK for instrumentation, OBI can identify the instrumentation and avoid re-instrumenting the application. This technology also works to combine the best parts of OpenTelemetry’s automatic language runtime instrumentation with OBI.
When it comes to third-party software, the eBPF and OpenTelemetry combination monitors network calls to applications that aren’t easily instrumented — including databases such as SQL, Redis, and MongoDB — at the kernel level. There, it can provide Rate, Errors, and Duration (RED) metrics, helping narrow down the source of performance problems to applications or dependencies.
OBI also works seamlessly alongside existing OpenTelemetry auto-instrumentation to make adoption simple and risk-free. It intelligently detects services that are already instrumented and avoids duplicating telemetry. This ensures clean, accurate data without extra configuration.
Removing the Final Barrier to Entry for OpenTelemetry
OpenTelemetry has become the industry standard for gathering machine data; any observability practice is incomplete without it. It offers a wide range of advantages. This includes a large set of integrations, freedom to customize your data and send it to any destinations of your choice, and a consistent data model and semantic conventions.
Recently, Splunk donated the OpenTelemetry Injector, which led to easier, less intrusive instrumentation for applications written in most programming languages. With OBI, developed by Splunk and Grafana Labs, practically any application can now be observed without instrumentation, language, or security complications. In turn, everyone can build a leading observability practice. The best advantage, however, is one that extends past simpler instrumentation. OBI lets organizations spend less time instrumenting and experimenting with getting data out of the observability system. Now, engineers have more time to develop new features and enhance their organization’s overall applications and services.
Tools like the OpenTelemetry Injector and OBI underscore Splunk’s commitment to building an inclusive, resilient observability community. By enabling teams to more easily leverage OpenTelemetry, these tools help ensure data reaches its full potential while giving developers time back, reducing operational risk, and ultimately strengthening organizational resilience.
from DevOps.com https://ift.tt/ACs7jFY
Comments
Post a Comment