[receiver/sqlserver] Add session attributes to query sample event

[gdivya-nr]

This PR enriches the db.server.query_sample log event emitted by the SQL Server receiver with additional session-level attributes, providing more context about the client connection associated with each query.

New Attributes added:-

sqlserver.session.host_process_id- Process ID of the client application on the host system
sqlserver.session.started- Timestamp of when the session logged in (ISO 8601 format)
sqlserver.session.total_elapsed_time - Total elapsed time in seconds the session has been actively executing requests.
sqlserver.session.program_name - Name of the client application that initiated the session

Use cases:-
sqlserver.session.started and sqlserver.session.total_elapsed_time together enable detection of problematic session patterns: a session that connected hours ago (session.started) but has accumulated very little active time (total_elapsed_time) is likely idle or leaked — still holding locks or resources without doing meaningful work. Conversely, a session with high total_elapsed_time relative to its age indicates a long-running or repeatedly executing workload.

sqlserver.session.program_name and sqlserver.host.process_id allow DBAs to trace problematic queries back to the specific application or process that initiated them, making it easier to correlate database-level issues with application behavior across services.

Fixes:- 48346

Documentation

Added attribute definitions in metadata.yaml for:

• sqlserver.host.process_id: Process ID of the client application on the host system
• sqlserver.session.started: ISO 8601 timestamp of when the session logged in (also captured for idle blocker sessions)
• sqlserver.session.total_elapsed_time: Total elapsed time in seconds the session has been actively executing requests.
• sqlserver.session.program_name: Name of the client application that initiated the session

Testing
Verified collector starts and connects to SQL Server successfully
Confirmed queries execute without errors in logs

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gdivya-nr / name: Divya G (0057493)

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Read our Contributing Guidelines.
• Sign the CLA if you haven't already.
• First-time contributors should have at most one PR not marked as draft until their first PR is merged.
• If your change isn't one of our priority components, reviews may take more time.
• Give reviewers at least a few days before pinging them for feedback.
• If you need help or struggle to move your PR forward, raise the topic on #otel-collector-dev or a Collector SIG meeting.

[thompson-tomo]

Suggested change

	sqlserver.session.total_elapsed_time:
	sqlserver.session.duration:

[thompson-tomo]

Suggested change

	- sqlserver.session.total_elapsed_time
	- sqlserver.session.duration

[thompson-tomo]

Suggested change

	sqlserver.session.program_name:
	sqlserver.client.app.name:

[thompson-tomo]

Not sure that this brings any benefit so would remove iy

Suggested change

	sqlserver.session.host_process_id:
	description: Process ID of the client application on the host system.
	type: int
	requirement_level: recommended

But if it did it bring value it should be & opt-in

Suggested change

	sqlserver.session.host_process_id:
	description: Process ID of the client application on the host system.
	type: int
	requirement_level: recommended
	sqlserver.client.process_0.id:
	description: Process ID of the client application on the host system.
	type: int
	requirement_level: opt-in

[gdivya-nr]

Hi @thompson-tomo ,
During blocking or deadlock incidents, the host_process_id helps quickly correlate a SQL Server session back to the specific OS process on the client host. This is valuable for reducing MTTR, especially when multiple application instances are running on the same host.

It also helps identify misbehaving app instances — for example, if one PID holds 100+ sessions while others have 5, we can immediately tell which specific instance is leaking connections

[thompson-tomo]

Shouldn't the client metrics be used to see when it is misbehaving ie too many connections? You already know which host to look at

[gdivya-nr]

Thank you @thompson-tomo , for the comments and perspective!

host_name and client_address identify the machine, but not the specific process on that machine.

When multiple instances of the same application run on the same host, they share the same host_name, client_address, and program_name. host_process_id is the only way to distinguish between them.

client_tcp_port is too volatile: it captures the random, ephemeral outbound port assigned per socket at the network layer, so a single application instance running a connection pool of 100 connections will show up as 100 entirely unique ports.

[thompson-tomo]

I understand that but what I actually mean is that the client should be reporting the client metrics as described in https://opentelemetry.io/docs/specs/semconv/db/database-metrics/#connection-pools.

When the client reports those metrics it enables more efficient troubleshooting for the use case you mentioned.