If you are familiar with instrumenting applications, you may have heard of OpenMetrics, OpenTracing, and OpenCensus. These projects aim to create standards for application performance monitoring and collecting metric data. Although the projects do overlap in terms of their goals, they each take a different approach to observability and instrumentation.

Forty-three percent of application performance problems occur because of an issue in the application code, according to a DZone study. Code-level issues include bugs in the code constructs, such as long waits, poor iterations, inefficient code algorithms, unhandled exceptions, bad choice of data structures, etc. Developers and application owners need code-level insight, so they can pinpoint issues in the code and fix them before users notice.

Jaeger is composed of different components, each potentially running in its own host. It might be the case that one of these moving parts isn’t working properly, causing spans to not be processed and stored. When something goes wrong, make sure to check the items listed here.

If you are running a distributed system and have reached a point of scale where you’re running 5+ services, you are more than likely experiencing difficulties when troubleshooting. Does the following sound somewhat familiar?

Custom Metrics (JMX, Golang expvar, Prometheus, statsd or many other), APM and Opentracing are different approaches on how to instrument code in order to monitor health, performance and troubleshoot your application more easily.