Remove Global Error handler.

[lalitb]

Fixes #2175

Needs #2259 #2257 #2256 to be merged first.

Changes

• Removed global::set_error_handler and global::handle_error, as the global_handle_error usage inside the opentelemetry crates has already been replaced with global::otel_info, otel_warn, otel_debug and otel_error

Migration Guide:

📌Note: This setup requires the internal-logs feature to be enabled for the OpenTelemetry crates. This feature is enabled by default, so application should ensure not to disable it explicitly for these crates in its Cargo.toml.

This guide explains how to migrate from global::set_error_handler to a new setup with otel_* macros and Tokio tracing. If your application previously used global::set_error_handler, remove it as part of this migration. If not, this configuration ensures errors previously going to eprintln! are now handled through structured tracing.

Step 1: Remove set_error_handler (if used)
If your code currently sets a custom error handler using global::set_error_handler, remove this line and any associated custom handler function.

// Remove any custom error handler
// global::set_error_handler(custom_error_handler).unwrap();

Step 2: Internal OpenTelemetry Logs Filter and Layer:
Set up a layer to handle OpenTelemetry internal logs and stop them from propagating to tracing bridge/appender.

1. Internal OpenTelemetry Logs Filter and Layer:
   • This layer captures logs with the opentelemetry prefix and prints them to eprintln!.

use tracing_subscriber::filter::filter_fn;
use tracing_subscriber::fmt::Layer;

let opentelemetry_layer = Layer::new()
    .with_writer(std::io::stderr)
    .with_filter(filter_fn(|metadata| metadata.target().starts_with("opentelemetry")));

2. Bridge Layer for OpenTelemetry Tracing (Excludes OpenTelemetry Internal Logs)::
   • To prevent logs with the opentelemetry prefix from propagating further, apply a filter_fn in this layer that excludes any logs with the opentelemetry target prefix.

use opentelemetry_appender_tracing::layer;

let non_opentelemetry_filter = filter_fn(|metadata| !metadata.target().starts_with("opentelemetry"));
let otel_bridge_layer = layer::OpenTelemetryTracingBridge::new(&cloned_provider)
   .with_filter(non_opentelemetry_filter);

Step 3: Register Layers in the Tracing Registry

use tracing_subscriber::prelude::*;

tracing_subscriber::registry()
    .with(opentelemetry_layer)       // OpenTelemetry internal logs (filtered out)
    .with(otel_bridge_layer)         // OpenTelemetry tracing bridge
    .init();

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[cijothomas]

Given this is breaking change, we need to add it to changelog. and also show a migration guide for anyone who were relying on this previously.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.5%. Comparing base (eca53b2) to head (c61db83).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2260   +/-   ##
=====================================
  Coverage   79.4%   79.5%           
=====================================
  Files        121     121           
  Lines      20981   20960   -21     
=====================================
- Hits       16673   16671    -2     
+ Misses      4308    4289   -19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lalitb]

Given this is breaking change, we need to add it to changelog. and also show a migration guide for anyone who were relying on this previously.

Done/

[cijothomas]

LGTM.
I'll try our self-diagnostics with few scenarios later and make suggestions, if any. (I am a customer of the internal logs !!)

[mdecimus]

Hi,

We just migrated from opentelemetry-otlp 0.25 and found out about this change. The otel_* macros seem to support only tracing which is an issue for us as we do not use it. Do you have any plans to support custom logging mechanisms or would you accept a PR for this?

[cijothomas]

Hi,

We just migrated from opentelemetry-otlp 0.25 and found out about this change. The otel_* macros seem to support only tracing which is an issue for us as we do not use it. Do you have any plans to support custom logging mechanisms or would you accept a PR for this?

Yes, we just started with tracing, and more improvements are needed, including providing a different feature-flag, that'd fire callbacks instead of using tracing.
#2697 (comment)

Can you submit a new issue with some more details on the proposal, or can send a draft PR to support this?

[mdecimus]

Thanks, I've just opened #2992 where I also explained another minor issue related to SdkLogRecord.