Vista geral dos destinos agregados

Este documento descreve os destinos agregados, que lhe permitem reunir e encaminhar entradas de registo originadas em recursos numa pasta ou numa organização para um destino suportado. Recomendamos que use destinos agregados para encaminhar os dados de registo para uma localização de armazenamento central.

Acerca dos destinos agregados

Uma união agregada é semelhante a uma união ao nível do projeto, uma vez que contém filtros e um destino. No entanto, o Log Router envia as seguintes entradas de registo para um destino agregado:

  • Todas as entradas de registo que têm origem numa pasta ou numa organização.
  • Todas as entradas de registo que têm origem nos recursos secundários da pasta ou da organização.

Por exemplo, se criar um destino agregado ao nível da pasta, o Log Router envia para esse destino todas as entradas de registo que têm origem na pasta ou em recursos secundários da pasta.

Quando existem destinos agregados na hierarquia de recursos de uma entrada de registo, o Router de registos envia inicialmente a entrada de registo para esses destinos. Uma vez que os destinos agregados podem ser intercetores ou não intercetores, o Log Router pode não enviar uma entrada de registo encaminhada por um destino agregado enviada para os destinos ao nível do projeto.

Intercetar o lavatório agregado

Um coletor agregado de interceção impede o encaminhamento de entradas de registo para coletores em recursos secundários, exceto para os coletores _Required nos recursos onde as entradas de registo têm origem. Um destino agregado de interceção pode ser útil para impedir o armazenamento de cópias duplicadas de entradas de registo em vários locais.

Por exemplo, suponhamos que precisa de ativar os registos de auditoria de acesso a dados para fins de auditoria. Para simplificar a análise, quer armazenar estes registos numa localização central. No entanto, por motivos de segurança e custos, também quer impedir que estes registos sejam armazenados ao nível do projeto. Para este cenário, pode criar um destino agregado de interceção.

Destino agregado não intercetor

Um destino agregado não intercetor não afeta a forma como as entradas de registo são encaminhadas para outros destinos. Isto significa que, mesmo quando uma entrada do registo corresponde ao filtro de um destinatário agregado não intercetor, essa entrada do registo é encaminhada para outros destinatários na hierarquia de recursos da entrada do registo. Um destino agregado sem interceção permite-lhe manter a visibilidade das entradas de registo nos recursos em que foram geradas.

Por exemplo, pode criar um destino agregado não intercetor que encaminhe todas as entradas de registo geradas a partir das pastas contidas por uma organização para um contentor de registos central. As entradas de registo são armazenadas no contentor de registos central. No entanto, como o destino é não intercetor, o Log Router também envia entradas de registo para os destinos de registo no recurso em que foram geradas.

Exemplos de encaminhamento

Esta secção ilustra como uma entrada de registo originada num projeto pode fluir através dos destinos na respetiva hierarquia de recursos.

Exemplo: não existem destinos agregados

Quando não existem destinos agregados na hierarquia de recursos da entrada de registo, a entrada de registo é enviada para os destinos de registo no projeto de onde a entrada de registo é originária. Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Exemplo: existe um ponto de recolha agregado não intercetor

Suponha que existe um destino agregado sem interceção na hierarquia de recursos para uma entrada de registo. Depois de o Log Router enviar a entrada do registo para o destino agregado não intercetor, ocorre o seguinte:

  1. O sink agregado não intercetor encaminha a entrada do registo para o destino do sink quando a entrada do registo corresponde ao filtro de inclusão, mas não corresponde a nenhum filtro de exclusão.

  2. O Log Router envia a entrada do registo para os destinos de registo no projeto onde a entrada do registo teve origem.

    Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Exemplo: existe um destino agregado de interceção

Suponha que existe um destino agregado de interceção na hierarquia de recursos para uma entrada de registo. Depois de o Log Router enviar a entrada do registo para o destino agregado de interceção, ocorre uma das seguintes situações:

  • A entrada do registo corresponde ao filtro de inclusão, mas não corresponde a nenhum filtro de exclusão:

    1. A entrada de registo é encaminhada para o destino do sink agregado de interceção.
    2. A entrada de registo é enviada para o destino _Required no projeto onde a entrada de registo foi criada.

  • A entrada do registo não corresponde ao filtro de inclusão ou corresponde a, pelo menos, um filtro de exclusão:

    1. A entrada do registo não é encaminhada pelo destino agregado de interceção.

    2. O Log Router envia a entrada do registo para os destinos de registo no projeto onde a entrada do registo teve origem.

      Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Destinos suportados para origens agregadas

Esta secção indica os destinos suportados para os destinos agregados.

Ralos de interceção

O destino de um coletor agregado de interceção tem de ser um projeto do Google Cloud.Google Cloud

Os sinks de registo no projeto de destino reencaminham as entradas de registo para os respetivos destinos. Todos os destinos, exceto projetos, são suportados. Por exemplo, os depósitos de registos no projeto de destino podem redirecionar as entradas de registo para um contentor de registos.

Lava-louças sem interceção

O destino de um ponto de recolha agregado sem interceção pode ser qualquer um dos seguintes:

O destino de um coletor pode estar num recurso diferente do coletor. Por exemplo, pode usar um destino de registo para encaminhar entradas de registo de um projeto para um contentor de registo armazenado num projeto diferente.

Os seguintes destinos são suportados:

Google Cloud projeto

Selecione este destino quando quiser que os destinos de registo no projeto de destino reencaminhem as suas entradas de registo ou quando tiver criado um destino agregado de interceção. Os sinks de registo no projeto que é o destino do sink podem reencaminhar as entradas de registo para qualquer destino suportado, exceto um projeto.

Contentor de registo

Selecione este destino quando quiser armazenar os seus dados de registo em recursos geridos pelo Cloud Logging. Os dados de registo armazenados em contentores de registos podem ser vistos e analisados através de serviços como o Explorador de registos e a análise de registos.

Se quiser juntar os seus dados de registo a outros dados empresariais, pode armazenar os dados de registo num contentor de registos e criar um conjunto de dados do BigQuery associado. Um conjunto de dados associado é um conjunto de dados só de leitura que pode ser consultado como qualquer outro conjunto de dados do BigQuery.

Conjunto de dados do BigQuery
Selecione este destino quando quiser associar os dados de registo a outros dados da empresa. O conjunto de dados especificado tem de ter a gravação ativada. Não defina o destino de um contentor como um conjunto de dados do BigQuery associado. Os conjuntos de dados associados são só de leitura.
Contentor do Cloud Storage
Selecione este destino quando quiser um armazenamento a longo prazo dos seus dados de registo. O contentor do Cloud Storage pode estar no mesmo projeto de origem das entradas de registo ou num projeto diferente. As entradas de registo são armazenadas como ficheiros JSON.
Tópico do Pub/Sub
Selecione este destino quando quiser exportar os dados de registo do Google Cloud e, em seguida, usar integrações de terceiros, como o Splunk ou o Datadog. As entradas de registo são formatadas em JSON e, em seguida, encaminhadas para um tópico do Pub/Sub.

Práticas recomendadas

Recomendamos que o destino de um coletor agregado seja um Google Cloud projeto. Com este destino, os registos são enviados para o projeto de destino Google Cloud , que redireciona as entradas de registo. O destino _Required encaminha apenas as entradas de registo que correspondem ao respetivo filtro e que têm origem no recurso onde o destino está definido. Por conseguinte, se quiser armazenar cópias adicionais de entradas de registo que correspondam ao filtro do destino _Required, tem de criar um destino de registo personalizado ou modificar o filtro do destino de registo _Default.

Quando cria um destino de interceção, recomendamos que faça o seguinte:

  • Considere se os recursos secundários precisam de controlo independente do encaminhamento das respetivas entradas de registo. Se um recurso filho precisar de controlo independente de determinadas entradas de registo, verifique se o seu receptor de interceção não encaminha essas entradas de registo.

  • Adicione informações de contacto à descrição de um ponto de recolha de interceção. Isto pode ser útil se os responsáveis pela entrada de interceção forem diferentes dos responsáveis pelos projetos cujas entradas de registo estão a ser intercetadas.

  • Teste a configuração do destino criando primeiro um destino agregado sem interceção para verificar se as entradas de registo corretas estão a ser encaminhadas.

Intercetar destinos agregados e métricas baseadas em registos

As métricas baseadas em registos são métricas do Cloud Monitoring derivadas do conteúdo das entradas de registo. A forma como uma entrada de registo é encaminhada determina as métricas baseadas em registos para as quais essa entrada de registo pode contribuir. Uma vez que um destino agregado de interceção afeta a forma como as entradas de registo são encaminhadas, a criação deste tipo de destino pode resultar em alterações aos valores das métricas baseadas em registos existentes.

Para mais informações, consulte o artigo Como as entradas do registo de encaminhamento afetam as métricas baseadas em registos.

Destinos agregados e VPC Service Controls

Aplicam-se as seguintes limitações quando usa destinos agregados e os VPC Service Controls:

  • Os destinos agregados podem aceder a dados de projetos dentro de um perímetro de serviço. Para restringir o acesso de destinos agregados a dados dentro de um perímetro, recomendamos que use o IAM para gerir as autorizações de registo.

  • Os VPC Service Controls não suportam a adição de recursos de pastas ou de organizações a perímetros de serviço. Por conseguinte, não pode usar os controlos de serviço da VPC para proteger os registos ao nível da pasta e da organização, incluindo os registos agregados. Para gerir as autorizações de registo ao nível da pasta ou da organização, recomendamos que use o IAM.

  • Se encaminhar registos através de um destino ao nível da organização ou da pasta para um recurso protegido por um perímetro de serviço, tem de adicionar uma regra de entrada ao perímetro de serviço. A regra de entrada tem de permitir o acesso ao recurso a partir da conta de serviço que o destino agregado usa. Para mais informações, consulte as seguintes páginas:

  • Quando especifica uma política de entrada ou saída para um perímetro de serviço, não pode usar ANY_SERVICE_ACCOUNT e ANY_USER_ACCOUNT como um tipo de identidade quando usa um destino de registo para encaminhar registos para recursos do Cloud Storage. No entanto, pode usar ANY_IDENTITY como o tipo de identidade.

O que se segue?