Route logs to supported destinations
Stay organized with collections
Save and categorize content based on your preferences.
This document explains how to create and manage log sinks, which route
log entries that originate in a Google Cloud project to supported destinations.
A sink performs a write action and therefore it must
be authorized to write to the destination. When the destination is a log bucket
in the same project as the sink, the sink is automatically
authorized. For all other destinations, the sink must be attached to a
service account that has been granted
the permissions required to write data to the destination.
When a service account is required, Cloud Logging automatically creates and
manages it. However, you might need to modify the permissions granted to
the service account. You don't have to use the service account created by
Logging. You can create and manage a service account
that is used by sinks in multiple projects. For more information, see
Configure log sinks with user-managed service accounts.
Overview
This page describes how to create a sink and how to configure the options
you might see when using the Google Cloud console or the API.
Sinks belong to a given Google Cloud resource: a Google Cloud project,
a billing account, a folder, or an organization. When the resource receives a
log entry, every sink in the resource processes the log entry. When a
log entry matches the filters of the sink, then the log entry is
routed to the sink's destination.
Typically, sinks only route the log entries that originate in a resource.
However, for folders and organizations you can create aggregated sinks,
which route log entries from the folder or organization, and the
resources
it contains. This document doesn't discuss
aggregated sinks. For more information, see
Aggregated sinks overview.
To create and manage sinks, you can use the Google Cloud console,
the Cloud Logging API, and the Google Cloud CLI. We recommend that
you use the Google Cloud console for the following reasons:
You can configure sink destinations as part of the flow to create a sink.
You can preview which log entries match the sink's filters.
Some authorization steps are simplified.
We recommend that you review your log sink configuration when you make any
changes to your log storage. For example, if you delete the destination of a
log sink, then delete the corresponding log sink.
To learn how to view and manage your log sinks, see the
Manage sinks section of this document.
Supported destinations
The destination of a sink can be in a different resource than the sink.
For example, you can use a log sink to route log entries from one project to a
log bucket stored in a different project.
The following destinations are supported:
Google Cloud project
Select this destination when you want the log sinks in the
destination project to reroute your log entries, or when you have created
an intercepting aggregated sink. The log sinks in the project that is the
sink destination can reroute the log entries to any supported destination
except a project.
Log bucket
Select this destination when you want to store your log data in
resources managed by Cloud Logging. Log data stored in log buckets
can be viewed and analyzed using services like the Logs Explorer
and Observability Analytics.
If you want to join your log data with other business data, then you
can store your log data in a log bucket and create a linked
BigQuery dataset. A linked dataset is a read-only dataset
that can be queried like any other BigQuery dataset.
BigQuery dataset
Select this destination when you want to join your log data with
other business data. The dataset you specify must be write-enabled.
Don't set the destination of a sink to be a linked
BigQuery dataset. Linked datasets are read-only.
Cloud Storage bucket
Select this destination when you want long-term storage of your log data.
The Cloud Storage bucket can be in the same project in which log entries
originate, or in a different project. Log entries are stored as JSON files.
Pub/Sub topic
Select this destination when you want to export your log data from
Google Cloud and then use third-party integrations like Splunk or Datadog.
Log entries are formatted into JSON and then routed to
a Pub/Sub topic.
Destination limitations
This section describes destination-specific limitations:
If you route log entries to a log bucket in a different Google Cloud project,
then Error Reporting doesn't analyze those log entries.
For more information, see Error Reporting overview.
If you route log entries to a BigQuery dataset, the
BigQuery dataset must be write-enabled. You can't route
log entries to linked datasets, which are read-only.
New sinks that route log data to Cloud Storage buckets might take
several hours to start routing log entries. These sinks are processed hourly.
The following limitations apply when the destination of a log sink
is a Google Cloud project:
There is a one-hop limit.
Log entries that match the filter of the
_Required log sink
are only routed to the _Required log bucket of the destination project
when they originate in the destination project.
Only aggregated sinks that are in the resource hierarchy of a log entry
process the log entry.
For example, assume the destination of a log sink in project A is
project B. Then the following are true:
Due to the one-hop limit, the log sinks in project B can't reroute
log entries to a Google Cloud project.
The _Required log bucket of project B only stores log entries that
originate in project B. This log bucket doesn't store any log
entries that originate in any other resource, including those
that originate in project A.
If the resource hierarchy of project A and project B differ, then
a log entry that a log sink in project A routes to project B
isn't sent to the aggregated sinks in the resource hierarchy of
project B.
If project A and project B have the same resource hierarchy,
then log entries are sent to the aggregated sinks in that hierarchy.
If a log entry isn't intercepted by an aggregated sink,
then the Log Router sends the log entry to the sinks in project A.
Before you begin
The instructions in this document describe creating and managing sinks at the
Google Cloud project level. You can use the same procedure to create a sink
that routes log entries that originate in an organization, folder, or
billing account.
To get started, do the following:
Enable the Cloud Logging API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role (roles/serviceusage.serviceUsageAdmin), which
contains the serviceusage.services.enable permission. Learn how to grant
roles.
To route log entries to a destination, the destination must exist before
you create the sink. You can create the destination in any
Google Cloud project in any organization.
Before you create a sink, review the limitations that apply for the
sink destination. For more information, see the
Destination limitations section in this document.
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and
APIs, you don't need to set up authentication.
gcloud
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a
Cloud Shell
session starts and displays a command-line prompt. Cloud Shell is a shell environment
with the Google Cloud CLI
already installed and with values already set for
your current project. It can take a few seconds for the session to initialize.
REST
To use the REST API samples on this page in a local development environment, you use the
credentials you provide to the gcloud CLI.
This section describes how to create a sink in a Google Cloud project.
You can create up to 200 sinks per Google Cloud project.
To view the number and volume of log entries that are routed, view the
logging.googleapis.com/exports/ metrics.
You use the Logging query language to create a filter
expression that matches the log entries you want to include. Don't put
sensitive information in sink filters. Sink filters are treated as service data.
When a query contains multiple statements,
you can either specify how those statements are joined or rely on Cloud Logging implicitly
adding the conjunctive restriction, AND, between the statements. For example,
suppose a query or filter dialog contains two statements,
resource.type = "gce_instance" and severity >= "ERROR".
The actual query is resource.type = "gce_instance" AND severity >= "ERROR".
Cloud Logging supports both disjunctive restrictions, OR, and conjunctive
restrictions, AND. When you use OR statements, we recommend that you
group the clauses with parentheses.
If you route log entries to a service that is in another project, then you must
provide the sink with the fully-qualified name for the service. Similarly,
if you route log entries to a different Google Cloud project, then you must
provide the sink with the fully-qualified name of the destination project:
This section describes how to grant Logging the
Identity and Access Management permissions to write log entries to your sink's destination.
For the full list of Logging roles and permissions,
see Access control.
Cloud Logging creates a shared service account for a resource when a
sink is created, unless the required service account already exists.
The service account might exist because the same service account is used for
all sinks in the underlying resource. Resources can be a Google Cloud project,
an organization, a folder, or a billing account.
The writer identity of a sink is the identifier of the service
account associated with that sink. All sinks have a writer identity except for
sinks that write to a log bucket in the same Google Cloud project in which
the log entry originates. For the latter configuration, a service account
isn't required and therefore the sink's writer identity field
is listed as None in the console. The
API and the Google Cloud CLI commands don't report a writer identity.
The following instructions apply to projects, folders, organizations, and
billing accounts:
Console
Make sure that you have Owner access on the
Google Cloud project that contains the destination.
If you don't have Owner access to the destination of the sink,
then ask a project owner to add the writer identity as a principal.
To get the sink's writer identity—an email address—from the
new sink, do the following:
In the Google Cloud console, go to the Log Router page:
If you use the search bar to find this page, then select the result whose subheading is
Logging.
In the toolbar, select the project that contains the sink.
Select more_vertMenu and then select
View sink details. The writer identity appears in the
Sink details panel.
If the value of the writerIdentity field contains an email address,
then proceed to the next step. When the value is None,
you don't need to configure destination permissions for the sink.
Copy the sink's writer identity into your clipboard.
The email address identifies the principal. The prefix, serviceAccount:,
specifies the account type.
Grant the principal specified in the sink's writer identity the permission
to write log data to the destination:
If you use the search bar to find this page, then select the result whose subheading is
IAM & Admin.
In the toolbar, make sure that the selected project is either the
project that stores the destination or is the sink destination.
For example, if the destination is a log bucket, then make sure that
the toolbar displays the project that stores the log bucket.
Click person_addGrant access.
Grant the principal specified in the sink's writer identity
an IAM role based on the destination of the log sink:
For all destinations, grant the
Logs Writer role
(roles/logging.logWriter). Specifically, a principal needs the
logging.logEntries.route permission.
Grant one of the following roles based on the destination:
Pub/Sub topic, including Splunk: Grant the
Pub/Sub Publisher role
(roles/pubsub.publisher).
gcloud
Make sure that you have Owner access on the
Google Cloud project that contains the destination.
If you don't have Owner access to the destination of the sink,
then ask a project owner to add the writer identity as a principal.
Get the service account from the writerIdentity field in your sink:
gcloud logging sinks describe SINK_NAME
Locate the sink whose permissions you want to modify, and if the sink
details contain a line with writerIdentity, then proceed
to the next step. When the details don't include a writerIdentity
field, you don't need to configure destination permissions for
the sink.
The writer identity for the service account looks similar to the
following:
Grant the sink's writer identity the permission
to write log data to the destination by calling the
gcloud projects add-iam-policy-binding command.
Before using the following command, make the following replacements:
PROJECT_ID: The identifier of the project. Specify the project which stores the destination of
the log sink. When the destination is a project, specify that project.
PRINCIPAL: An identifier for the principal that you want to
grant the role to. Principal identifiers usually have the following form:
PRINCIPAL-TYPE:ID.
For example, user:my-user@example.com.
For a full list of the formats that PRINCIPAL can have,
see Principal identifiers.
ROLE: An IAM role. Grant the sink's writer identity an IAM
role based on the destination of the log sink:
For all destinations, grant the
Logs Writer role
(roles/logging.logWriter). Specifically, a principal needs the
logging.logEntries.route permission.
Grant one of the following roles based on the destination:
We recommend that you use the Google Cloud console or the Google Cloud CLI
to grant a role to service account.
Manage sinks
We recommend that you review your log sink configuration when you make any
changes to your log storage. For example, if you delete the destination of a
log sink, then delete the corresponding log sink.
After your sinks are created, you can perform the following actions on them.
Any changes made to a sink might take a few minutes to apply:
View details
Update
Disable
You can't disable the _Required sink.
You can disable the _Default sink to stop it from routing log entries to
the _Default Logging bucket.
If you want to disable the _Default sink for any new
Google Cloud projects or folders created in your organization,
then consider configuring
default resource settings for Cloud Logging.
Delete
You can't delete the _Default or the _Required sinks.
When you delete a sink, it no longer routes log entries.
If the sink has a dedicated service account, then deleting that sink also
deletes the service account. Sinks created before
May 22, 2023 have dedicated service accounts. Sinks created
on or after May 22, 2023 have a shared service account.
Deleting the sink doesn't delete the shared service account.
Troubleshoot failures
View log volume and error rates
Following are the instructions for managing a sink in a Google Cloud project.
Instead of a Google Cloud project, you can specify a billing account,
folder, or organization:
You can disable the _Default sink and any user-defined sinks. When you
disable a sink, the sink stops routing log entries to its destination.
For example, if you disable the _Default sink, then no log entries are
routed to the _Default bucket. The
_Default bucket becomes empty when all of the previously stored log entries
have fulfilled the bucket's
retention period.
The following instructions illustrate how to
disable your Google Cloud project sinks that route log entries to the
_Default log buckets:
To use client library code to configure sinks in your chosen languages, see
Code samples.
Filter examples
Following are some filter examples that are particularly useful when creating
sinks. For additional examples that might be useful as you build your inclusion
filters and exclusion filters, see
Sample queries.
Restore the _Default sink filter
If you edited the filter for the _Default sink, then you might want to restore
this sink to its original configuration. When created, the _Default sink is
configured with the following inclusion filter and an empty exclusion filter:
NOT log_id("cloudaudit.googleapis.com/activity") AND NOT \
log_id("externalaudit.googleapis.com/activity") AND NOT \
log_id("cloudaudit.googleapis.com/system_event") AND NOT \
log_id("externalaudit.googleapis.com/system_event") AND NOT \
log_id("cloudaudit.googleapis.com/access_transparency") AND NOT \
log_id("externalaudit.googleapis.com/access_transparency")
Exclude Google Kubernetes Engine container and pod logs
To exclude Google Kubernetes Engine container and pod log entries for
GKE system namespaces, use the following filter:
resource.type = ("k8s_container" OR "k8s_pod")
resource.labels.namespace_name = (
"cnrm-system" OR
"config-management-system" OR
"gatekeeper-system" OR
"gke-connect" OR
"gke-system" OR
"istio-system" OR
"knative-serving" OR
"monitoring-system" OR
"kube-system")
To exclude Google Kubernetes Engine node log entries for GKE
system logNames, use the following filter:
resource.type = "k8s_node"
logName:( "logs/container-runtime" OR
"logs/docker" OR
"logs/kube-container-runtime-monitor" OR
"logs/kube-logrotate" OR
"logs/kube-node-configuration" OR
"logs/kube-node-installation" OR
"logs/kubelet" OR
"logs/kubelet-monitor" OR
"logs/node-journal" OR
"logs/node-problem-detector")
To view the volume of Google Kubernetes Engine node, pod, and container log entries
stored in log buckets, use Metrics Explorer:
Although Cloud Logging lets you exclude log entries and prevent them
from being stored in a log bucket,
you might want to consider keeping log entries that help with supportability.
Using these log entries can help you troubleshoot and identify issues
with your applications.
For example, GKE system log entries are useful to
troubleshoot
your GKE applications and clusters because they are
generated for events that happen in your cluster. These log entries can help you
determine if your application code or the underlying GKE
cluster is causing your application error. GKE system logs
also include Kubernetes Audit Logging generated by the Kubernetes API Server
component, which includes changes made using the kubectl command and Kubernetes
events.
For Dataflow, we recommended that you, at a minimum, write your system
logs (labels."dataflow.googleapis.com/log_type"="system") and supportability
logs (labels."dataflow.googleapis.com/log_type"="supportability") to
log buckets. These logs
are essential for developers to observe and troubleshoot their Dataflow
pipelines, and users might not be able to use the Dataflow
Job details page to view job logs.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-09 UTC."],[],[]]