Data observibility gives you important insight into the details of your services when they're report the right data. Things like distributed tracing and script instrumentation allow teams to quickly collect detailed telemetry data. Unfortunately, operations teams usually aren't in the best position to evaluate the quality of the telemetry they get, which can result in too much data which delays the ability to resolve problems in your system.
Revealing improperly instrumented services to users puts customer satisfaction at risk as teams release new features from code bases without knowing the links between software delivery and observability programs. Service instrumentation planning is the approach used to describe a single service runtime through telemetry, and this guide focuses on the metrics of your application's code as well as external measurements through synthetic testing.
You're a good candidate for using this guide if any of the following are true:
- Your development teams are disconnected from production observability design.
- You have new services/capabilities that run in production and before fully establishing telemetry and alerting.
- You need to provide additional business context to your instrumentation to improve diagnosis and business KPI measurement.
- You employ a highly customized or proprietary software framework.
- Your service is under active development. Legacy services, and services built from commercial-off-the-shelf platforms, tend to be better served with generic instrumentation options.
Making sure that you're capturing the right data can help your developers get more involved in the process of fixing issues when they arise by providing them relevant service data more efficienctly. Doing so will:
- Improve troubleshooting:
- Good telemetry naming gives operations staff a common language to use with developers during incidents, reducing the time to triage and fix problems.
- More precise and contextually relevant telemetry from your service allows for more accurate detection of faults that you can take action on.
- Make better informed development decisions by:
- Detecting areas of volatility or unexpected behavior and addressing them.
- Understanding what dependencies in your code lack redundancy and taking measures to improve the service.
- Appreciating how end-users are employing your software. You can better understand where improvements will have the biggest impact.
It's important know a few simple KPIs to track the ongoing improvements in your software delivery and operations programs. Here are two main types of KPIs to consider as you improve instrumentation:
- Business KPIs are aligned to your overall program objectives and should be consistently measured to demonstrate ongoing improvement for each service. Business KPIs include:
- Practitioner KPIs are used to measure changes in the execution of job functions for those participating in the development and management of services. Practictioner KPIs include:
As you work through the steps in the guide, keep the following documentation resources handy:
- APM agent install and configure
- Instrumentation guides:
- Introduction to New Relic synthetic monitoring
Choose one of the guides below based on what data you want to capture: