Leading your organization to use OpenTelemetry is a challenge. In addition to all the usual project hurdles, you’ll face one of these two situations: convince your teams to use OpenTelemetry, or convince them to move from the telemetry tool they are already using to OpenTelemetry. Most people don’t want to change. You’ll need lots of effort and baby steps. My tip is the following: the fewer the changes, the higher your chances of success.

Frankel's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and personal anecdotes, Frankel offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

A Java geek

Migrating an organization to OpenTelemetry is easier when you minimize changes. For JVM applications already exposing metrics via JMX, the OpenTelemetry JMX Metric Scraper lets you collect and forward MBean metrics to an OpenTelemetry Collector without touching the application itself. The post walks through setting up the scraper as a Docker container, configuring it with built-in presets (e.g., Tomcat, Kafka) or custom YAML rules, and wiring it into a stack with the OTel Collector, Prometheus, and Grafana. The key takeaway: reuse existing instrumentation assets to reduce change management overhead and improve adoption chances.

One tip for successful OpenTelemetry projects