Skip to content

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, the service.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 the spanMetrics 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 sets service.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:

export OTEL_RESOURCE_ATTRIBUTES="service.version=$(git rev-parse HEAD)"

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].