Cloud Logging Queries, Exports and Redaction

Analyzing logs using the Logs Explorer and the Logging query language means filtering stored log entries with precise Boolean expressions and then diagnosing them with visual tools. Cloud Logging (opens in a new tab) uses the same Logging query language in Logs Explorer, the Logging API entries.list method, the gcloud logging read command, and in filters for sinks and log-based metrics. Every query tests indexed LogEntry fields such as resource.type, severity, logName, timestamp, textPayload, jsonPayload, and protoPayload.

1.1Constructing Filters with the Logging Query Language

The Logging query language builds filters from comparisons joined by logical operators. A comparison is either a global value or a [FIELD_NAME] [OP] [VALUE] test, joined as expression = ["NOT"] comparison { ("AND" | "OR") ["NOT"] comparison }. A simple restriction such as resource.type = "k8s_cluster" tests one field, a conjunctive restriction such as resource.type = "k8s_cluster" AND severity = "ERROR" requires both tests, and a disjunctive restriction such as resource.type = ("k8s_cluster" OR "gce_instance") matches either value. Parentheses control order in complex expressions such as resource.type = "k8s_cluster" AND (severity = "ERROR" OR "error").

Separate lines in the query editor join with an implicit AND, so resource.type = "gce_instance" on one line and severity >= "ERROR" on the next line evaluates as both conditions together. Logical operators AND, OR, and NOT must be capitalized, while field names and most string comparisons are not case sensitive. Queries cannot exceed 20,000 characters, and regular expressions remain case sensitive even though the rest of the language is case-insensitive. Resource, severity, and log-name filters narrow results to the exact source, for example resource.type = "gce_instance" AND severity >= "ERROR" AND NOT textPayload:robot, where >= "ERROR" includes ERROR and higher severities.

Log names must use the full encoded path because the short display name does not match. The Admin Activity audit log is named cloudaudit.googleapis.com/activity, so the correct test is logName = "projects/my-project-id/logs/cloudaudit.googleapis.com%2Factivity" with %2F for the slash. A precise source filter combines that encoded logName with nested labels such as resource.type = "gce_instance" AND resource.labels.instance_id = "6731710280662790612".

1.2Filtering by Payload Content, Time, and Query Speed

Payload and time filtering isolates the exact message and failure window while keeping queries fast. The path textPayload tests unstructured text, jsonPayload.my_favorite_cat tests a field inside JSON, and protoPayload.metadata.event.eventName tests an audit event name, for example protoPayload.metadata.event.eventName = "password_edit" with resource.type = "audited_resource" for Workspace login auditing. Checking one entry first reveals the correct label and payload names before those paths are used broadly. Time filtering uses the timestamp field with RFC 3339 values that include the letter T, so 2023-06-27 14:40:00-04:00 becomes 2023-06-27T14:40:00-04:00, and a bounded range such as timestamp >= "2023-06-27T12:40:00-04:00" AND timestamp <= "2023-06-27T14:40:00-04:00" selects only entries between two times.

The match operator controls whether the test is exact or partial. The following comparison shows three supported matching styles:

A bare quoted value such as "Hello Kitty" is a global restriction that implicitly searches every field and payload, so it is the slowest form. Index-friendly queries prefer conjunctive AND tests on indexed fields such as logName and resource.type and avoid global or substring searches. Queries that use only AND, such as SEARCH("foo") AND SEARCH("bar"), can use indexes better and run faster than OR queries such as SEARCH("foo") OR SEARCH("bar"), which are slow. When OR is required, grouping clauses with parentheses preserves the intended logic.

1.3Navigating Logs Explorer with Timeline, Fields, and Trace Correlation

Logs Explorer is the Google Cloud console interface for displaying, parsing, and analyzing log entries stored in log buckets. The Logs Explorer interface combines five coordinated areas: the Query pane builds filters, the Fields pane surfaces field values and patterns, the Timeline visualizes entries across the selected time range, the Query results pane lists matching entries, and the primary toolbar controls time range, streaming, sharing, and display preferences. The toolbar manages scope and presentation through the query library for recent and saved queries, share links that preserve the absolute time range, preferences for showing the Timeline and Fields panes and configuring sorting and line wrapping, the time-range selector, log streaming as entries are stored, and learning links.

The Timeline pane shows how matching entries distribute across the selected time range, so a sudden spike, gap, or cluster signals a behavior change to drill into in the Query results pane. The page searches entries that originate in the selected project, folder, or organization, including entries routed to the project by a sink in another project and then stored in a log bucket. The Fields pane parses entry fields so anomalous values and high-cardinality dimensions can be spotted without reading every payload, and summary fields highlight repeating patterns such as a failing version or resource type. Severity provides the second triage signal, where severity >= "ERROR" isolates error and critical entries from a single resource type.

Correlation in Logs Explorer groups entries that share the same trace field into a parent-child view, which simplifies tracing one request across distributed microservices. Trace context originates from instrumentation with OpenTelemetry, where trace and span IDs flow in OTLP data, or from native writers such as App Engine standard environment, Cloud Run functions, and Cloud Run, while Compute Engine and Google Kubernetes Engine (GKE) include trace data when they use the Ops Agent or OpenTelemetry Collector. For Logs Explorer to correlate entries, all of the following requirements must hold: the trace field is set to TRACE_ID or projects/PROJECT_ID/traces/TRACE_ID, the trace value is the same across the group, each entry has a different logName value, and the parent timestamp is no later than any child timestamp.

To view and search correlated entries in Logs Explorer, follow this order:

1. Open Logs Explorer and select Correlate by: Go to Logs Explorer and, in the Correlate by menu, select the parent log name, for example request_log for App Engine.
2. Review parent rows and expand: The Query results pane shows one row per parent entry; click Expand this log entry to reveal nested children that share the trace ID within the query time range.
3. Filter the correlated set: Enter a search term or update the query expression and click Run query to show only correlated entries that contain the term.

If an expanded parent shows no children, no other entries within the query time range share that trace ID, so widening the time range or removing an overly restrictive filter is the next step.

1.4Converting Log Queries into Metrics and Analytics Assets

Converting log queries into metrics and analytics assets turns a one-time troubleshooting filter into a saved query or continuously evaluated signal. The same Logging query language expression runs in Logs Explorer, the Logging API, and the Google Cloud CLI, so a filter validated in the console can later run through gcloud logging read or entries.list without changing logic. When counting, grouping, or trending is needed, the workflow moves from Logs Explorer to Observability Analytics or to a log-based metric that feeds Cloud Monitoring. Observability Analytics (opens in a new tab) in this context refers to SQL-based aggregation over upgraded log buckets.

The choice between Logs Explorer and Observability Analytics depends on inspecting entries versus generating grouped insights:

Logs Explorer does not support aggregate operations like counting entries that contain a pattern. To perform aggregation, analytics must be enabled on the log bucket and then Observability Analytics must be used against log views with system-defined schemas or analytics views with user-defined schemas. Upgrading a bucket does not affect Logs Explorer, which only requires storage in a log bucket, but entries written before the upgrade become analyzable only after backfill completes, which can take several days. Linked BigQuery datasets allow BigQuery to query log data without exporting it.

Log-based metrics are custom metrics derived from matching entries that track behavior over time in Cloud Monitoring. A log-based metric applies a Logging query language filter to incoming entries, so every new match contributes to the metric time series. That time series flows from Cloud Logging to Cloud Monitoring, where it can be charted and attached to an alerting policy, for example counting accesses to sensitive content and alerting when accesses exceed a threshold. The Analyze results path converts a Logs Explorer result set into SQL by translating the current query when the button is clicked, but the button appears only when at least one selected log view sits on an upgraded bucket. The generated FROM clause depends on scope: project logs query the _Required and _Default buckets, N log view scope queries views in the current project, and custom scope applies the same rules to listed resources. Observability Analytics cannot query across projects or regions and cannot query buckets with field-level access controls.

Exporting and retaining logs means routing copies of log entries from Cloud Logging (opens in a new tab) to central destinations and keeping them for the required time at the lowest cost. Cloud Logging routes entries through sinks to a central logging bucket, Cloud Storage, BigQuery, or Pub/Sub, and each destination enforces its own retention and access controls. Retention in Cloud Logging buckets is configurable from 1 day to 3650 days, while exported copies use destination controls such as retention locks and partition expiration.

2.1Securing Log Pipelines and Implementing Compliance Retention Policies

Securing log pipelines and implementing compliance retention policies controls who can write and read logs while keeping copies for the required time. A log sink is the routing rule that sends matching entries to a supported destination, including an aggregated sink that collects logs from all projects in an organization or folder. Every sink has a writer identity, which is a Google-managed service account created for that sink, and log flow from the sink to the destination succeeds only after that identity is granted write permission on the destination. Read access to the destination is configured separately, so analysts do not need the same permissions as the pipeline.

Securing the pipeline requires strict separation of Identity and Access Management (IAM) roles for sink management, destination access, and analysis:

• Project IAM Admin to grant the Logs Writer role on the destination log bucket
• Storage Admin to grant Storage Object Viewer on the storage bucket hosting exported logs
• Create Service Accounts to create supporting service accounts
• Service Usage Admin to enable required APIs
• Logging Admin to upgrade a bucket for analysis and delete imported logs
• Cloud Run Developer to create and modify import jobs

Access to audit logs must be restricted to authorized personnel with unique accountability. Admin Activity audit logs are always written and cannot be configured, excluded, or disabled, even if the Cloud Logging API is disabled, so monitoring for administrator activity depends on protecting this immutable stream. Bucket-level retention applies to the entire log bucket for 1 to 3650 days regardless of log type or whether the log was copied from elsewhere, so logs with different compliance needs must be placed in different buckets. A central bucket for organization-wide analysis is created in a fixed location of global, us, or eu, and the region cannot be changed after creation. Retention policies should use Bucket Lock to prevent early deletion.

2.2Evaluating and Selecting Destination-Specific Log Architectures

Evaluating destination-specific log architectures matches an operational requirement to the Google Cloud destination served through a Cloud Logging sink. A Cloud Logging sink routes copies to Cloud Storage, BigQuery, or Pub/Sub, while an aggregated sink collects logs from any or all projects in an organization into one central destination. The choice determines how long logs are kept, how they are queried, how quickly they can leave Google Cloud, and what ingestion and storage costs apply. Centralized log destinations (opens in a new tab) flow from source projects through a sink filter to a single Logging bucket, BigQuery dataset, Pub/Sub topic, or Cloud Storage bucket in an aggregation project.

Storage, analysis, and streaming destinations serve different access patterns:

For third-party security information and event management (SIEM) use, the sink must first aggregate logs in Pub/Sub or Cloud Storage before the tool pulls them. If the predefined exportable set meets needs, Google Security Operations can ingest those logs directly without a sink. Cloud Storage provides low-cost archival, BigQuery provides SQL search over large volumes, and Pub/Sub forwards to other applications and third parties including third-party SIEM systems. In BigQuery, default partition expiration automatically drops old partitions to control cost, while in Cloud Storage a retention policy with Retention Lock provides immutability. Because Data Access audit logs can be very large, excluding non-useful Data Access logs in development projects controls cost without weakening Admin Activity coverage.

2.3Designing and Configuring Log Sinks and Routing Filters

Designing and configuring log sinks and routing filters controls where copies of entries go after Cloud Logging receives them. The Log Router evaluates every incoming entry against sinks, and each sink with a matching filter forwards a copy to its destination while the original continues to its log bucket. One entry can therefore be stored locally, copied to long-term storage, and streamed elsewhere at the same time. A sink defines a destination resource plus a filter, and routing to Pub/Sub enables forwarding outside Google Cloud.

Choosing between project-level and aggregated sinks determines coverage. A project-level sink routes only logs generated in its project, while an aggregated sink created at the organization or folder level routes logs from any or all child projects to a single destination. Aggregated sinks centralize audit logs from one control point into one Logging bucket for Observability Analytics or one BigQuery dataset for cross-project queries. If that central sink already exists, a new export updates the existing sink filter rather than creating a new sink.

Controlling traffic with inclusion and exclusion filters determines which entries consume storage and cost. The sink inclusion filter selects which entries forward to the destination, from all logs to a precise match on log name, service, severity, or resource. Exclusion filters prevent matched entries from being stored or forwarded, which reduces volume when noisy logs push projects over allotments. Precise filters commonly target activity for Admin Activity, data_access for Data Access, system_event for System Events, and policy for Policy Denied logs. Data Access logs drive storage cost, so development projects often exclude them while production routes them to BigQuery or Cloud Storage.

Building the ordered centralized export pipeline aggregates logs through a fixed sequence:

1. Set up a single destination: Create the central Logging bucket with gcloud logging buckets create or the central BigQuery dataset with bq mk in the aggregation project.
2. Create an aggregated log sink: Define the sink at the organization or folder level with a filter that selects logs across child projects.
3. Grant access to the sink: Grant the sink writer identity permission to write to the destination bucket, dataset, or topic.
4. Configure read access to the destination: Grant analysts and security tools permission to read the central bucket or dataset.
5. Verify that logs are routed: Confirm that new matching entries arrive and are queryable, and adjust the filter if expected logs are missing.

Bucket location is fixed at creation to global, us, or eu, with global used when unspecified, and the region cannot be changed afterward. A separate bucket is recommended instead of reusing _Default so retention, location, and analytics upgrades stay isolated. Cloud Logging encrypts content at rest by default, with customer-managed encryption keys (CMEK) available for stricter control.

Handling sensitive data in logs means preventing, hiding, or transforming regulated fields such as personally identifiable information (PII) and protected health information (PHI) while keeping logs useful for debugging and auditing. Redaction with Cloud Logging (opens in a new tab) starts before ingestion by keeping sensitive values out of payloads, continues at read time with views and field masks, and extends to transformation when utility must be preserved. Audit logs never include resource data contents or query results, but they capture resource metadata, so names, labels, and request fields must be treated as a redaction boundary.

3.1Configure and Implement Log Redaction with Cloud Logging

Log redaction with Cloud Logging prevents regulated values from leaking through viewers, exports, or analytics. Prevention is the most reliable control because data that is never logged cannot leak, so producing workloads must not place PII, PHI, or credentials in experiment output, secondary log servers, resource metadata, build files, or request fields that Cloud Logging will capture. This rule applies across services where operational fields flow directly from the source system to log storage.

Sensitive values commonly leak through operational fields that appear harmless:

• Metric labels, virtual machine (VM) labels, GKE resource annotations, dashboard titles, and alerting display names and documentation, which monitoring permission holders can read
• API Gateway headers, Fraud Defense URIs and actions, Cloud CDN cache keys, and Cloud Build configuration files and build artifacts
• Application Integration IntegrationParameter values, Integration Connectors connection names and configuration, and Knowledge Catalog lineage Process.attributes and Run.attributes values
• Identity Platform optional attributes, federated tokens and claims, anonymous accounts, and client-side SDK output
• Artifact Registry artifact names and other metadata visible to artifact readers

Visibility controls separate what is stored in a log bucket from what each principal can read at query time. The following comparison shows the two bucket-level mechanisms:

Field-level access is finer, but it carries an analytics tradeoff. Observability Analytics cannot query buckets that have field-level access controls configured, so log views must be chosen when analytics compatibility matters. Transformation with Sensitive Data Protection (opens in a new tab) preserves utility through pseudonymization, de-identification, tokenization, and generalization such as bucketing, so analysts can join or count records without seeing raw identifiers. Data flows from the source log through inspection to a de-identified output for governed analysis. Secure destinations keep redacted logs available: exports go to Cloud Storage for archival and to BigQuery for analysis, with separate access controls, where the Logs Viewer role grants Admin Activity logs and the Private Logs Viewer role grants Data Access logs.

3.2Identify and Classify Sensitive Data in Log Streams

Identifying and classifying sensitive data finds where regulated information appears in telemetry and labels it by type and risk before storage or export. Cloud Logging collects text payloads, resource metadata, labels, and audit events, and any field can carry PII or PHI if applications place it there. Classification uses Sensitive Data Protection infoTypes, which are named detectors for patterns such as credit card numbers and email addresses, plus sensitivity levels and data risk levels. Data minimization requires not collecting data that is not strictly necessary.

Regulated data categories group values by how directly they identify a person:

Quasi-identifiers are the most missed risk because each field looks harmless alone but becomes identifying when Cloud Logging, BigQuery, or a SIEM joins logs by time, user, or resource. High-risk sources include resource metadata captured by audit logs, observability metadata such as metric labels and dashboard content, request and integration fields logged by platforms, build and AI configuration persisted into logs, and Identity Platform attributes outside the core service boundary.

Classification schemas turn findings into a consistent inventory through continuous discovery at the organization, folder, or project level. Discovery generates data profiles with sensitivity and risk metrics for BigQuery, Cloud Storage, and Vertex AI datasets, and profiles can flow to Security Command Center, Google SecOps, and Knowledge Catalog. A practical workflow follows this order:

1. Enable discovery: Configure Sensitive Data Protection discovery so new projects, tables, and buckets are classified automatically.
2. Review profiles by infoType, risk, and location: Locate where direct and quasi-identifiers concentrate and whether sensitive data is expected and protected, unexpected, or needs investigation.
3. Label and route based on findings: Apply sensitivity labels, publish profiles for monitoring, and write job outputs only to storage inside the secure environment.

When discovery finds data that should not be broadly accessible, teams create a de-identified copy that masks or tokenizes sensitive columns so analysts can work in BigQuery or Cloud Storage without seeing raw identifiers.

3.3Assess Compliance and Security Implications of Log Data Handling

Compliance and security implications of log handling are the legal, residency, retention, and access risks created when logs capture PII and PHI. Cloud Logging stores, indexes, and searches data in regional buckets, and that storage choice, retention rule, encryption control, and access grant together determine whether handling meets frameworks such as GDPR and HIPAA. A compliant strategy minimizes what is logged, regionalizes where it is stored, limits how long it is kept, encrypts it with required key control, and restricts who can read it.

Data residency means the bucket infrastructure that stores, indexes, and searches logs lives in a specific geographic location. Cloud Logging buckets are regional resources, so organizations configure a default resource location for new _Default and _Required buckets and create user-defined buckets to centralize by region. The same principle extends to destinations: Cloud Storage stores data only within the specified region, Pub/Sub restricts message storage with message storage policies, and Assured Workloads establishes data boundaries for regulated workloads. Traffic flows from Google Cloud services to the regional bucket and then through sinks to export destinations.

Retention policy defines how long every log in a bucket is kept before deletion. Cloud Logging allows custom retention between 1 day and 3650 days, applying to all logs in the bucket regardless of type. By default, Admin Activity and System Event audit logs are retained for 400 days while Data Access audit logs are retained for 30 days, after which logs must be moved to Cloud Storage or another database product. Organizations apply minimization by using synthetic or anonymized data where possible and by using Cloud Storage lifecycle controls and Object Versioning with retention locks.

Access control is layered, where IAM provides the base and bucket mechanisms add granularity:

Users with the Logs Viewer role can access Admin Activity logs, while Data Access logs require the Private Logs Viewer role, with separation of duties, least privilege, IAM Conditions, principal access boundary policies, and just-in-time elevation through Privileged Access Manager further limiting privilege. Protective controls combine default encryption at rest with customer-managed encryption keys (CMEKs) in Cloud Key Management Service (Cloud KMS) when organizations must control keys, plus VPC Service Controls perimeters with deny-by-default firewall rules to prevent exfiltration. Under HIPAA practices, the organization enters a Business Associate Agreement (BAA), avoids pre-GA services with PHI, and never places PHI in metadata because audit logs capture metadata but never contents.

Using Gemini Cloud Assist (opens in a new tab) for AI-powered log analysis means using natural language chat and automated investigations to interpret logs, metrics, and configurations. Gemini Cloud Assist is an AI-powered collaborator that analyzes operational data to speed diagnosis of complex cloud problems. Interactive chat in the Cloud Assist panel answers questions using the current console page, project ID, and session memory, while Investigations performs deeper automated analysis inside workflows such as Logs Explorer. All AI output must be validated against raw logs, metrics, and configuration because Gemini can produce plausible but incorrect responses.

4.1Interpret AI-Generated Insights and Implement Recommended Actions

Gemini Cloud Assist Investigations produce structured results that separate observed evidence from recommended action. When an investigation starts from an error or resource, Gemini ingests logs, configurations, and metrics from that resource, explores multiple hypotheses in parallel across multi-tier topologies, and returns ranked observations with probable root causes. This parallel exploration matters because a symptom in one tier is often triggered by another tier.

The Investigation Overview pane organizes results into three parts:

Findings describe what the data shows, while Hypotheses prescribe what to do next. In some analyses no significant change is detected and Hypotheses contains no recommendation. For databases, an investigation compares baseline data for the selected time range against five signals: client latencies, server latencies, CPU utilization, disk utilization, and request count. The same pattern applies to GKE, Cloud Run, and Config Sync, where Gemini translates messages such as panic: runtime error: invalid memory address or nil pointer dereference, KNV2009: the server could not find the requested resource, or HTTP 429 The request was aborted because there was no available instance into plain language, common causes, and checks.

Implementation turns validated Findings and Hypotheses into operational changes across incident response, configuration, code, and monitoring:

1. Validate the insight: Corroborate cited log entries, metric spikes, and configuration values in Logs Explorer and dashboards before acting.
2. Contain the incident: Apply immediate remediation for the ranked root cause, such as fixing role-based access control (RBAC) permissions or adjusting max instance limits.
3. Correct code or configuration: Apply the suggested fix through the normal deployment path, including nomos vet and nomos hydrate validation where applicable.
4. Harden preventive monitoring: Narrow alerts and dashboards to the signals that proved diagnostic and allow a new baseline to form.
5. Escalate with context only if unresolved: Transfer validated Issue, Findings, and attempted steps to a Google Cloud support case rather than raw chat text.

As of April 10, 2026, creating, running, and editing investigations requires a Premium Support contract, although earlier results remain visible. Cost totals use contract prices before committed-use discounts, and application totals include only fully used resources.

4.2Formulate and Refine Prompts for Log Analysis Queries

Formulating prompts for log analysis queries means writing precise natural language requests that tell Gemini Cloud Assist what signals to analyze and what outcome to produce. A precise prompt names the resource, pastes the exact error text, and states the goal, such as explaining an error, correlating events, or tracking degradation. Vague prompts return general guidance, while scoped prompts direct the model to interpret specific entries, suggest metrics, and propose causes and next steps.

How prompt and page context shapes analysis is shown by GKE troubleshooting. Gemini combines prompt text with automatic console context, so a prompt written on a resource page inherits project, resource, and visible log details without retyping. The context signals include:

• Project ID and organization ID for scoping to the correct environment
• Page context awareness, including the current console page URL and visible text
• Session memory that stores conversation history across turns
• Current resource page, because navigating to the affected service, cluster, node, or database lets Gemini include it in reasoning

Opening the prompt from the affected resource page is therefore a dependency for accurate analysis. Prompts that identify error patterns paste the full code and message, for example asking what a GKE panic error means or analyzing Config Sync KNV2009 for missing permissions, oversized objects, incorrect paths, or inventory conflicts. For Cloud Run, a prompt without an error string returns general container guidance, while pasting HTTP 429 directs analysis toward instance limits, traffic spikes, slow startup, and long processing.

Prompts that correlate events and detect trends connect latency, crashes, node status, and errors across services:

Refining prompts narrows scope after the first answer by adding identifiers, time ranges, and explicit output requests. When chat alone is insufficient, escalation moves to Investigations, which ingests logs, metrics, and configurations and explores hypotheses in parallel. From chat, escalation follows an ordered flow: request investigation, click Create investigation when offered, refine fields such as resources and time range, then run and review observations and hypotheses for transfer to a support case.

4.3Configure and Integrate Gemini Cloud Assist with Logging Sources

Gemini Cloud Assist integration with logging sources connects the AI ecosystem directly to operational data without a separate log pipeline. Integration does not require a separate pipeline because Gemini reads context from the active project, the console page in view, and workflows such as Logs Explorer. Once setup and Identity and Access Management (IAM) permissions are complete, Gemini can ingest logs, metrics, and configurations to detect patterns and recommend steps. Setup must first be completed for the user account and project, and propagation can take a few minutes before troubleshooting features appear.

Integration points are the console surfaces where Gemini can see logs and act on them. The two primary modes differ in depth and output:

Investigations are integrated into Logs Explorer, Bigtable System insights, Cloud SQL Query insights, and the Cloud Run Source tab, with additional surfaces including Database Center, Cloud Hub, mobile app, command-line, and third-party integrations such as Slack and ServiceNow. An investigation from an error can be transferred to a support case when a support package is available, and Cloud Run source deployments can receive code fix suggestions.

IAM permissions control whether Gemini can read the signals needed for analysis. Access is granted with predefined roles on the workload project:

• View monitoring dashboards with Monitoring Viewer
• Read Bigtable data with Bigtable Reader
• View database performance with Database Insights Viewer
• Use investigations with Gemini Cloud Assist Investigation Owner

These roles provide permissions such as databaseinsights.performanceIssues.detect and databaseinsights.performanceIssues.investigate. A Bigtable performance investigation follows this sequence: open the instance list and click the instance name, select System insights, click Explore Investigations, select the cluster and time filter, click Investigate and wait while Gemini compares baseline against client latencies, server latencies, CPU, disk, and request count, then review the Issue, Findings, and Hypotheses. For Cloud SQL troubleshooting (opens in a new tab), best results require waiting 24 hours after enabling AI assistance so a baseline can form.

Key Facts

• Logging query language queries cannot exceed 20,000 characters, require capitalized AND, OR, and NOT, and treat field names as case-insensitive while regular expressions remain case sensitive.
• Logs Explorer correlation requires the same trace value across entries, a different logName for each entry, and a parent timestamp no later than any child timestamp.
• Every log sink has a writer identity that must be granted write permission on the destination, and an aggregated sink at the organization or folder level routes logs from all child projects to one central destination.
• Custom retention in Cloud Logging applies to the entire log bucket for 1 to 3650 days, bucket location is fixed to global, us, or eu at creation, and Admin Activity audit logs are always written and cannot be excluded.
• Log views hide entire LogEntry objects while field-level access controls hide individual fields, but Observability Analytics cannot query buckets with field-level access controls.