Os registros de fluxo são agregados por conexão de IP (5-tupla). Esses registros são usados para monitoramento de rede, perícia forense, análise de segurança e otimização de despesas.
É possível ver os registros de fluxo no Cloud Logging e exportá-los para qualquer destino compatível com a exportação do Cloud Logging.
Casos de uso
Monitoramento de rede
Os registros de fluxo de VPC fornecem visibilidade sobre
capacidade de processamento e desempenho. É possível:
monitorar a rede VPC;
realizar o diagnóstico de rede;
Filtrar os registros de fluxo por VMs, anexos de VLAN e
túneis do Cloud VPN para entender as mudanças no tráfego
entender o crescimento do tráfego para previsão de capacidade.
Como entender o uso da rede e como otimizar as despesas de tráfego de rede
É possível analisar o uso da rede com os registros de fluxo de VPC para
otimizar as despesas de tráfego de rede. Por exemplo, você pode
analisar os fluxos de rede para:
tráfego entre regiões e zonas;
tráfego para países específicos na Internet;
Tráfego para redes no local e outras redes na nuvem
Principais usuários na rede, incluindo VMs, anexos da VLAN e
túneis do Cloud VPN
Perícia forense da rede
É possível usar os registros de fluxo de VPC para fazer uma análise forense na rede. Por exemplo, se houver um incidente, você pode examinar:
quais IPs conversaram com quem e quando isso aconteceu;
todos os IPs comprometidos, pela análise de todos os fluxos de rede de entrada e de saída.
Especificações
Os registros de fluxo de VPC fazem parte do Andromeda, o software que aciona
redes VPC. Eles não causam atrasos ou penalidades de desempenho quando ativados.
Os registros de fluxo de VPC funcionam com redes VPC, não com redes legadas. Os registros de fluxo de VPC são ativados ou desativados por sub-rede,
anexo da VLAN para o Cloud Interconnect
(visualização) ou túnel do Cloud VPN
(visualização). Se ativados para uma sub-rede,
os registros de fluxo de VPC coletam dados de todas as instâncias de VM, incluindo
nós do GKE nessa sub-rede.
Os registros de fluxo de VPC fornecem amostras de fluxos TCP, UDP, ICMP, ESP e
GRE. São fornecidas amostras para os fluxos de entrada e os de saída. Esses fluxos podem estar dentro do Google Cloud ou entre o Google Cloud e outras redes.
Se um fluxo for capturado por amostragem, os registros de fluxo de VPC gerarão um registro para o fluxo. Cada registro de fluxo inclui as informações descritas na seção Formato do registro.
Os registros de fluxo de VPC interagem com as regras de firewall das seguintes maneiras:
Os pacotes de saída são amostrados antes das regras de firewall de saída. Mesmo que uma regra de firewall de saída negue pacotes de saída, é possível que esses pacotes sejam amostrados por registros de fluxo de VPC.
Os pacotes de entrada são amostrados depois das regras de firewall de entrada. Se uma regra de firewall de entrada negar pacotes de entrada, esses pacotes não serão amostrados por registro de fluxo de VPC.
É possível usar filtros nos registros de fluxo de VPC para gerar apenas determinados registros.
Os registros de fluxo de VPC são compatíveis com VMs que têm várias interfaces de rede.
É necessário ativar os registros de fluxo de VPC para cada sub-rede, em cada VPC, que contenha uma interface de rede.
Para registrar fluxos entre pods no mesmo nó do Google Kubernetes Engine (GKE), ative a visibilidade intranós no cluster.
Os registros de fluxo de VPC não são informados dos recursos do Cloud Run.
Coleta de registros
A amostragem dos pacotes é feita dentro de um intervalo de agregação. Todos os pacotes coletados para
uma determinada conexão de IP no intervalo de agregação são agregados em uma
única entrada de registro de fluxo. Esses dados são enviados para o Logging.
Para gerar logs de fluxo, os registros de fluxo de VPC coletam amostras de pacotes que saem e entram em uma VM ou passam por um gateway, como um anexo da VLAN ou um túnel do Cloud VPN na nuvem. Após a geração dos registros de fluxo,
os registros de fluxo de VPC os processam seguindo o procedimento descrito
nesta seção.
Os registros de fluxo de VPC fazem a amostragem de pacotes usando uma taxa de amostragem principal.
A taxa de amostragem primária é dinâmica e varia
dependendo da carga do host físico que executa a VM ou o gateway no
durante o período de amostragem. A probabilidade de amostragem de qualquer conexão IP única aumenta
com o volume de pacotes. Não é possível controlar o processo de amostragem do registro de fluxo principal
nem ajustar a taxa de amostragem principal.
Depois que os registros de fluxo são gerados, os registros de fluxo da VPC os processam
de acordo com o seguinte procedimento:
Filtragem: é possível especificar que apenas os registros que corresponderem a critérios especificados serão gerados. Por exemplo, é possível filtrar para que apenas os registros de uma determinada VM ou apenas os registros com um determinado valor de metadados sejam gerados, enquanto o restante é descartado. Para mais informações, consulte Filtragem de registros.
Agregação: as informações dos pacotes da amostragem são agregadas em um intervalo de agregação configurável para produzir uma entrada de registro de fluxo.
Amostragem do registro de fluxo secundário: este é um segundo processo de amostragem. Entradas do registro de fluxo
são amostradas posteriormente de acordo com um parâmetro configurável de taxa de amostragem secundária.
A amostragem secundária é realizada nos registros de fluxo gerados pelo processo de amostragem de registro de fluxo principal. Por exemplo, se a taxa de amostragem secundária for definida como 1.0 ou 100%, os Registros de fluxo da VPC farão a amostragem de 100% dos registros de fluxo gerados pela amostragem de registro de fluxo principal.
Metadados: se desativados, todas as anotações de metadados serão descartadas. Se quiser manter os metadados, você poderá especificar que todos os campos ou um conjunto específico de campos sejam mantidos. Para mais informações, consulte Anotações de metadados.
Gravar no Logging: as entradas de registro finais são gravadas no Cloud Logging.
Como os registros de fluxo de VPC não capturam todos os pacotes, eles compensam os pacotes ausentes por meio da interpolação dos pacotes capturados. Isso acontece com
os pacotes perdidos devido a configurações de amostragem iniciais e definidas pelo usuário.
Embora o Google Cloud não capture todos os pacotes, as capturas de registros podem ser muito grandes. É possível equilibrar a visibilidade do tráfego e suas necessidades de custo de armazenamento ajustando os seguintes aspectos da coleta de registros:
Intervalo de agregação: pacotes amostrados em um intervalo de tempo são agregados em uma única entrada de registro. Esse intervalo de tempo pode ser de 5 segundos (padrão), 30 segundos, 1 minuto, 5 minutos, 10 minutos ou 15 minutos.
Taxa de amostragem secundária:
Nas VMs, 50% das entradas de registro são mantidas por padrão. É possível definir esse parâmetro de 1.0 (100%, todas as entradas de registro serão mantidas) até 0.0 (0%, nenhum registro será mantido).
Para anexos de VLAN e túneis do Cloud VPN, 100% das entradas de registro
são mantidas por padrão. É possível definir isso
de 1.0 para maior que 0.0.
Anotações de metadados: por padrão, as entradas do registro de fluxo contêm informações de metadados, como os nomes das VMs de origem e de destino no Google Cloud ou a região geográfica de origens e destinos externos. É possível desativar as anotações de metadados ou especificar apenas algumas anotações para economizar espaço de armazenamento.
Filtragem: por padrão, os registros são gerados para cada fluxo amostrado.
É possível definir filtros para que sejam gerados apenas registros que correspondam a determinados critérios.
Preços
São aplicados preços padrão para o Logging, BigQuery ou Pub/Sub.
Os preços de registros de fluxo de VPC estão descritos em Preços de telemetria de rede.
A seguir
Para saber mais sobre o formato de registro dos registros de fluxo de VPC e quais metadados
anotações estão disponíveis, consulte
Sobre os registros de fluxo de VPC
Para conferir exemplos de registros de fluxo de VPC coletados para diversos casos de uso,
consulte Sobre fluxos de tráfego.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-12-06 UTC."],[],[],null,["# VPC Flow Logs\n=============\n\nVPC Flow Logs samples packets in your Virtual Private Cloud (VPC)\nnetwork to generate flow logs. Flow logs are aggregated by IP connection\n(5-tuple). VPC Flow Logs samples the following packets:\n\n- Packets sent from and received by [virtual machine (VM) instances](/compute/docs/instances), including instances used as [Google Kubernetes Engine nodes](/kubernetes-engine/docs)\n- Packets sent through VLAN attachments for [Cloud Interconnect](/network-connectivity/docs/interconnect/concepts/overview) and [Cloud VPN](/network-connectivity/docs/vpn/concepts/overview) tunnels\n\nYou can view flow logs in [Cloud Logging](/logging), and you\ncan export logs to any destination that Cloud Logging export supports.\nThese logs can be used for network monitoring, forensics, security analysis,\nand expense optimization.\n\nFor more information, see [Supported configurations](#configurations).\n\nUse cases\n---------\n\nThe following are use cases for VPC Flow Logs.\n\n### Network monitoring\n\nVPC Flow Logs provides you with visibility into network\nthroughput and performance. You can:\n\n- Monitor the VPC network\n- Perform network diagnosis\n- Filter the flow logs by VMs, VLAN attachments, and Cloud VPN tunnels to understand traffic changes\n- Understand traffic growth for capacity forecasting\n\n### Understanding network usage and optimizing network traffic expenses\n\nYou can analyze network usage with VPC Flow Logs to\noptimize network traffic expenses. For example, you can\nanalyze the network flows for the following:\n\n- Traffic between regions and zones\n- Traffic to specific countries on the internet\n- Traffic to on-premises and other cloud networks\n- Top talkers in the network, including VMs, VLAN attachments, and Cloud VPN tunnels\n\n### Network forensics\n\nYou can use VPC Flow Logs for network forensics. For example,\nif an incident occurs, you can examine the following:\n\n- Which IPs talked with whom and when\n- Any compromised IPs by analyzing all the incoming and outgoing network flows\n\nSupported configurations\n------------------------\n\nYou can enable VPC Flow Logs at the organization and project\nlevels. An organization-level VPC Flow Logs configuration enables\nflow logs for all subnets, VLAN attachments, and Cloud VPN tunnels in\nall VPC networks in the organization.\n\nAt the project level, you can enable VPC Flow Logs for specific\nVPC networks, subnets, VLAN attachments, and Cloud VPN\ntunnels.\n\nYou can use filtering to customize these configuration scopes. For more\ninformation, see [Log sampling and processing](#log-sampling).\n\nLogs collection\n---------------\n\nPackets are sampled within an aggregation interval. All packets collected for\na given IP connection within the aggregation interval are aggregated into a\nsingle flow log entry. This data is then sent to\n[Logging](/logging/docs) in the Google Cloud project of the\nVPC network that reported the flow.\n\nLogs are stored in Logging for 30 days by default. If\nyou want to keep logs longer than that, you can either [set a custom\nretention period](/logging/docs/storage#logs-retention) or\n[export them](/logging/docs/export/configure_export_v2) to a supported\ndestination.\n\n### Log sampling and processing\n\nTo generate flow logs, VPC Flow Logs samples packets that\nleave and enter a VM or pass through a gateway such as a VLAN attachment\nor Cloud VPN tunnel. After the flow logs are generated,\nVPC Flow Logs processes them by following the procedure described\nin this section.\n\nVPC Flow Logs samples packets using a *primary sampling rate*.\nThe primary sampling rate is dynamic and varies\ndepending on the load of the physical host running the VM or gateway at the\ntime of sampling. The probability of sampling any single IP connection increases\nwith the volume of packets. You can't control the primary flow log sampling\nprocess or adjust the primary sampling rate.\n\nAfter the flow logs are generated, VPC Flow Logs processes them\naccording to the following procedure:\n\n1. **Filtering** . You can specify that only logs that match specified criteria are generated. For example, you can filter so that only logs for a particular VM or only logs with a particular metadata value are generated and the rest are discarded. For more information, see [Log filtering](/vpc/docs/about-flow-logs-records#filtering).\n2. **Aggregation** . Information for sampled packets is aggregated over a configurable *aggregation interval* to produce a *flow log entry*.\n3. **Secondary flow log sampling** . This is a second sampling process. Flow log entries are further sampled according to a configurable *secondary sampling rate* parameter. The secondary sampling is performed on the flow logs generated by the primary flow log sampling process. For example, if the secondary sampling rate is set to 1.0, or 100%, VPC Flow Logs samples 100% of the flow logs generated by the primary flow log sampling.\n4. **Metadata** . If disabled, all metadata annotations are discarded. If you want to keep metadata, you can specify that all fields or a specified set of fields are retained. For more information, see [Metadata\n annotations](/vpc/docs/about-flow-logs-records#metadata).\n5. **Write to Logging**. The final log entries are written to Cloud Logging.\n\n| **Note:** You can't change how VPC Flow Logs collects samples. However, you can control the secondary flow log sampling with the **Secondary sampling rate** parameter, as described in [Enable VPC Flow Logs](/vpc/docs/using-flow-logs#enabling-vpc-flow-logs). If you need to analyze all packets, you can use [Packet Mirroring](/vpc/docs/packet-mirroring) and collector instances running third-party software.\n\nBecause VPC Flow Logs doesn't capture every packet, it compensates\nfor missed packets by interpolating from the captured packets. This happens for\npackets missed because of initial and user-configurable sampling settings.\n\nEven though Google Cloud doesn't capture every packet, log record captures\ncan be quite large. You can balance your traffic visibility and storage cost\nneeds by adjusting the following aspects of logs collection:\n\n- **Aggregation interval**. Sampled packets for a time interval are aggregated into a single log entry. This time interval can be 5 seconds (default), 30 seconds, 1 minute, 5 minutes, 10 minutes, or 15 minutes.\n- **Secondary sampling rate** .\n - For configurations created with the Compute Engine API, 50% of log entries are kept by default. You can set this parameter from `1.0` (100%, all log entries are kept) to `0.0` (0%, no logs are kept).\n - For configurations created with the Network Management API, 100% of log entries are kept by default. You can set this parameter from `1.0` to greater than `0.0`.\n- **Metadata annotations**. By default, flow log entries are annotated with metadata information, such as the names of the source and destination within Google Cloud or the geographic region of external sources and destinations. Metadata annotations can be turned off, or you can specify only certain annotations, to save storage space.\n- **Filtering**. By default, logs are generated for every sampled flow. You can set filters so that only logs that match certain criteria are generated.\n\nSpecifications\n--------------\n\n- VPC Flow Logs introduces no delay or performance penalty when enabled.\n- VPC Flow Logs works with VPC networks, not legacy networks.\n- VPC Flow Logs [samples](#log-sampling) TCP, UDP, ICMP, ESP, GRE, and RDMA flows:\n - Both inbound and outbound flows are sampled. For RDMA over Converged Ethernet (RoCE), only outbound flows are sampled.\n - Flows can be within Google Cloud or between Google Cloud and other networks.\n - If a flow is captured by sampling, VPC Flow Logs generates a log for the flow. Each flow record includes the information described in the [Record format](/vpc/docs/about-flow-logs-records#record_format) section.\n- VPC Flow Logs interacts with firewall rules in the following ways:\n - Egress packets are sampled *before* *egress* firewall rules. Even if an egress firewall rule denies outbound packets, those packets can be sampled by VPC Flow Logs.\n - Ingress packets are sampled *after* *ingress* firewall rules. If an ingress firewall rule denies inbound packets, those packets aren't sampled by VPC Flow Logs.\n- You can use [filters](/vpc/docs/about-flow-logs-records#filtering) in VPC Flow Logs to generate only certain logs.\n- VPC Flow Logs supports VMs that have multiple network interfaces. You need to enable VPC Flow Logs for each subnet, in each VPC, that contains a network interface.\n- To log flows between Pods on the same Google Kubernetes Engine (GKE) node, you must enable [intranode visibility](/kubernetes-engine/docs/how-to/intranode-visibility) for the cluster.\n- VPC Flow Logs isn't supported for Cloud Run resources.\n- VPC Flow Logs isn't supported for subnets with purpose `INTERNAL_HTTPS_LOAD_BALANCER` because these subnets are used as proxy-only subnets and have no VM instances.\n- VPC Flow Logs writes logs to the project of the reporting VPC network. For resources in Shared VPC networks, logs are reported in the host project.\n\nPricing and billing\n-------------------\n\nStandard pricing for Logging,\nBigQuery, or Pub/Sub apply.\nVPC Flow Logs pricing is described in\n[Network Telemetry pricing](/vpc/pricing#network-telemetry).\n\nVPC Flow Logs charges are billed to the Google Cloud project of the\nresource that reports flow logs. If VPC Flow Logs is enabled for an\norganization, each project is billed separately.\n\nWhat's next\n-----------\n\n- To learn more about the VPC Flow Logs record format and which metadata annotations are available, see [About VPC Flow Logs records](/vpc/docs/about-flow-logs-records).\n- To see examples of VPC Flow Logs that are collected for various use cases, see [About traffic flows](/vpc/docs/about-traffic-flows).\n- To start reporting flows for a subnet, see [Configure VPC Flow Logs](/vpc/docs/using-flow-logs)."]]
