RFC - Investigate Open Telemetry

[YOU54F]

Aim

Open Telemetry provides mechanisms for collecting information in an open, standardised manner. I wonder if this could potentially allow for an open mechanism to provide CLI app telemetry, collected in a centralised otel collector, such as BugSnag, or to a users own otel collector, either locally, or externally hosted.

Whilst I appreciate people have mixed views on telemetry in applications, there is certainly value in providing open datasets, for both maintainers, contributors and users to view / query, and to do it in an open manner, allows others to scrutinise and improve.

Additionally with the recent addition of CI/CD metrics as part of OpenTelemetry, being able to centralise that information as well, ideally to the same destination, would give us a pane of glass view over an organisation, which may consist of multiple projects (pact-foundation, for example have over 80)

Objectives

Identify viability of using OpenTelemetry for

• CLI telemetry
  • Which versions are in use
  • Which functions are being used
  • Where are users getting stuck
• CI/CD observability
  • Workflow metrics from GitHub Actions

Recommended Background Reading

• Blogs
  • https://www.cncf.io/blog/2024/11/04/opentelemetry-is-expanding-into-ci-cd-observability/
  • https://logz.io/blog/continuous-observability-cicd-pipelines/?utm_source=devrel&utm_medium=devrel
• Podcasts / Videos
  • Continuous Observability: Shedding Light on CI/CD Pipelines
• Technical Docs
  • https://opentelemetry.io/docs/specs/semconv/attributes-registry/cicd/
• Otel CI/CD existing related solutions
  • https://github.com/open-telemetry/community/blob/main/projects/ci-cd.md#existing-related-solutions
    • GitHub
      • https://github.com/krzko/opentelemetry-collector-contrib/tree/feat-add-githubactionseventreceiver/receiver/githubactionsreceiver
      • https://github.com/liatrio/liatrio-otel-collector/tree/main/receiver/githubreceiver
      • https://github.com/marketplace/actions/opentelemetry-export-trace
      • https://github.com/marketplace/actions/new-relic-opentelemetry-github-actions-exporter
      • https://github.com/krzko/run-with-telemetry
• BugSnag
  • DotNet
    • Setup BugSnag Client
      • Other .NET apps
    • Setup Performance Integration (OpenTelemetry)
      • https://docs.bugsnag.com/performance/integration-guides/dotnet/
  • OpenTelemetry
    • Demo application (GitHub)
  • GitHub
    • BugSnag Repositories
• OpenTelemetry
  • .NET OpenTelemetry SDK
  • Awesome OpenTelemetry List
  • Instrumentation
    • CI/CD Metrics
    • CLI Apps
    • .NET

[YOU54F]

Following the BugSnag guide for otel

• https://docs.bugsnag.com/performance/integration-guides/dotnet/#opentelemetry-sdk-installation

It leads me to the zero code docs

• https://opentelemetry.io/docs/zero-code/net/

There is auto instrumentation for Nuget apps

• https://opentelemetry.io/docs/zero-code/net/nuget-packages/

Although this needs to be run via an instrumentation script, which means it's not suitable for distribution.

I noticed a bug in the installer, but even after sorting this, I haven't got anything out of the app yet, so I assume I need to manually put some calls in, as the auto instruction probably only works with web apps

Anyway documented bug here noted on macos arm64 machines

osx-arm64 lib does not exist, so CORECLR_PROFILER_PATH is incorrect

Bug Report

Symptom

Install steps are incorrect for osx-arm64 target, when attempting to setup on MacOS with ARM64 processor, and set the wrong environment variable for CORECLR_PROFILER_PATH

This doesn't work as the release package for macos, only contains x64 libraries.

Expected behavior

CORECLR_PROFILER_PATH to point to a location that exists, either by way of providing an osx-arm64 library (preferable), over-riding the architecture of x64, if darwin is detected, in . $HOME/.otel-dotnet-auto/instrument.sh

Runtime environment (please complete the following information):

• OpenTelemetry Automatic Instrumentation version: [e.g. 1.0.0] - https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/releases/tag/v1.10.0
• OS: macOS - 15.2 -24C101
• .NET version: 7.0.410

Reproduce

Steps to reproduce the behavior:

Using steps from https://opentelemetry.io/docs/zero-code/net/#linux-and-macos

1. curl -sSfL https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/releases/latest/download/otel-dotnet-auto-install.sh -O
2. sh ./otel-dotnet-auto-install.sh
   1. error Set the architecture type using the ARCHITECTURE environment variable. Supported values: x64, arm64.
3. ARCHITECTURE=arm64 sh ./otel-dotnet-auto-install.sh
4. ls $HOME/.otel-dotnet-auto - only osx-x64 folder exists
5. . $HOME/.otel-dotnet-auto/instrument.sh
6. echo $CORECLR_PROFILER_PATH
   1. $HOME/.otel-dotnet-auto/osx-arm64/OpenTelemetry.AutoInstrumentation.Native.dylib

Workaround.

7. Update $HOME/.otel-dotnet-auto/instrument.sh to override the arch to x64

# find this section
ARCHITECTURE=${ARCHITECTURE:-}
if [ -z "$ARCHITECTURE" ]; then
  case $(uname -m) in
    x86_64)        ARCHITECTURE="x64" ;;
    aarch64|arm64) ARCHITECTURE="arm64" ;;
  esac
fi

# add the following to workaround osx-arm64 lib being unavailable
if [ "$OS_TYPE" = "macos" ] && [ "$ARCHITECTURE" = "arm64" ]; then
  ARCHITECTURE="x64"
fi