A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/stackdriver/docs/solutions/gke/using-logs below:

View GKE logs | Google Kubernetes Engine (GKE)

This page provides an overview of how to find and use your Google Kubernetes Engine (GKE) logs.

Accessing your logs

You can access your GKE logs in many ways:

For custom log aggregation, log analytics, or integration with third-party systems, you can also use the logging sinks feature to export logs to BigQuery, Cloud Storage, and Pub/Sub.

Understanding your logs

A log in Cloud Logging is a collection of log entries, and each log entry applies to a certain type of logging resource.

Resource types

These are the resource types that are specific to GKE clusters:

Log resource types gke_cluster GKE cluster operations logs gke_nodepool GKE node pool operations logs k8s_cluster Kubernetes cluster logs k8s_node Kubernetes node logs k8s_pod Kubernetes Pod logs k8s_container Kubernetes container logs k8s_control_plane_component Kubernetes control plane component logs

When GKE writes your cluster's logs, each log entry includes the resource type. Understanding where your logs appear makes it easier to find your logs when you need them.

System logs

System logs include logs from the following sources:

Your system audit logs will appear in Cloud Logging with the following names:

For detailed information about log entries that apply to the Kubernetes Cluster and GKE Cluster Operations resource types, refer to the Audit logging documentation.

There are additional system logs such as those for the kube-system that are written which are described in Controlling the collection of your application logs.

Kubernetes Event logs

In Kubernetes, Events are objects that provide information about resources, such as state changes, node errors, Pod errors, or scheduling failures. Various Kubernetes components, such as the kubelet or workload controllers, create Events to report changes in objects. For example, the StatefulSet controller might create an Event when the number of replicas in a StatefulSet changes. For more information about Events, see the Event API reference page and the Kubernetes glossary entry for Event.

You can find the logs for Kubernetes Events in Logging with the projects/PROJECT_ID/logs/events log name. Log entries for Events use one of the following resource types, depending on the component that created the Event in the Kubernetes API:

Application logs

Kubernetes containers collect logs for your workloads written to STDOUT and STDERR. You can find your workload application logs using the k8s_container resource type. Your logs will appear in Logging with the following names:

Control plane component logs

If control plane logs are enabled for your GKE cluster, then logs emitted by certain Kubernetes control plane components (for instance, the API server, Scheduler, and Controller Manager) are exported to Cloud Logging.

These logs use the k8s_control_plane_component resource type and appear in Cloud Logging with the following names:

Control plane access logs

If you use GKE control plane authority, you can enable optional logs for all incoming network connections to control plane instances and when SSH events occur in your control plane instances. You can then correlate these control plane access logs with logs from Access Transparency and with logs from the Kubernetes API server to optionally verify that connections to your control plane instances were the result of authorized administrative access by Google personnel. For details, see Verify Google connections to the cluster control plane.

These logs use the gke_cluster resource type and appear in Cloud Logging with the following names:

Cluster identity issuance logs

If you use GKE control plane authority to run your own certificate authorities (CAs) and signing keys for your cluster, GKE generates audit logs for when those CAs and keys are used to issue X.509 certificates or JSON Web Tokens (JWTs) in your cluster. You can then correlate these identity issuance logs with logs from the Kubernetes API server, from Certificate Authority Service, and from Cloud Key Management Service to track the usage of those certificates and JWTs in your cluster. For details, see Verify identity issuance and usage.

These logs are System Event audit logs use the gke_cluster resource type and appear in Cloud Logging with the following name:

Finding your logs in the Logging user interface

You can view your logs using the Logs Explorer in the Logging user interface.

Logs Explorer

Using the Query Builder, you can build a query either by selecting fields from a drop-down or by adding query parameters manually. For example, if you're reviewing logs for GKE clusters, you can start with selecting or searching for the Kubernetes Cluster resource type and then select the location and cluster name. You can then refine your search by selecting the Activity logs in the Log Name selector.

The Logs Explorer offers an additional way to build your search queries using the Logs field explorer. It shows the count of log entries, sorted by decreasing count, for the given log field. Using the Logs field explorer is particularly useful for GKE logs because the Logs field explorer provides a way to select the Kubernetes values for your resources to build a query. For example, using the Logs field explorer, you can select logs for a specific cluster, namespace, pod name, and then container name.

You can find more details in the Logging documentation about using the Logs Explorer.

Sample queries

If you're looking for specific logs, use the following sample queries to help you find your GKE logs:

Troubleshoot common issues with logs

If you're writing a high volume of logs from your GKE cluster, you might find that many of those logs consistently don't appear in Cloud Logging. A potential cause is that your logging volume exceeds the supported logging throughput for GKE.

Logging supports up to 100KB/s per node of logging throughput. If any of the nodes in your GKE cluster require greater logging throughput than this, then we recommend increasing the logging agent throughput.

While you investigate instances, you can use Gemini Cloud Assist Investigations to gain additional insights into your logs, and resolve issues. For more information about different ways to initiate an investigation by using the Logs Explorer, see Troubleshoot issues with Gemini Cloud Assist Investigations in the Gemini documentation.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4