![]() ![]() ![]() ![]() The Operator is fairly simple to install once you have a GKE cluster provisioned. You can configure these Collectors and instrumentation through Custom Resources (explained in more detail later in this post). The two main functions of the Operator are managing OpenTelemetry Collectors and auto-instrumenting applications. Getting started with the OpenTelemetry Operator In this post, we’ll talk about some benefits of the OpenTelemetry Operator and how to use it. We gathered these under a single GitHub repository ( ) with the goal of providing a set of samples and walkthroughs for installing and working with the Operator. These two features help simplify both the onboarding process for new users and the day-to-day operational burden of monitoring fully-instrumented applications.Īcross this spectrum of use cases, we’ve identified a few common problems that can be easily solved using the OpenTelemetry Operator. It also automates the deployment of OpenTelemetry Collectors, which offer vendor-agnostic monitoring pipelines. The OpenTelemetry Operator is designed to provide auto-instrumentation to export traces and metrics in new and existing applications without any code changes. The community has also created a Kubernetes Operator to automate some of these solutions in containerized environments. The OpenTelemetry project has tried to address these problems with its open standard for telemetry data, multi-lingual instrumentation libraries, and “auto-instrumentation” of applications without needing code changes. But a major friction point is still the investment required to instrument applications with these libraries, and libraries are often tied to a small set of telemetry backends. In recent years, the application monitoring landscape has exploded with instrumentation libraries, SDKs, and backends for storage and visualization. ![]()
0 Comments
Leave a Reply. |