feat(secretmanager): add OpenTelemetry distributed tracing samples

[chalmerlowe]

Add OpenTelemetry distributed tracing samples for Secret Manager.

There is a push to add OpenTelemetry (Observability) support to the GAPIC generated libraries.

This is a collection of samples that applies to Secret Manager, but is intended to help users of any GAPIC generated library to take advantage of the new Observability capabilities that are rolling out.

Note

For clarity:

• This new capability is NOT related to Google Cloud Trace (the UI). The traces that the generated code will produce are agnostic and can be ingested into any tracing UI backend (of which Google Cloud Trace is only one) and thus it should NOT go into python-docs-samples/trace which is specific to the Google Cloud Trace UI. We do include a sample to show users how to send traces to a backend (and for simplicity we point it at Cloud Trace).
• This new capability is not related to any existing observability capabilities that may exist in a handful of handwritten libraries (e.g. bigquery, etc). This is new to GAPIC generated code.
• The are some references to observability and the Cloud SDK CLI in the Google documentation but this is NOT related to that effort. This is focused on the Cloud SDK client libraries such as secretmanager, translate, etc.

[gemini-code-assist]

Code Review

This pull request introduces new Python snippets and unit tests demonstrating OpenTelemetry distributed tracing with the Secret Manager client libraries, covering synchronous, asynchronous, programmatic, and Google Cloud Trace configurations. The feedback highlights a critical anti-pattern where the global TracerProvider is initialized and shut down inside reusable functions, which can cause silent failures on subsequent invocations. The reviewer recommends moving the TracerProvider lifecycle management to the main entry points, updating the unit tests to set the global provider directly, and importing the root secretmanager module in the async snippet for consistency.

[snippet-bot]

Here is the summary of changes.

You are about to add 4 region tags.

• secretmanager/snippets/secretmanager_trace.py:18, tag secretmanager_enable_tracing
• secretmanager/snippets/secretmanager_trace_async.py:18, tag secretmanager_enable_tracing_async
• secretmanager/snippets/secretmanager_trace_client_options.py:18, tag secretmanager_trace_client_options
• secretmanager/snippets/secretmanager_trace_cloud_trace.py:18, tag secretmanager_trace_cloud_trace

---

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

• Refresh this comment

[chalmerlowe]

Remove unnecessary numbering on the comments.

[iennae]

Overall, these look really great!

I just have one minor nit regarding the filenames. I recommend including the specific API action in the filenames (e.g., renaming secretmanager_trace.py to secretmanager_get_secret_version_trace.py). While I understand these are meant to be general Secret Manager tracing examples, making the action explicit aligns better with our standard naming conventions and makes it immediately clear what the sample is doing.

I'm curious about the choice of get_secret_version for the trace sample. Did you consider tracing an add_secret_version operation instead? I'm wondering if a write/mutate operation might produce a more interesting trace output for a user to see. I realize get is easier to run cleanly without mutating state, so I don't have a strong preference—just wondering if an add would show off the tracing value better!

Not blockers for merging, thank you for improving observability!

Thank you!