Records metrics using the opentelemetry global meter

[hardbyte]

More for discussion than seriously for merge.

Doesn't refactor as suggested in #86 but instead strips out all attempt to export metrics and just records using the opentelemetry global meter.

[ttys3]

Thanks for the PR

The refactor removes both the prom (pull) and OTLP (push) based exporter setup and initialization code.

This is good as it simplifies the crate code and makes it easier to maintain.

However, the code that has been removed will ultimately need to be handled by the end user.
You might consider making it a feature or creating a utility sub crate for it? (similar to how hyper has hyper-util)

[ttys3]

and also, we'd better keep some real test for prom and otlp, rather than remove it.
even we do not include the exporters in the lib, we may also need to test the crate works or not

[hardbyte]

I think leaving opentelemetry configuration outside the scope of this crate would make the most sense and aligns with e.g. axum-tracing-opentelemetry. Although I can see why you might want to have a one-stop-shop. Perhaps exporting via /metrics could still be supported using a different Layer behind a feature flag.

I put together a small demo using my fork at https://github.com/hardbyte/rust-telemetry-example/

The OTLP metric exporter is configured (with a few more options) here with:

fn init_meter_provider() -> opentelemetry_sdk::metrics::SdkMeterProvider {
    let exporter = opentelemetry_otlp::new_exporter()
        .tonic();

    let provider = opentelemetry_otlp::new_pipeline()
        .metrics(opentelemetry_sdk::runtime::Tokio)
        .with_exporter(exporter)
        .build()
        .unwrap();
    let cloned_provider = provider.clone();
    opentelemetry::global::set_meter_provider(cloned_provider);
    provider
}

Agree we'd still want tests! This was really just to see what it might look like and get the conversation started.