Before diving into features, let us understand what a log is and why a managed logging service matters.

What is a log?

A log is a time-ordered record of something that happened. A web server writes a line every time a page is requested. A database writes a line when a query is slow. A security system writes a line when someone signs in. Each line is called a log entry, and a collection of related entries is called a log. Logs answer the questions “what happened?”, “when?” and “to what?”.

The one-sentence definition

Cloud Logging is Google Cloud’s fully managed service for ingesting, storing, searching, analyzing and alerting on log data from Google Cloud services, your own applications, virtual machines, containers and even other clouds or on-premises systems. It can handle very large volumes of logs without you managing any servers or storage.

The problem it solves

Without central logging, every machine keeps its own files. When something breaks, an engineer must connect to servers one by one, hunt through files and hope the machine still exists. Containers vanish within minutes, taking their logs with them. Central logging collects everything into one place before it can disappear, so you can search across your whole system at once.

Logs are among the most valuable and the most neglected assets in a system.

A handful of terms appear everywhere in Cloud Logging. Learn them once and the rest feels familiar.

Anatomy of a log entry

flowchart LR
  A[Applications and Services] --> B[Cloud Logging API]
  B --> C[Log Router]
  C --> D[Log Buckets]
  C --> E[Sinks to Other Destinations]
  D --> F[Logs Explorer and Log Analytics]
  D --> G[Log-Based Metrics and Alerts]
        

Not all logs are the same. Knowing the main categories helps you decide what to keep, what to search and what to pay for.

The three families of audit logs

Logs reach Cloud Logging in several ways, depending on where your workload runs.

flowchart TD
  A[Cloud Run and Functions: stdout and stderr] --> L[Cloud Logging]
  B[GKE Containers and Cluster Components] --> L
  C[Virtual Machines with Ops Agent] --> L
  D[Google Cloud Platform Logs and Audit Logs] --> L
  E[Applications Using Client Libraries] --> L
  F[On-Premises and Other Clouds] --> L
        

Structured versus plain-text logging

A plain-text log line is easy to write but hard to search reliably, because you must match wording. A structured log is a small set of named fields, such as the user identifier, the request path, the status code and the duration. Cloud Logging can store these fields separately, so you can filter and count by them. Structured logging is one of the highest-value habits you can adopt.

The Log Router is the traffic controller at the heart of Cloud Logging. Understanding it is the key to controlling cost and compliance.

How routing works

Every log entry that arrives in a project passes through the Log Router. The router compares the entry against a list of sinks. Each sink has a filter that says which entries it wants and a destination that says where to send them. An entry can match several sinks and be sent to several places at once. Exclusion filters on a sink can drop unwanted entries so they are not stored or billed in that destination.

flowchart TD
  IN[Incoming Log Entry] --> R[Log Router]
  R --> S1[Required Sink: Required Bucket]
  R --> S2[Default Sink: Default Bucket with Exclusions]
  R --> S3[Custom Sink: User-Defined Bucket]
  R --> S4[Sink: BigQuery for Analysis]
  R --> S5[Sink: Cloud Storage for Archive]
  R --> S6[Sink: Pub/Sub for External Tools]
        

Default routing

Each project starts with two built-in sinks. The Required sink sends certain audit logs, such as admin activity and system event logs, to the Required bucket. You cannot change or disable it. The Default sink sends nearly everything else to the Default bucket. You can edit the Default sink, for example to exclude noisy logs, and you can add your own sinks.

Sink destinations

Aggregated sinks

For organizations with many projects, an aggregated sink can be created at a folder or organization level. It collects matching logs from all projects beneath it, which is the basis for central audit log collection and enterprise-wide security monitoring.

Where logs are stored, for how long, and who can see them, are decisions with both cost and security consequences.

Log buckets

A log bucket is a storage container inside Cloud Logging that holds log entries. Each project has the Required bucket, which holds certain audit logs for a fixed long period at no charge, and the Default bucket, which holds most other logs for a shorter default period. You can create your own buckets, each with its own location and retention period, to separate logs by purpose, team, sensitivity or compliance need.

Retention and location

Retention is how long entries are kept before being deleted automatically. Storing logs for longer increases cost, so set retention to match real needs. Each bucket also has a location, either a specific region or a global setting. Choose a location that meets data residency requirements, as it cannot be changed after creation. Buckets can also be protected with customer-managed encryption keys and locked so that retention cannot be shortened.

Log views: controlling who sees what

A log view is a saved filter on a bucket that limits which entries a person can see. Instead of giving a team access to a whole bucket full of everyone’s logs, you give them access to a view that shows only their service’s entries. This is a clean way to share a central logging bucket across many teams while keeping each team’s data private.

flowchart TD
  B[Central Log Bucket: All Production Logs] --> V1[View: Payments Team Entries]
  B --> V2[View: Web Team Entries]
  B --> V3[View: Security Team All Entries]
  V1 --> U1[Payments Engineers]
  V2 --> U2[Web Engineers]
  V3 --> U3[Security Analysts]
        

Collecting logs is useless if you cannot find the right line quickly. Logs Explorer is your search window.

What Logs Explorer offers

Logs Explorer is the main console tool for viewing logs. It shows a histogram of entries over time, a list of matching entries and a field panel to filter by resource, severity and other fields. You can build queries by clicking fields, by typing text, or by writing queries in the Logging query language. It also supports live tailing, which streams new entries as they arrive, and sharing links to a specific query for teammates.

The Logging query language

The query language is a simple way to describe which entries you want. You combine conditions about fields, such as the resource type, the severity, a field inside a structured payload or a time range, with the words AND, OR and NOT. It also supports comparisons and text matches. Learning to write precise queries is the difference between finding the answer in seconds and scrolling for an hour.

Sometimes searching is not enough. You want to count, group, join and measure. Log Analytics brings SQL to logs.

What Log Analytics is

Log Analytics lets you run SQL queries over your logs directly inside Cloud Logging. You upgrade a log bucket to use Log Analytics, and its entries become queryable like a table. You can group by fields, calculate averages and percentiles, find the top error messages, and chart results in the console. You can also create a linked dataset so BigQuery can query the same logs without copying them, which allows joining logs with business data.

Typical analytics questions

Logs describe individual events. Metrics describe trends. Log-based metrics turn one into the other.

What a log-based metric is

A log-based metric is a number that Cloud Logging calculates from log entries matching a filter you choose. A counter metric counts how many matching entries occurred, such as the number of failed payments per minute. A distribution metric records values extracted from entries, such as request durations, so you can chart percentiles. Labels extracted from the entries, such as the service name or error type, let you slice the metric by category.

Alerting from logs

Cloud Monitoring can alert on log-based metrics, notifying you when an error rate crosses a threshold. For rare but important messages, log-based alerts can notify you directly when a matching entry appears, without building a metric first, for example when a critical security event is logged. Notifications can go to email, chat tools, incident management systems and webhooks.

flowchart LR
  L[Log Entries] --> F[Filter for Specific Pattern]
  F --> M[Log-Based Metric]
  M --> C[Chart and Dashboard]
  M --> A[Alert Policy]
  A --> N[Notification to On-Call Team]
  F --> LA[Log-Based Alert for Rare Events]
  LA --> N
        

A single user request may pass through many services. Correlation ties all their log lines together.

Trace and span identifiers

When your request flows through services, each service can record a trace identifier in its log entries. Cloud Logging uses the trace and span fields to link entries to traces in Cloud Trace. With correct fields, you can click from a slow request in a trace to all log lines produced during that request, across every service. Many Google Cloud services add these fields automatically, and your own code can add them using client libraries or standard formats.

Error Reporting

Error Reporting watches logs for exceptions and stack traces, groups similar errors together, counts how often they occur and notifies you of new ones. Instead of reading thousands of repeated error lines, you see a short list of distinct problems and their frequency.

Audit logs answer the most important security question: who did what, where and when?

What an audit log entry tells you

Audit log entries record the identity that made the call, the method that was called, the resource affected, the time, the source address and whether the request succeeded or was denied. This lets you reconstruct events during an investigation, prove compliance and detect unusual behavior such as a new administrator being added at midnight.

Logs often contain sensitive details. Protecting them is as important as protecting the systems that produce them.

Controlling access with IAM

Protecting sensitive content

Applications sometimes accidentally write passwords, tokens, card numbers or personal data into logs. Because logs are widely read and copied, this is a serious risk. Avoid logging sensitive values in the first place, mask or hash them before writing, and use tools that detect and redact sensitive data where available. Use log views and separate buckets to limit who can read the most sensitive logs.

Logging costs are driven mostly by volume. Understanding the meters lets you keep valuable logs and drop the waste.

Ways to reduce cost without losing value

Many organizations send logs onward to security, analytics and archival systems.

flowchart TD
  L[Cloud Logging Log Router] --> A[Log Bucket: Search and Alerts, 30 to 90 days]
  L --> B[BigQuery: Analysis, 1 year]
  L --> C[Cloud Storage: Archive, 7 years]
  L --> D[Pub/Sub: Security Platform]
        

When logs go missing, the problem is rarely mysterious. A short checklist solves most cases.

Several approaches exist for managing logs. Knowing the differences guides your choice.

flowchart TD
  Q1{Running mostly on Google Cloud?} -->|Yes| A1[Start with Cloud Logging]
  Q1 -->|No| Q2{One tool needed across many clouds?}
  Q2 -->|Yes| A2[Consider a multi-cloud platform and forward logs]
  Q2 -->|No| A1
  A1 --> Q3{Need long-term analytics or security detection?}
  Q3 -->|Yes| A3[Add sinks to BigQuery, Storage or Pub/Sub]
  Q3 -->|No| A4[Use buckets, Explorer and alerts]
        

Patterns capture what experienced teams repeatedly find works; anti-patterns capture what goes wrong.

Helpful patterns

Anti-patterns to avoid

An honest view of strengths, limits and where teams actually apply Cloud Logging.

Real-world examples

A short checklist to carry into every logging project.

The service is enabled by default in Google Cloud projects, and many services send logs automatically. You may need an agent for virtual machines and settings for audit logs, retention and routing.

It depends on the bucket. The Required bucket keeps certain audit logs for a fixed long period, the Default bucket keeps logs for a shorter default period that you can change, and your own buckets can have custom retention.

A bucket is where logs are stored inside Cloud Logging. A sink is a routing rule that decides which entries go to which destination, which can be a bucket or an outside service.

Admin activity and system event audit logs are generally not charged. Data access audit logs are disabled by default for most services and are billed like other logs when you enable them. Always confirm current pricing.

Structured fields let you filter, count and chart by exact values, build reliable metrics and run SQL analysis, which is far harder with free-form text.

Find the highest-volume sources, exclude or sample low-value entries, lower production log levels, shorten retention for hot storage and archive older logs cheaply.

Yes. Log Analytics lets you run SQL over upgraded log buckets, and you can link a BigQuery dataset to query the same logs there.

Create a log-based metric and alert policy for trends and thresholds, or a log-based alert for rare events that should notify you on the first occurrence.

Yes. Agents and collectors can forward logs from on-premises servers and other clouds, or you can write entries through the API.

Use log views on a shared bucket, or separate buckets, and grant each team access to its view with least-privilege roles.

Excluded entries are not stored in that destination and cannot be recovered later, so exclude carefully and consider sampling instead of dropping everything.

Include a trace or request identifier in every log entry. Then filter by that identifier, or open the trace and jump to its related logs.

Cloud Logging is Google Cloud’s managed flight recorder: it collects log entries from platform services, audit systems, containers, virtual machines and your own code, routes them through the Log Router into buckets and other destinations, and lets you search, analyze with SQL, turn patterns into metrics and alert on important events. Its real power appears when logs are structured, correlated with traces, retained according to need and protected by careful access control. Cost and noise are managed by reviewing volume, excluding or sampling low-value entries, tiering retention and enabling expensive categories such as data access audit logs only where they matter. Treat logging as a designed system, not an afterthought, and review current documentation for limits, features and pricing.