Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:
For a list of supported locations, see Locations for observability buckets.
]]>You can collect, view, and analyze multimodal prompts and responses from your agentic applications that use the LangGraph or Agent Development Kit (ADK) frameworks. This feature is generally available (GA).
]]>The Trace API supports regional endpoints. For a list of supported endpoints, see the REST API reference pages:
]]>Custom dashboards can display trace data. You can view individual spans or aggregated data. This feature is public preview. For more information, see Display traces on a custom dashboard.
]]>To view the instrumentation scope or the schema associated with a span, open the Details view for the span and select the Metadata & Links tab. For more information, see View attributes, log entries, and events.
]]>The create-observability bucket flow enforces organization policies with constraints on resource locations. This flow also enforces policies that require customer-managed encryption keys (CMEKs) and that restrict the projects that store those keys. Your trace data is stored in an observability bucket.
For more information, see the following:
]]>The details page for a span can display the call hierarchy of a trace using a directed acyclic graph (DAG). One way to view a span's details is to open the Trace Explorer page and select the span. The DAG view is also available for some integrations. For example, if you view an Application Monitoring dashboard and explore the trace data it displays, the flyout supports the DAG option.
For more information, see the following:
]]>You can view the available regional endpoints for the Observability API and for the Telemetry API on their REST reference pages. For more information, see API overview.
]]>Cloud Trace in Observability Analytics is generally available (GA). Observability Analytics lets you query and analyze your trace data by using SQL. You can chart your query results, save your queries, and join your trace and log data.
For more information, see the following documents:
The Observability API is generally available (GA). This API lets you configure the following:
For more information, see the following documents:
Trace scopes are generally available (GA). For more information, see Create and manage trace scopes.
The following remote MCP servers automatically generate a trace span for
tools/call operations. These spans can help you understand the behavior of
your agentic applications. For more information, see
Investigate MCP calls using Trace.
Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:
For a list of supported locations, see Locations for observability buckets.
]]>The following remote MCP servers automatically generate a trace span for
tools/call operations. These spans can help you understand the behavior of
your agentic applications. For more information, see
Investigate MCP calls using Trace.
Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:
For a list of supported locations, see Locations for observability buckets.
]]>Cloud Trace is a service covered by the Cloud Observability (Monitoring, Logging, Trace) Service Level Agreement (SLA).
]]>Your trace data can be encrypted with a customer-managed encryption key (CMEK). To enable CMEK, set a default storage location and for that location, set a default Cloud Key Management Service key.
You can set these defaults for an organization, a folder, or a project. When set for an organization or folder, the settings apply to that resource and to its descendants. For more information, see Set defaults for observability buckets.
When you configure a default storage location, you control the location of your new observability buckets. These buckets store your trace data.
You can set a default storage location for an organization, a folder, or a project. When set for an organization or folder, the setting applies to that resource and to its descendants. For more information, see Set defaults for observability buckets.
]]>Use Cloud Trace to troubleshoot your MCP server usage, tool failures, and latency causes. For more information, see Investigate MCP calls using Trace.
]]>Google Cloud CLI lets you configure trace scopes, manage observability buckets, and set default observability settings. These features are in Public Preview. For more information, see the following documents:
Configure trace scopes by using the Google Cloud console, the Google Cloud CLI, Terraform, or the Observability API. For more information, see Create and manage trace scopes.
Manage trace storage by using the Google Cloud CLI or the Observability API. For more information, see Manage trace storage.
Configure default settings by using the Google Cloud CLI, Terraform, or the Observability API. For more information, see Set defaults for observability buckets.
For any new project that is created on or after March 30, 2026, if the project enables the Cloud Trace API, then Google Cloud Observability also enables the Telemetry API.
You can use the Cloud Trace API MCP server to let agents and AI applications interact with your trace data. This feature is in Preview.
]]>The Telemetry API supports trace ingestion of up to 2.4GB per minute for the following regions:
For all other regions, the Telemetry API supports trace ingestion of up to 300 MB per minute.
These regional byte-based quotas replace a global quota which limited the number of requests per minute. To learn more, see Telemetry API limits and quotas.
]]>Google Cloud Observability has expanded the supported locations for observability buckets, which store your trace data, to include the following:
For a list of supported locations, see Locations for observability buckets.
You can create alerting policies that monitor the results of your SQL queries. For more information, see Monitor your SQL query results with an alerting policy. This feature is in public preview.
]]>You can send trace data to your Google Cloud project by using the Cloud Trace API or the Telemetry API. These two APIs are enabled individually.
If you send trace data to the Telemetry API endpoint, then Google Cloud Observability requires that the Cloud Trace API be enabled on your Google Cloud project before it stores the trace data. If the Cloud Trace API is disabled, then Google Cloud Observability discards the trace data.
To learn more, see APIs that ingest trace data.
]]>For organizations, folders, and projects, you can now configure default settings for observability buckets. Default settings let you specify the following for new observability buckets:
This feature is in public preview. To learn more, see Set defaults for observability buckets.
You can now configure observability buckets to be in the following locations:
Your trace data is stored in an observability bucket. To learn more, see Trace storage overview.
]]>Starting February 18, 2026, trace sinks are deprecated. For more information, see Export trace spans with sinks deprecation.
You can use the Observability Analytics page, which provides a SQL query interface, to query both your trace and log data. To learn more, see the following documents:
To migrate to using Observability Analytics page from a sink-based export of trace data to BigQuery, see Migrate to Observability Analytics.
To query your trace data by using the Observability Analytics page, see Query and analyze traces.
To query your trace data by using BigQuery services, see Query a linked BigQuery dataset.
You can now analyze your trace data by using the Log Analytics page in the Google Cloud console. This page supports SQL queries and lets you view your query results as a table or as a chart. Your SQL queries can also join your trace and log data. This feature is in Public Preview.
To learn more about analyzing and viewing trace data, see the following documents:
Cloud Trace now stores your trace data in an observability dataset. You can continue to view your trace data by using the Trace Explorer page. If you create a link on your dataset, then you can use services like BigQuery to query and analyze your trace data. To learn more, see the following documents:
]]>To support correlation between log and trace data, the following changes have been made:
The required format for the LogEntry.trace field has been relaxed. The
preferred format for this field is the trace ID. However, you can continue
to provide the full resource name. For more information, see
LogEntry.
If you open the Trace Details flyout page by using options provided in a log entry, then the resources listed in the default trace scope are searched for the trace data.
If you open the Logs Explorer page by using options on span data, then the resources listed in the default log scope are searched for log data.
To learn more about default scopes, see Configure observability scopes for multi-project queries.
]]>You can now collect, view, and analyze multimodal prompts and responses from your agentic applications that use the LangGraph or Agent Development Kit (ADK) frameworks. This feature is in Public Preview.
To learn more, see the following documents:
]]>The Trace Explorer has been updated to include annotations that let you identify App Hub-registered services and workloads. The link provided with a service or workload lets you open the corresponding Application Monitoring dashboard. To learn more, see the following documents:
You can now collect, view, and analyze prompts and responses from your agentic applications when they are built with the Agent Development Kit (ADK). This feature is in Public Preview.
Collect and view multimodal prompts and responses describes how to do the following:
You can now create and manage the trace scope programmatically. This feature is in Public Preview. For more information, see the following documents:
]]>Application-specific resource attributes are attached to your trace data when your App Hub applications use supported Google Cloud resources, or when you instrument an application with OpenTelemetry and use the Google Cloud Telemetry endpoint. You can use the Trace Explorer to filter by your application, your service, or your workload. To learn more, see the following:
]]>The Analysis reports page has been removed. To analyze your trace data, use the Trace explorer page. You can use filters and the time-range selector to view and analyze historical data.
]]>