First, what a log is, then what the service does with it.

What is a log?

A log is a record of something that happened, written by a program or system. Each separate record is called a log entry. A typical log entry says what happened, when it happened, how serious it was, and where it came from. For example: “At 10:42:05, the payment service failed to charge a card because the bank did not answer.”

Why logs matter

• Troubleshooting: find out why something broke.
• Monitoring: spot patterns, such as more errors than usual.
• Security: see who did what, and when.
• Auditing and compliance: prove to regulators that rules were followed.
• Business insight: learn how people use your product.

What is Cloud Logging?

Cloud Logging is a fully managed service that ingests (receives), stores, searches, analyzes, and routes log data from Google Cloud, other clouds, and your own servers. You do not build log servers, manage disks, or index data yourself. It scales from a few messages to many millions per second.

It is part of Google Cloud’s operations suite, together with Cloud Monitoring (charts and alerts), Error Reporting, and Cloud Trace. Those tools work best when used together.

The pain it removes.

Logs scattered everywhere

In the old days, each server kept its own log files on its own disk. To find an error, an engineer had to log in to each machine one by one and search through huge text files. If a server crashed or was deleted, its logs vanished with it.

Modern systems are many and temporary

Today, one application may run on hundreds of containers that start and stop all the time. A request may pass through ten services. If the logs live only on those short-lived machines, they disappear when the machines do, and tracing a single request across ten places by hand is nearly impossible.

Running your own logging system is heavy work

Companies sometimes build their own logging stack with open-source tools. This needs servers, storage, scaling, upgrades, and security, and the system itself can break at the worst moment. A managed service removes this burden.

The vocabulary of Cloud Logging.

Log entry

A log entry is one record. It holds a time stamp, a severity, the resource that produced it, a log name, and the actual content, called the payload. It may also have labels and links to a trace.

Severity

Severity shows how serious a message is. Common levels, from least to most serious, are: Debug, Info, Notice, Warning, Error, Critical, Alert, and Emergency. Filtering by severity is the fastest way to focus on problems.

Payload: text or structured

A text payload is plain words. A structured payload, usually in JSON format, holds named fields such as user, order number, and duration. Structured logs are far easier to search and analyze, because you can ask “show me entries where duration is more than two seconds”.

Monitored resource

A monitored resource describes where the log came from, such as a virtual machine, a Cloud Run service, a GKE container, or a load balancer. It includes details like project, region, and name, so you can filter by source.

Log name and log type

Logs are grouped by log name, such as “stdout”, “stderr”, or “cloudaudit activity”. Think of each name as a separate notebook in the library.

Log bucket

A log bucket is a storage container for log entries inside Cloud Logging. Each bucket has its own retention time and location. This is different from a Cloud Storage bucket.

Log sink and Log Router

A sink is a rule that copies matching log entries to a destination. The Log Router is the part of the service that receives every entry and applies all sinks and filters, deciding where each entry goes.

Log-based metric

A log-based metric turns logs into numbers. For example, count how many times “payment failed” appears per minute, then chart it or alert on it.

How logs travel from a program to your screen.

The main pieces

• Log sources: Google Cloud services, your applications, virtual machines, containers, other clouds, and on-premises systems.
• Agents and libraries: the Ops Agent on VMs, built-in collection in GKE and Cloud Run, and client libraries or the API for your code.
• The Logging API: the front door that accepts incoming entries.
• The Log Router: applies sinks, filters, and exclusions to each entry.
• Log buckets: the default storage inside Cloud Logging, with search and analysis tools.
• Sink destinations: other log buckets, Cloud Storage, BigQuery, Pub/Sub, or other projects.
• Interfaces: Logs Explorer, Log Analytics, the command line, and APIs.
• Companion tools: Cloud Monitoring, Error Reporting, and Cloud Trace.

flowchart LR
  SRC["Sources: Google Cloud services, VMs, GKE, Cloud Run, apps"] --> API["Cloud Logging API"]
  API --> ROUTER["Log Router: sinks and filters"]
  ROUTER --> REQ["_Required bucket: audit logs"]
  ROUTER --> DEF["_Default bucket: other logs"]
  ROUTER --> CUS["Custom log buckets"]
  ROUTER -- "Sink" --> GCS["Cloud Storage: long-term archive"]
  ROUTER -- "Sink" --> BQ["BigQuery: analytics"]
  ROUTER -- "Sink" --> PS["Pub/Sub: streaming to other tools"]
  DEF --> UI["Logs Explorer and Log Analytics"]
  DEF --> MET["Log-based metrics and alerts"]
    

Regional and global considerations

Log buckets have a location. Choose a location that meets your data residency rules, such as keeping data inside a certain country or region. Once chosen for a bucket, the location generally cannot be changed.

Not all logs are the same. Know the main families.

Audit logs in detail

Audit logs deserve special attention because they answer “who did what”. There are four kinds:

• Admin Activity logs: record changes to configuration or metadata, such as creating or deleting a VM. They are always on and free to keep for the required period.
• Data Access logs: record who read or wrote user data. Most are off by default, because they can be large, and you turn them on where needed.
• System Event logs: record actions taken by Google systems, such as moving a VM during maintenance.
• Policy Denied logs: record when a request was blocked by a security policy.

Different sources use different paths into Cloud Logging.

Automatic collection from Google Cloud services

Many services send logs to Cloud Logging by themselves with no setup. Cloud Run captures what your container prints. Cloud Functions captures function output. App Engine, load balancers, and many managed databases and tools do the same, and audit logs are produced automatically.

Google Kubernetes Engine

GKE collects the standard output and standard error of your containers, plus system component logs, and sends them to Cloud Logging. You can control which logs are collected through cluster settings.

Virtual machines and the Ops Agent

On Compute Engine VMs and other servers, install the Ops Agent. It is a lightweight program that reads log files and system metrics and sends them to Cloud Logging and Cloud Monitoring. You can add configuration to read your own application log files.

From your own code

Your code can write logs in two common ways. First, simply print to standard output in a structured JSON format, which many Google Cloud runtimes pick up automatically. Second, use the Cloud Logging client libraries or API to write entries directly, with fine control over severity, labels, and trace links.

From other clouds and on-premises

Agents and open standards, such as OpenTelemetry collectors, can forward logs from other environments into Cloud Logging, giving you one view of a hybrid system.

flowchart TD
  CR["Cloud Run and Functions: stdout automatically"] --> CL["Cloud Logging"]
  GKE["GKE containers: stdout and stderr"] --> CL
  VM["VMs with Ops Agent: log files"] --> CL
  APP["Your code using client libraries"] --> CL
  OTH["Other clouds and on-premises: agents and collectors"] --> CL
  SVC["Google Cloud services: platform and audit logs"] --> CL
    

Where logs are kept, copied, and dropped.

Default buckets

Every project starts with two log buckets:

• _Required: holds audit logs that must be kept, such as Admin Activity and System Event logs. It has a fixed retention that cannot be changed, and storing in it is free.
• _Default: holds most other logs. Its retention is shorter by default but you can change it.

Custom buckets

You can create your own buckets for special needs, such as a bucket for security logs kept for several years, or a bucket in a certain region to meet data rules. Sinks send selected logs to these buckets.

Sinks and destinations

A sink has three parts: a filter (which logs), a destination (where to send), and optional exclusions. Common destinations are:

• Another log bucket: for different retention or location.
• Cloud Storage: for cheap long-term archives.
• BigQuery: for SQL analysis of large volumes.
• Pub/Sub: to stream logs to other tools, such as a security information system or a third-party monitoring platform.
• Another project: to centralize logs from many projects.

Aggregated sinks

At the folder or organization level you can create an aggregated sink, which collects matching logs from every project beneath it. This is the usual way to gather audit logs from a whole company into one secure place.

Exclusion filters

An exclusion filter drops matching logs before they are stored, so you do not pay for noise. For example, exclude debug messages from a chatty test service, or exclude a percentage of routine health check logs. Excluded logs are gone for good from the bucket, so use exclusions with care.

flowchart TD
  IN["Incoming log entries"] --> R["Log Router"]
  R --> E{"Matches an exclusion filter?"}
  E -- "Yes" --> D["Dropped from that bucket"]
  E -- "No" --> B["Stored in _Default or a custom bucket"]
  R --> S1["Sink 1: security logs to long-retention bucket"]
  R --> S2["Sink 2: audit logs to Cloud Storage archive"]
  R --> S3["Sink 3: all logs to BigQuery for analysis"]
  R --> S4["Sink 4: errors to Pub/Sub for alert tools"]
    

Finding the needle in the haystack.

Logs Explorer

Logs Explorer is the main web page for reading and searching logs. It shows a histogram of how many entries arrived over time, a list of entries, and menus to filter by resource, severity, and log name. You can expand any entry to see all its fields.

The query language

Logs Explorer uses a simple query language. You describe what you want using field names and values, joined by words such as AND and OR. In plain words, examples of what queries can express are:

• Show entries from a certain Cloud Run service with severity Error or higher.
• Show entries where the text contains the words “payment failed”.
• Show entries in a time window around an incident.
• Show entries where a structured field such as “duration” is greater than two seconds.
• Show all entries that share one request or trace identifier.

Follow one request across services

Many Google Cloud services add a trace identifier to logs. By searching for that identifier, you can see every log entry related to one user request, even if it crossed many services. This is a major time saver during troubleshooting.

Log fields and saved queries

The field panel shows which values appear most often, helping you narrow down. You can save useful queries and share them with your team, so everyone searches the same way.

Live tailing

With live tailing, you watch new entries stream in nearly in real time, which is helpful while testing a deployment.

Turning raw messages into insight and action.

Log Analytics

Log Analytics lets you run SQL queries on your logs. After you upgrade a log bucket to use it, you can group, count, join, and chart log data like a table. Linked datasets can let BigQuery read the same logs without copying them. This is perfect for questions such as “which customers saw the most errors last week?” or “what is the 95th percentile response time per endpoint?”.

Log-based metrics

A log-based metric converts log entries into numbers that Cloud Monitoring can chart and alert on. There are two main kinds:

• Counter metrics: count how many log entries match a filter, such as the number of failed logins per minute.
• Distribution metrics: collect a number from each entry, such as request duration, and show how values are spread.

Alerts from logs

You can create log-based alerts that notify you when a certain kind of log entry appears, such as a critical error or a suspicious administrator action. You can also alert on log-based metrics, such as “more than fifty failed payments in five minutes”.

Error Reporting

Error Reporting reads error logs and groups similar errors together, so you see “this error happened 4,000 times, first seen yesterday” instead of thousands of separate lines. It helps teams prioritize bug fixes.

flowchart LR
  L["Log entries"] --> M["Log-based metric: count failed payments"]
  M --> MON["Cloud Monitoring chart"]
  MON --> AL["Alert policy"]
  AL --> N["Notify on-call via email, chat, or pager"]
  L --> ER["Error Reporting: grouped errors"]
  L --> LA["Log Analytics: SQL insights"]
    

How long to keep logs, and where.

Retention

Retention is how long logs are kept before being deleted automatically. Each log bucket has its own retention period. The required audit bucket has a fixed, longer retention. The default bucket keeps logs for a shorter period unless you change it, and you can extend retention for specific buckets up to a long maximum. Check the current documentation for exact values, because they can change.

Choose retention by purpose

• Debug and application logs: a few days to a few weeks is often enough.
• Security and audit logs: months to years, depending on rules for your industry.
• Financial and compliance logs: follow legal requirements, which may be many years.

Cheap long-term storage

For very long retention, send a copy to Cloud Storage with lifecycle rules that move old logs to cheaper storage classes. Logs in Cloud Storage can be kept at low cost for years, and you can analyze them later by loading them into BigQuery when needed.

Data residency and encryption

Choose bucket locations to keep logs inside required regions. Logs are encrypted at rest by default, and you can use customer-managed encryption keys for stricter control.

Immutability and legal hold

For strict compliance, you can send audit logs to a Cloud Storage bucket with a retention lock, which prevents anyone from deleting or shortening the retention period until it expires. This helps show regulators that records were not tampered with.

Logs can contain secrets. Protect them.

IAM roles

IAM roles decide who can view, write, or manage logs. Typical roles include one for viewing logs, one for writing logs from applications, one for viewing sensitive private logs such as Data Access audit logs, and one for administering logging configuration. Give people only what they need.

Protect sensitive logs

• Private logs such as Data Access logs need a stronger role to view.
• Log views allow you to show only part of a bucket to certain users, such as only one team’s logs.
• Separate security buckets in a dedicated project, with access limited to the security team.

Do not log secrets

Developers sometimes write passwords, tokens, card numbers, or personal details into logs by accident. Logs are widely readable, copied to many places, and kept for a long time, so this is dangerous. Use code reviews, log scrubbing, and data loss prevention scanning to find and remove sensitive data. Mask personal data before logging it.

Tamper protection and monitoring

Audit who changes logging settings, because an attacker may try to turn off logging or delete logs to hide their tracks. Use alerts on changes to sinks, exclusions, and retention. Send security-critical logs to a separate project that normal administrators cannot change.

Service accounts

Applications write logs using service accounts. Give them only the log-writing permission, not broad access to read all logs.

How the service behaves under heavy load.

Scale

Cloud Logging is built to ingest very large volumes. Even so, there are quotas on the rate of write requests, entry sizes, and query rates. Plan for them in very high-volume systems, and request increases when needed.

Write efficiently

• Batch writes when using client libraries, so you send fewer requests.
• Write asynchronously so logging never slows your main program.
• Keep entries reasonably small. Huge entries are costly and may be truncated.
• Avoid logging in tight loops. A million near-identical lines per second helps nobody.
• Use sampling for very repetitive events.

Reliability

Logs are stored durably by Google. Agents and libraries buffer entries and retry if there is a brief network problem, but buffers are limited. A long outage or a crashing program may lose some entries. For critical records, such as audit trails, rely on the platform’s own audit logs rather than only application logs.

Query speed

Narrow your time window and add resource and severity filters so searches are fast. Searching “everything for the last month” is slow and expensive, while “errors from one service in the last hour” is quick.

Logs can quietly become one of your biggest bills. Learn to manage them.

What drives cost

• Ingestion: the main cost, charged per amount of log data stored in log buckets. A monthly free allowance per project exists, but check the current price page for details.
• Retention beyond the default: keeping logs longer than the included period carries a storage charge.
• Log Analytics and queries: some analysis features may have separate pricing.
• Sink destinations: BigQuery storage and queries, Cloud Storage storage, Pub/Sub throughput.
• Network egress: logs sent out of Google Cloud may cost extra.

The required audit bucket is generally free to store for its required period, while data access logs and verbose application logs often cause the largest bills.

Ways to reduce cost

• Find the top log producers using Logs Explorer or the logs storage page, and fix the noisiest first.
• Use exclusion filters for debug logs, health checks, and repetitive messages.
• Sample very frequent, low-value logs, for example keep one in ten.
• Lower log levels in production, for example avoid Debug unless investigating.
• Route only what you need to expensive destinations such as BigQuery.
• Archive to Cloud Storage for cheap long retention.
• Set budgets and alerts on logging volume and cost.
• Review Data Access audit logs and turn them on only for sensitive services.

flowchart TD
  A["Review ingestion by service"] --> B{"Is one service very noisy?"}
  B -- "Yes" --> C["Reduce log level or fix the code"]
  B -- "No" --> D{"Low-value repetitive logs?"}
  C --> D
  D -- "Yes" --> E["Add exclusion filter or sampling"]
  D -- "No" --> F{"Need long retention?"}
  E --> F
  F -- "Yes" --> G["Sink to Cloud Storage archive"]
  F -- "No" --> H["Keep short retention in default bucket"]
    

An honest report card.

Compared with neighbors

Habits that work, and traps to avoid.

Good patterns

Anti-patterns

Your checklist, the usual stumbles, and where logging shines.

Best practices

• Decide what to log before writing code: key events, errors, and decisions.
• Use structured logs with consistent field names.
• Include request and trace identifiers in every entry.
• Use severity levels correctly.
• Never log secrets or unnecessary personal data.
• Create separate buckets for different retention and access needs.
• Collect audit logs centrally with aggregated sinks, and protect that project.
• Create log-based metrics and alerts for important events.
• Review volume and cost monthly, and tune exclusions.
• Manage logging settings as code so they are reviewed and repeatable.

Common mistakes

Real-world uses

You started with an airplane’s flight recorder. You now understand that Cloud Logging is the flight recorder for your whole cloud estate: it gathers every system’s diary, files it safely, and lets you search, analyze, and act on it.