Span Metrics
Learn how to add custom metrics to your spans for enhanced performance monitoring and debugging.
To use span metrics effectively, you must first set up tracing in your application.
Span metrics allow you to track custom performance data and debugging information within your application's traces. There are two main approaches to instrumenting metrics:
- Adding metrics to existing spans
- Creating dedicated spans with custom metrics
You can enhance existing spans with custom metrics by adding attributes. This is useful when you want to augment automatic instrumentation or add contextual data to spans you've already created.
const span = Sentry.getActiveSpan();
if (span) {
// Add individual metrics
span.setAttribute("database.rows_affected", 42);
span.setAttribute("cache.hit_rate", 0.85);
// Add multiple metrics at once
span.setAttributes({
"memory.heap_used": 1024000,
"queue.length": 15,
"processing.duration_ms": 127,
});
}
When adding metrics as span attributes:
- Use consistent naming conventions (e.g.,
category.metric_name
) - Keep attribute names concise but descriptive
- Use appropriate data types (string, number, boolean, or arrays of these types)
For more detailed operations, task, or process tracking, you can create custom dedicated spans that focus on specific metrics or attributes that you want to track. This approach provides better discoverability and more precise span configurations, however it can also appear to create more noise in your trace waterfall.
Sentry.startSpan(
{
name: "Database Query Metrics",
op: "db.metrics",
attributes: {
"db.query_type": "SELECT",
"db.table": "users",
"db.execution_time_ms": 45,
"db.rows_returned": 100,
"db.connection_pool_size": 5,
},
},
() => {
// Your database operation here
},
);
For detailed examples of how to implement span metrics in common scenarios, see our Span Metrics Examples guide.
To consistently add metrics across all spans in your application, you can use the beforeSendTransaction
callback:
Sentry.init({
beforeSendTransaction(event) {
// Add metrics to the root span
event.contexts.trace.data = {
...event.contexts.trace.data,
"app.version": "1.2.3",
"environment.region": "us-west-2",
};
// Add metrics to all child spans
event.spans.forEach((span) => {
span.data = {
...span.data,
"app.component_version": "2.0.0",
"app.deployment_stage": "production",
};
});
return event;
},
});
Metric Naming
- Use clear, consistent naming patterns
- Include the metric category (e.g.,
db
,cache
,http
) - Use snake_case for metric names
- Avoid high-cardinality values in metric names
Data Types
- Use appropriate numeric types for measurements
- Use booleans for status flags
- Use strings for categorical data
- Use arrays when grouping related values
Performance Considerations
- Avoid adding too many metrics to a single span
- Consider the overhead of metric collection
- Use sampling when collecting high-frequency metrics
- Balance metric granularity with system performance
Debugging and Monitoring
- Include relevant error and status information
- Add timestamps for important events
- Include correlation IDs for related operations
- Add context that helps with troubleshooting
When implementing span metrics in your application:
Start Small and Iterate
- Begin with basic metrics that directly relate to your debugging or performance monitoring needs
- Add more detailed tracking as specific debugging needs emerge
- Remove metrics that aren't providing actionable insights
Maintain Consistency
- Use consistent naming patterns across your application
- Document metric meanings and units in your codebase
- Share common metrics across similar operations
Focus on Actionability
- Track metrics that help diagnose specific issues
- Consider what alerts or dashboard visualizations you'll want to create
- Ensure metrics can drive issue resolution or decision-making
For detailed examples of how to implement span metrics in common scenarios, see our Span Metrics Examples guide.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").