Group by Service Version
Grouping service metrics by version provides you with detailed insights into your service's performance across different versions. By breaking down key metrics such as Requests, Latency, Apdex, and Top Errors for each version, you can effectively track the impact of each deployment, compare versions running simultaneously in different environments, and quickly identify version-specific issues. This enables more precise monitoring and troubleshooting, ensuring that each release meets performance expectations.
Group your services by version to:
- Quickly identify regressions by detecting performance degradations associated with a specific version.
- Assess the success of version updates by analyzing performance improvements and stability after each release.
- Compare new version performance across various environments.
- Monitor phased rollouts of new versions to ensure a seamless and controlled deployment process.
- Facilitate canary deployments by comparing metrics from the new version with those of the current stable version, helping to inform decisions on full rollouts.
This level of granularity enables you to track trends over time, quickly identify issues, and make informed, data-driven decisions to maintain reliable, high-performing services.
Enable grouping by version
-
Ensure that the
service.version
process tag is included in your spans to track version deployments. In this case, theservice.version
tag is an attribute that designates the exact version used to identify an artifact. This may be a git hash (8ae73a) or an arbitrary version string (0.1.2.20210101), whatever was used when building the artifact. -
If you use Span Metrics, the relevant labels are added by default to the latest Coralogix OTel collector configuration values.yaml. If you're using an older version of the collector, make sure to configure it to include
service.version
in thespanMetrics
dimensions. For details, see the Span Metrics configuration documentation.
Note
The Group by version option in APM is enabled if the system detects that the organization has been using the service.version
process tag in any of the services over the past 7 days. If this process tag is not identified, the Group by version option will not be displayed in the Overview widgets within the UI.
Display data per service version
Version data is available for the Requests, Errors Top 5 Operation, Apdex and Latency widgets.
-
At the top left-hand corner of any supported Overview widget, use the drop-down list to invoke the By Version view for the widget. The widget changes to display its metric data distribution among the service versions and its legend shows the available version strings.
-
For the Latency widget, select the desired latency metrics (P99, P95, P75, or Avg) to view the performance of each version based on the chosen metrics.
Deployment tips and examples
This section includes an example of a Kubernetes deployment, along with useful deployment best practices.
Adding the service.version
attribute using OTEL_RESOURCE_ATTRIBUTES
Some users may want to set the OpenTelemetry resource attribute service.version
to their Git commit hash or container image version. This can be done by configuring the OTEL_RESOURCE_ATTRIBUTES
environment variable with the desired version value, which can be sourced from the pipeline or deployment configuration.
OTEL_RESOURCE_ATTRIBUTES
is an environment variable that specifies key-value pairs for OpenTelemetry resource attributes.- The
service.version
attribute is part of OpenTelemetry resource semantic conventions, commonly used to indicate the version of the service generating telemetry.
Kubernetes deployment
The following example illustrates how the container image version (myapp:v1.1.2
) is passed into OTEL_RESOURCE_ATTRIBUTES
to represent the service version.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
labels:
app: myapp
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v1.1.2
ports:
- containerPort: 8080
env:
- name: MYAPP_ENV
value: "production"
- name: OTEL_RESOURCE_ATTRIBUTES
value: "service.version=v1.1.2"
where:
image: myapp:v1.1.2
: The container image version (in this case,v1.1.2
) represents the version of the service.env: - name: OTEL_RESOURCE_ATTRIBUTES
: The environment variable setsservice.version
to match the container image version.- Each Kubernetes deployment (representing a service) will include the
OTEL_RESOURCE_ATTRIBUTES
environment variable, ensuring consistent version tagging across spans and telemetry.
Pipeline integration tip
You can dynamically inject the commit SHA or container version into OTEL_RESOURCE_ATTRIBUTES
from your CI/CD pipeline. For example:
Alternatively, use Helm values to automatically inject the container version during deployments.
Important
- This approach works provided the user is using the OpenTelemetry SDK, as the SDK automatically reads the OTEL_RESOURCE_ATTRIBUTES.
- If using auto-instrumentation, this environment variable is automatically respected by OpenTelemetry agents.
References
Support
Need help?
Our world-class customer success team is available 24/7 to walk you through your setup and answer any questions that may come up.
Feel free to reach out to us via our in-app chat or by sending us an email at [email protected].