Repository navigation
RFC - Investigate Open Telemetry #43
Description
Activity
Following the BugSnag guide for otel
It leads me to the zero code docs
There is auto instrumentation for Nuget apps
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-arm64target, when attempting to setup on MacOS with ARM64 processor, and set the wrong environment variable forCORECLR_PROFILER_PATHThis doesn't work as the release package for macos, only contains x64 libraries.
Expected behavior
CORECLR_PROFILER_PATHto point to a location that exists, either by way of providing anosx-arm64library (preferable), over-riding the architecture of x64, ifdarwinis detected, in. $HOME/.otel-dotnet-auto/instrument.shRuntime 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
curl -sSfL https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/releases/latest/download/otel-dotnet-auto-install.sh -Osh ./otel-dotnet-auto-install.sh- error
Set the architecture type using the ARCHITECTURE environment variable. Supported values: x64, arm64.
- error
ARCHITECTURE=arm64 sh ./otel-dotnet-auto-install.shls $HOME/.otel-dotnet-auto- onlyosx-x64folder exists. $HOME/.otel-dotnet-auto/instrument.shecho $CORECLR_PROFILER_PATH$HOME/.otel-dotnet-auto/osx-arm64/OpenTelemetry.AutoInstrumentation.Native.dylib
Workaround.
- Update
$HOME/.otel-dotnet-auto/instrument.shto 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
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
Recommended Background Reading