OpenTelemetry tracing and metrics

Hello, thanks for the great work.

I am working on .NET Aspire integrations for Firebird and wonder if the .NET data provider is instrumented with OpenTelemetry tracing and metrics?

Here are the common attributes for client metrics.
https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-metrics.md

@willibrandon

Thanks @willibrandon. I will start to work on it now.

I just pushed into #1200 the last "pillar of observability" that was missing (metrics).

I chose not to implement all OpenTelemetry suggested metrics because, frankly, some are really questionable. But it is a good start.

Have a great weekend! 😄

@fdcastel

@fdcastel - Taking your changes for a run 🏃

I can foresee extension method APIs for MeterProviderBuilder and TraceProviderBuilder that could be created in order to assist in subscribing to FirebirdSql.Data OpenTelemetry tracing and metrics.

/// <summary>
///  Extension method for setting up FirebirdSql.Data OpenTelemetry tracing.
/// </summary>
public static class TracerProviderBuilderExtensions
{
	/// <summary>
	///  Subscribes to FirebirdSql.Data activity source to enable OpenTelemetry tracing.
	/// </summary>
	public static TracerProviderBuilder AddFirebird(
		this TracerProviderBuilder builder)
		=> builder.AddSource("FirebirdSql.Data");
}

/// <summary>
///  Extension method for setting up FirebirdSql.Data OpenTelemetry metrics.
/// </summary>
public static class MeterProviderBuilderExtensions
{
	/// <summary>
	///  Subscribes to FirebirdSql.Data meter to enable OpenTelemetry metrics.
	/// </summary>
	public static MeterProviderBuilder AddFirebird(
		this MeterProviderBuilder builder)
		=> builder.AddMeter("FirebirdSql.Data");
}

Regarding the extension methods, I believe the best course of action would be to create a new package OpenTelemetry.Instrumentation.FirebirdSql, in line with OpenTelemetry guidelines.

This would allow the FirebirdSql.Data.FirebirdClient project to remain free of any OpenTelemetry packages dependencies.

However, I've deferred this discussion once the instrumentation code is more refined.

So, please give it a try in real scenarios and bring us your feedback. So far, I’ve only tested it within the Aspire Dashboard (and OpenObserve) on my end with some basic use cases.

Will do. Initially I was motivated because I saw a gap with Aspire integrations, but now I see this could be more useful than that. Where I work we are responsible for a large and growing number of Firebird databases running in retail stores across the United States. There, I support a small team of database administrators who I know would appreciate additional metrics, logs, and traces to help them analyze our software's performance and behavior. I will try and get their feedback.

Please note that Aspire Dashboard never intended to be a production system. Is more a "developer helper"
(or, in Microsoft words, "purpose-built to enhance the development experience").

If you want something battle tested, Seq is probably a good option. Though, of course, there are several other professional options available.

And, on a completely unrelated note, it’s great to hear that Firebird is being utilized in large-scale operations in the U.S.! 🚀

First off, thank you for putting together this OpenTelemetry instrumentation proposal! I’ve done some initial testing in real scenarios, and here are a few thoughts and observations:

Tracing
- Having Activity spans around each command is great—it fits well with how other ADO.NET providers handle telemetry. The use of attributes like db.system and db.query.text (or db.statement) is aligned with OpenTelemetry conventions.
- I especially appreciate that exceptions are caught and recorded properly in the span. It’s very helpful for diagnosing issues.
Metrics
- The new histograms (db.client.operation.duration, etc.) and counters (db.client.connection.count, db.client.connection.max) give valuable insights into query performance and connection pool usage. It’s easy to see at a glance when we’re approaching pool limits.
Connection Instrumentation
- Measuring Open() and OpenAsync() times is really useful. If you ever plan to capture “time waiting for a connection from the pool,” that might be a nice next step.
Performance & Logging
- Overall, overhead seems minimal when no listeners are attached. Using Microsoft.Extensions.Logging is also a nice modernization, letting us plug in our existing log pipeline.
- Parameter logging toggles are a great touch—some environments can’t store full param data, so having a quick way to disable that is appreciated.
Potential Small Tweaks
- You may want to rename a couple of attributes (e.g., db.statement instead of db.query.text) to exactly match OTel specs, but that’s more of a nitpick than a requirement.
- Sanitizing or truncating large SQL statements or sensitive parameter values might be worth considering in certain scenarios.

Overall, this is a fantastic addition and makes the Firebird ADO.NET experience much more observability-friendly. Thanks again for taking the time to implement these changes—I’m looking forward to continuing to test them out and will share more feedback as I gather more data in production environments.

@willibrandon

Thank you @willibrandon for the valuable feedback. 👍🏻

I will be away for the next ~10 days but I will surely address your suggestions upon my return.

Meanwhile, if you can, please provide more detailed points you would like to see addressed.

Whenever possible, citing sources. E.g. Where did you get that db.statement is the recommended attribute name? I got db.query.text from here.

@cincuranet

@cincuranet What about the creation of a new package as discussed here?

@cincuranet

@cincuranet Additionally, if possible, could you offer guidance on how to measure the 'time spent waiting for a connection from the pool,' as referenced by @willibrandon in the third point?

@fdcastel

@fdcastel Thanks for the update, and I really appreciate you taking time to review this in detail! I realize now that my mention of db.statement came from an older version of the OpenTelemetry specs, where that attribute was commonly used. The latest Database Client Semantic Conventions indeed recommend db.query.text for the full SQL text and potentially db.query.summary for a lower-cardinality representation.

Sorry for any confusion that caused—your reference is spot on. I look forward to refining the implementation with the new guidance once you’re back. In the meantime, if there are any other details you’d like me to clarify or test, just let me know!

I realize now that my mention of db.statement came from an older version of the OpenTelemetry specs

You're not alone! 😅 When I was coding, I ended up using an old version of the document for a good chunk of it.

Eventually, I caught my mistake and updated the attributes to match the latest version.

In the meantime, if there are any other details you’d like me to clarify or test, just let me know!

If possible, please share any other additional metrics/attributes you think are relevant for your real-world scenario.

As I said earlier I tried to stick to the specs exactly, but some of them seemed pretty useless. So, I left those out -- at least until someone can show me a solid reason to include them.

@fdcastel

@fdcastel

What about the creation of a new package as discussed #1196 (comment)?

We don't need separate package. .NET has all the pieces in the box (Activity, ILogger, ...) and OTEL plugs into (or rather on top) it.

Navigation Menu

Repository navigation

OpenTelemetry tracing and metrics #1196

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OpenTelemetry tracing and metrics #1196

Description

Activity

willibrandon commented on Oct 25, 2024

fdcastel commented on Oct 26, 2024

fdcastel commented on Oct 26, 2024

willibrandon commented on Oct 30, 2024

willibrandon commented on Oct 30, 2024

fdcastel commented on Oct 30, 2024

willibrandon commented on Oct 31, 2024

fdcastel commented on Oct 31, 2024

fdcastel commented on Oct 31, 2024

willibrandon commented on Dec 23, 2024

fdcastel commented on Dec 23, 2024

fdcastel commented on Dec 23, 2024

fdcastel commented on Dec 23, 2024

willibrandon commented on Dec 23, 2024

fdcastel commented on Dec 23, 2024

cincuranet commented on Jan 6, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions