Cloud Logging is a comprehensive solution for managing logs generated by your applications, the platform they run on, and the underlying infrastructure, whether it’s on Google Cloud, other cloud providers, or on-premises systems. This fully managed service allows you to easily store, search, analyze, monitor, and receive alerts on logging data and events from all of these environments.
Logs are one of the most important sources of information when it comes to day-to-day admin activities and troubleshooting. Google Cloud services are capable of generating various types of logs, including the following:
- Platform logs: These are, in most cases, enabled by default and can’t be disabled; they are logs from Google Cloud services such as Compute Engine VMs or Google Cloud Storage.
- Component logs: These are similar to platform logs but come from the Google software components that run on user-owned systems.
- Security logs: These logs are collected for auditing and compliance purposes. In Chapter 12, detailed information about security logs will be provided.
- User-written logs: These are enabled and controlled by a user. They are logs collected by Ops Agent, APIs, client libraries, and third-party applications.
- Multi-cloud and hybrid-cloud logs: These come from other cloud providers and on-premises environments.
The Logging service, by default, encrypts the ingested logs using Google-managed encryption keys. But it is possible to use customer-managed keys to control the encryption process altogether.
When designing system architecture, you may want to have control over where your logs are streamed and for how long they are stored. To route logs to specified destinations, Google Cloud uses log sinks. All logs are stored in _Required and _Default log buckets, but it is also possible to keep them in other destinations, such as the following:
- Google Cloud Storage
- BigQuery
- Pub/Sub, which can be used for third-party integrations such as Splunk
- Customer-owned cloud logging buckets
When your project is created, there are two sinks defined:
- _Required, which sends logs to a global audit log bucket where the logs are stored for 400 days. You can’t delete a _Required sink or edit it to change the log destination. Logs that are stored in an audit log bucket are related to the following:
- Admin activities related to modifying configuration or metadata, for example, when a VM instance is created
- System events from Google Cloud Platform
- Access transparency related to a justified Google’s access to your resources
- _Default, which sends the remaining part of logs to a global default log bucket where logs are stored for 30 days. A user can change the retention period. You can also delete the _Default sink and create your sinks if you don’t want your logs to be stored in a global bucket.
The following diagram is based on Routing and storage overview from Google’s documentation, which you can read here: https://cloud.google.com/logging/docs/routing/overview. It covers how logs are routed via default, customized sinks, and the default and customized destinations to route them:
Figure 11.23 – Routing and storing Cloud Logging entries
In addition to _Required and _Default sinks, users can define their own sinks and send data to other locations, also customizing the retention time to adjust to their company’s policy. In the upcoming sections, we will learn how to customize such log sinks, but first, let’s look at how logs are presented in Cloud Logging dashboards and how to filter logs before we send them to a new destination.