Stay organized with collectionsSave and categorize content based on your preferences.
Use flow logs to save network traffic metadata, including 5-tuples, in
Google Distributed Cloud (GDC) air-gapped to the
observability stack in the form of queryable logs. Use these logs to:
Understand traffic flows for a particular service in an organization.
Understand and identify issues with the network health of a Kubernetes
workload.
You must obtain authorization to manage or view flow logs from the GDC console.
To view or manage flow logs, ask your Organization IAM Admin to grant you the corresponding flow log role.
Before querying and viewing flow logs on dashboards, you must obtain access to the monitoring instance. For more information, seeQuery and view metrics.
Create a flow log
Create a flow log to save network traffic metadata that is filtered by a given set of specifications.
Create flow log with protocol and namespace filters
Create a file calledexample-flowlog.yamlwith the following contents:
ReplaceFLOW_LOG_NAMEwith the chosen name for the flow log.
In this example, the flow log captures all flows for which a TCP connection was
started by any pod in thegpc-systemorkube-systemnamespace to any pod
inkube-systemnamespace. It stops recording logs one hour from
when the object is created.
[[["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 2025-09-04 UTC."],[[["\u003cp\u003eFlow logs in Google Distributed Cloud (GDC) air-gapped capture network traffic metadata, including 5-tuples, for observability, using the open-source Hubble project as a base.\u003c/p\u003e\n"],["\u003cp\u003eThese flow logs are used to understand service traffic, identify network issues in Kubernetes workloads, and verify Kubernetes network policies.\u003c/p\u003e\n"],["\u003cp\u003eTo create a flow log, you define filters using the \u003ccode\u003eFlowLog\u003c/code\u003e resource from the Networking API, such as specifying the protocol and namespaces, and apply it with \u003ccode\u003ekubectl\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eBefore creating, managing, or viewing flow logs, you need the appropriate authorization and access to the monitoring instance.\u003c/p\u003e\n"],["\u003cp\u003eYou can modify existing flow logs by altering the \u003ccode\u003eexample-flowlog.yaml\u003c/code\u003e file and reapplying it, and you can verify the status to ensure that the logging is active and that the configuration has been propagated and reconciled successfully.\u003c/p\u003e\n"]]],[],null,["# Manage flow logs\n\nUse flow logs to save network traffic metadata, including 5-tuples, in\nGoogle Distributed Cloud (GDC) air-gapped to the\nobservability stack in the form of queryable logs. Use these logs to:\n\n- Understand traffic flows for a particular service in an organization.\n- Understand and identify issues with the network health of a Kubernetes workload.\n- Verify Kubernetes network policies.\n\nFlow log is a GDC feature based on the open source\nHubble project: \u003chttps://github.com/cilium/hubble\u003e. Configure flow logs using\nthe [`FlowLog`](/distributed-cloud/hosted/docs/latest/gdch/apis/service/networking/v1/networking-v1#flowlog)\nresource from the\n[Networking API](/distributed-cloud/hosted/docs/latest/gdch/apis/service/networking/networking-api-overview).\n\nBefore you begin\n----------------\n\n- You must obtain authorization to manage or view flow logs from the GDC console.\n\n To view or manage flow logs, ask your Organization IAM Admin to grant you the corresponding flow log role.\n\n For information about setting role bindings from the GDC console, see [Grant access to resources](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/set-up-role-bindings).\n- Before querying and viewing flow logs on dashboards, you must obtain access to the monitoring instance. For more information, see [Query and view metrics](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/query-and-view-metrics).\n\nCreate a flow log\n-----------------\n\nCreate a flow log to save network traffic metadata that is filtered by a given set of specifications.\n| **Note:** To reduce excess and undesired information in the saved logs, narrow down the filter conditions. This is important when the network traffic volume is large.\n\n### Create flow log with protocol and namespace filters\n\n1. Create a file called \u003cvar translate=\"no\"\u003eexample-flowlog.yaml\u003c/var\u003e with the following contents:\n\n apiVersion: networking.gdc.goog/v1\n kind: FlowLog\n metadata:\n name: \"\u003cvar translate=\"no\"\u003eFLOW_LOG_NAME\u003c/var\u003e\"\n namespace: \"platform\"\n spec:\n filters:\n - l4Protocols:\n - tcp\n source:\n namespacePodSelectors:\n - namespace: gpc-system\n - namespace: kube-system\n destination:\n namespacePodSelectors:\n - namespace: kube-system\n lifetime:\n duration: \"1h\"\n\n Replace \u003cvar translate=\"no\"\u003eFLOW_LOG_NAME\u003c/var\u003e with the chosen name for the flow log.\n\n In this example, the flow log captures all flows for which a TCP connection was\n started by any pod in the `gpc-system` or `kube-system` namespace to any pod\n in `kube-system` namespace. It stops recording logs one hour from\n when the object is created.\n2. Create the flow log object:\n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e apply -f \u003cvar translate=\"no\"\u003eexample-flowlog.yaml\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e with the zonal Management API server's kubeconfig path.\n | **Note:** The `FlowLog` object must be created in the `platform` namespace.\n3. Verify that the \u003cvar translate=\"no\"\u003eFLOW_LOG_NAME\u003c/var\u003e value was correctly reconciled, and that the logging process has started by examining the `Status` field:\n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e describe -n platform \u003cvar translate=\"no\"\u003eFLOW_LOG_NAME\u003c/var\u003e\n\n Example status: \n\n Status:\n Clusters:\n Cluster: org-1-infra-cluster\n Conditions:\n Last Transition Time: 2024-01-19T01:46:11Z\n Message:\n Observed Generation: 1\n Reason: ResourcesPropagated\n Status: True\n Type: Propagated\n Name: cilium-flowlog-config\n Namespace: kube-system\n Node: org-1-infra\n Cluster: user-vm-1-cluster\n Conditions:\n Last Transition Time: 2024-01-19T01:46:11Z\n Message:\n Observed Generation: 1\n Reason: ResourcesPropagated\n Status: True\n Type: Propagated\n Name: cilium-flowlog-config\n Namespace: kube-system\n Node: user-vm-1\n Cluster: user-vm-2-cluster\n Conditions:\n Last Transition Time: 2024-01-19T01:46:11Z\n Message:\n Observed Generation: 1\n Reason: ResourcesPropagated\n Status: True\n Type: Propagated\n Name: cilium-flowlog-config\n Namespace: kube-system\n Node: user-vm-2\n Conditions:\n Last Transition Time: 2024-01-18T19:17:53Z\n Message:\n Observed Generation: 1\n Reason: Active\n Status: True\n Type: Logging\n Last Transition Time: 2024-01-19T01:46:11Z\n Message:\n Observed Generation: 1\n Reason: ResourcesPropagated\n Status: True\n Type: Propagated\n Last Transition Time: 2024-01-18T19:17:53Z\n Message:\n Observed Generation: 1\n Reason: Succeeded\n Status: True\n Type: Reconciled\n Start Time: 2024-01-18T19:17:53Z\n End Time: 2024-01-18T20:17:53Z\n\n This example output contains the following conditions:\n - `Propagated`: the flow log configuration was sent to clusters `user-vm-1`, `user-vm-2`, and `org-1-infra`.\n - `Reconciled`: the flow log was successfully programmed on clusters `user-vm-1`, `user-vm-2`, and `org-1-infra`.\n - `Logging`: the flow log is not expired or disabled, has not encountered any error, and may produce logs if the filters match the flows.\n - The `Start Time` and `End Time` indicate the job was started at `19:17:53`, and expires at `20:17:53`.\n\n For this flow log to be able to successfully produce log entries, all `Propagated`, `Reconciled` and `Logging` conditions must be true.\n\nModify flow log\n---------------\n\nTo modify an existing flow log, modify the created flow log object definition in\nthe `example-flowlog.yaml` file and apply it again: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e apply -f \u003cvar translate=\"no\"\u003eexample-flowlog.yaml\u003c/var\u003e\n\nView flow logs in monitor dashboard\n-----------------------------------\n\nTo view flow logs, ask users with the corresponding flow log role to check [Query operational logs](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/query-and-view-logs#query-operational-logs).\n\nReferences\n----------\n\n- Documentation on Hubble Dynamic Exporter: \u003chttps://docs.cilium.io/en/latest/observability/hubble-exporter/#dynamic-exporter-configuration\u003e"]]
