Entradas do registo de rotas

Este documento explica como o Cloud Logging encaminha as entradas de registo que são recebidas por Google Cloud. Existem vários tipos diferentes de destinos de encaminhamento. Por exemplo, pode encaminhar as entradas de registo para um destino, como um contentor de registos, que armazena as entradas de registo. Se quiser exportar os dados de registos para um destino de terceiros, pode encaminhar as entradas de registos para o Pub/Sub. Além disso, uma entrada de registo pode ser encaminhada para vários destinos.

A um nível elevado, é assim que o Cloud Logging encaminha e armazena as entradas de registo:

Figura que ilustra como o Cloud Logging encaminha as entradas de registo.

Acerca dos routers de registos

Cada Google Cloud projeto, conta de faturação, pasta e organização tem um Log Router, que gere o fluxo de entradas de registo através de destinos ao nível do recurso. Um Log Router também gere o fluxo de uma entrada do registo através de destinos que se encontram na hierarquia de recursos da entrada. Os destinos controlam a forma como as entradas de registo são encaminhadas para os destinos.

Um Log Router armazena uma entrada de registo temporariamente. Este comportamento protege contra interrupções temporárias e indisponibilidades que podem ocorrer quando uma entrada de registo flui através de destinos. O armazenamento temporário não protege contra erros de configuração.

O armazenamento temporário do Log Router é diferente do armazenamento a longo prazo fornecido pelos contentores de registos.

As entradas de registo recebidas com indicações de tempo que sejam anteriores ao período de retenção de registos ou que sejam posteriores a 24 horas são rejeitadas.

Acerca dos sinks de registo

Quando um destino de registo recebe uma entrada de registo, determina se deve ignorar ou encaminhar a entrada de registo. Esta decisão é tomada comparando a entrada do registo com os filtros no destino do registo. Quando a entrada do registo é encaminhada, o destino do registo envia a entrada do registo para o destino especificado pelo destino do registo. Esse destino pode ser um projeto, uma localização de armazenamento ou um serviço.

Os destinos de registo pertencem a um determinado Google Cloud recurso: Google Cloud projetos, contas de faturação, pastas e organizações. Estes recursos também contêm vários destinos de registo. Quando um recurso recebe uma entrada de registo, cada destino de registo nesse recurso avalia independentemente a entrada de registo. Consequentemente, vários destinos de registo podem encaminhar a mesma entrada de registo.

Por predefinição, os dados de registo são armazenados no projeto onde os dados têm origem. No entanto, existem vários motivos pelos quais pode querer alterar esta configuração:

  • Para centralizar o armazenamento dos dados de registo.
  • Para juntar os dados de registo com outros dados empresariais.
  • Para organizar os dados de registo de uma forma útil para si.
  • Para transmitir os seus registos para outras aplicações, outros repositórios ou terceiros. Por exemplo, pode querer exportar os seus registos do Google Cloud para os poder ver numa plataforma de terceiros. Para exportar as entradas de registo, crie um destino de registo que encaminhe as entradas de registo para o Pub/Sub.

Um sink de registo configurado incorretamente não encaminha as entradas de registo. Quando um destino está configurado incorretamente, são escritas entradas de registo que comunicam os detalhes do erro. Além disso, é enviado um email para os contactos essenciais do recurso. Para mais informações, consulte o artigo Resolução de problemas: ver erros.

Os destinos de registos não podem encaminhar retroativamente entradas de registos. Ou seja, um destino de registo não pode encaminhar uma entrada de registo que foi recebida antes de o destino ter sido criado. Da mesma forma, se um destino estiver configurado incorretamente, encaminha apenas as entradas de registo que chegam depois de o erro de configuração ser resolvido. No entanto, pode copiar retroativamente dados de registo de um contentor de registos para o Cloud Storage. Para mais informações, consulte o artigo Copiar registos.

Suporte para organizações e pastas

Para ajudar a gerir os dados de registo numa organização ou pasta, pode fazer o seguinte:

  • Pode criar destinos agregados, que encaminham as entradas de registo de uma organização ou uma pasta e respetivos filhos para o destino especificado pelo destino. Existem dois tipos de destinos agregados:

    • Destinos agregados sem interceção
    • Intercetar destinos agregados

    A diferença entre estes dois tipos de destinos é que os destinos de interceção num nível da hierarquia de recursos podem afetar o encaminhamento de recursos num nível inferior da hierarquia. Os destinos não intercetores não afetam o encaminhamento de outros recursos. Quando um filtro de interceção num recurso corresponde a uma entrada de registo, a entrada de registo não é enviada para os filtros nos recursos secundários, com a exceção de que a entrada de registo é sempre enviada para o filtro de registo _Required no recurso onde a entrada de registo tem origem.

  • Pode configurar as predefinições de recursos para especificar a configuração do destino _Default criado pelo sistema para novos recursos numa organização ou numa pasta. Por exemplo, pode usar estas definições para desativar o destino _Default ou especificar os filtros nesse destino.

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.

Filtros de sinks de registo

Cada destino de registo contém um filtro de inclusão e pode conter vários filtros de exclusão. Estes filtros determinam se o destino do coletor recebe uma entrada de registo. Se não especificar filtros, todas as entradas de registo são encaminhadas para o destino do coletor.

Uma entrada de registo é encaminhada por um destino de registo com base nestas regras:

  • Se a entrada do registo não corresponder ao filtro de inclusão, não é encaminhada. Quando um destino não especifica um filtro de inclusão, todas as entradas de registo correspondem a esse filtro.

  • Se a entrada do registo corresponder ao filtro de inclusão e, pelo menos, a um filtro de exclusão, não é encaminhada.

  • Se a entrada do registo corresponder ao filtro de inclusão e não corresponder a nenhum filtro de exclusão, é encaminhada para o destino do coletor.

Os filtros num destino do registo são especificados através da linguagem de consulta de registo.

Não pode usar filtros de exclusão para reduzir o consumo da sua entries.write quota da API nem o número de entries.write chamadas da API. Os filtros de exclusão são aplicados depois de as entradas de registo serem recebidas pela API Logging.

Sinks de registo criados pelo sistema

Para cada Google Cloud projeto, conta de faturação, pasta e organização, o Cloud Logging cria dois destinos de registo, um denominado _Required e o outro denominado _Default. Os filtros de inclusão e exclusão para estes destinos verificam se cada entrada de registo que atinge o recurso é encaminhada por um destes destinos. Ambos os destinos encaminham os dados de registo para um contentor de registos que se encontra no mesmo recurso que o destino de registos.

O resto desta secção fornece informações sobre os filtros e os destinos dos contentores de registos criados pelo sistema.

_Required sink de registo

O _Required sink de registo num recurso encaminha um subconjunto de registos de auditoria para o _Required contentor de registos do recurso. Este destino não especifica filtros de exclusão e o filtro de inclusão é o seguinte:

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

O destino de registo _Required só corresponde a entradas de registo originárias do recurso onde o destino de registo _Required está definido. Por exemplo, suponhamos que um destino de registo encaminha uma entrada do registo de atividade do projeto A para o projeto B. Uma vez que a entrada de registo não teve origem no projeto B, o destino de registo _Required no projeto B não encaminha esta entrada de registo para o contentor de registos _Required.

Não pode modificar nem eliminar o destino de registo _Required.

_Default sink de registo

O destino de registo _Default num recurso encaminha todas as entradas de registo, exceto as que correspondem ao filtro do destino de registo _Required, para o contentor de registos _Default do recurso. Uma vez que o filtro de inclusão para este destino está vazio, corresponde a todas as entradas de registo. No entanto, o filtro de exclusão está configurado da seguinte forma:

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

Pode modificar e desativar o destino de registo _Default. Por exemplo, pode editar o destino do registo _Default e alterá-lo. Também pode modificar qualquer filtro existente e adicionar filtros de exclusão.

Destinos de sincronização

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.

Limitações de destinos

Esta secção descreve as limitações específicas do destino:

  • Se encaminhar as entradas de registo para um contentor de registos num Google Cloud projeto diferente, o Error Reporting não analisa essas entradas de registo. Para mais informações, consulte o artigo Vista geral dos relatórios de erros.
  • Se encaminhar entradas de registo para um conjunto de dados do BigQuery, o conjunto de dados do BigQuery tem de ter a gravação ativada. Não pode encaminhar entradas de registo para conjuntos de dados associados, que são só de leitura.
  • Os novos destinos que encaminham dados de registo para contentores do Cloud Storage podem demorar várias horas a começar a encaminhar entradas de registo. Estes destinos são processados de hora em hora.

  • Aplicam-se as seguintes limitações quando o destino de um coletor de registos é um Google Cloud projeto:

    • Existe um limite de um salto.
    • As entradas de registo que correspondem ao filtro do _Required sink de registo só são encaminhadas para o contentor de registos _Required do projeto de destino quando têm origem no projeto de destino.
    • Apenas os destinos agregados que se encontram na hierarquia de recursos de uma entrada de registo processam a entrada de registo.

    Por exemplo, suponha que o destino de um coletor de registos no projeto A é o projeto B. Então, as seguintes afirmações são verdadeiras:

    • Devido ao limite de um salto, os destinos de registo no projeto B não podem reencaminhar entradas de registo para um projeto Google Cloud .
    • O contentor de registos _Required do projeto B apenas armazena entradas de registo que têm origem no projeto B. Este contentor de registos não armazena entradas de registo originárias de outros recursos, incluindo as originárias do projeto A.
    • Se a hierarquia de recursos do projeto A e do projeto B for diferente, então uma entrada de registo que um destino de registo no projeto A encaminha para o projeto B não é enviada para os destinos agregados na hierarquia de recursos do projeto B.
    • Se o projeto A e o projeto B tiverem a mesma hierarquia de recursos, as entradas de registo são enviadas para os destinos agregados nessa hierarquia. Se uma entrada de registo não for intercetada por um sink agregado, o Router de registos envia a entrada de registo para os sinks no projeto A.

Como as entradas do registo de encaminhamento afetam as 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. Por exemplo, pode usar uma métrica baseada em registos para contar o número de entradas de registo que contêm uma determinada mensagem ou para extrair informações de latência registadas nas entradas de registo. Pode apresentar métricas baseadas em registos em gráficos do Cloud Monitoring, e as políticas de alerta podem monitorizar estas métricas.

As métricas baseadas em registos definidas pelo sistema aplicam-se ao nível do projeto. As métricas baseadas em registos definidas pelo utilizador podem ser aplicadas ao nível do projeto ou do contentor de registos. As métricas baseadas em registos ao nível do contentor são úteis quando usa destinos agregados para encaminhar entradas de registo para um contentor de registos e quando encaminha entradas de registo de um projeto para um contentor de registos noutro projeto.

Métricas baseadas em registos definidas pelo sistema
O Log Router contabiliza uma entrada de registo quando todas as seguintes condições são verdadeiras:
  • A entrada de registo passa pelos sinks de registo do projeto onde a métrica baseada em registos está definida.

  • A entrada de registo é armazenada num contentor de registos. O contentor de registos pode estar em qualquer projeto.

    Por exemplo, suponhamos que o projeto A tem um destino de registo cujo destino é o projeto B. Suponha também que os destinos de registo no projeto B encaminham as entradas de registo para um contentor de registo. Neste cenário, as entradas de registo encaminhadas do projeto A para o projeto B contribuem para as métricas baseadas em registos definidas pelo sistema do projeto A. Estas entradas de registo também contribuem para as métricas baseadas em registos definidas pelo sistema do projeto B.

Métricas baseadas em registos definidas pelo utilizador
O Log Router contabiliza uma entrada de registo quando todas as seguintes condições são verdadeiras:
  • A faturação está ativada no projeto onde a métrica baseada em registos está definida.
  • Para métricas ao nível do contentor, a entrada de registo é armazenada no contentor de registos onde a métrica baseada em registos está definida.
  • Para métricas ao nível do projeto, a entrada de registo passa pelos sinks de registo do projeto onde a métrica baseada em registos está definida.

Para mais informações, consulte o artigo Vista geral das métricas baseadas em registos.

Práticas recomendadas

Para ver práticas recomendadas sobre a utilização do encaminhamento para a gestão de dados ou para exemplos de utilização comuns, consulte os seguintes documentos:

Exemplos: centralize o armazenamento de registos

Esta secção descreve como pode configurar o armazenamento centralizado. O armazenamento centralizado oferece um único local para consultar dados de registo, o que simplifica as suas consultas quando está a pesquisar tendências ou a investigar problemas. Do ponto de vista da segurança, também tem uma localização de armazenamento, o que pode simplificar as tarefas dos seus analistas de segurança.

Se centralizar o armazenamento de registos, considere se deve colocar um ónus no projeto que armazena os dados de registo. Um bloqueio pode impedir a eliminação acidental de um projeto. Para saber mais, consulte o artigo Proteger projetos com hipotecas.

Centralize o armazenamento de registos de projetos numa pasta

Suponhamos que gere uma pasta e quer centralizar o armazenamento das suas entradas de registo. Para este exemplo de utilização, pode fazer o seguinte:

  1. Na pasta, cria um projeto com o nome CentralStorage.
  2. Crie um sink agregado de interceção para a sua pasta e configure-o para encaminhar todas as entradas de registo. Define o destino do coletor como o projeto com o nome CentralStorage.

Quando chega uma entrada de registo originária da pasta ou de um dos respetivos recursos subordinados, essa entrada de registo é enviada para o destino agregado de interceção que criou. Esse destino encaminha as entradas do registo para o projeto com o nome CentralStorage. Os sinks de registo neste projeto processam as entradas do registo:

  • O _Default destino de registo encaminha para o _Default contentor de registos todas as entradas de registo que correspondem ao filtro do destino. Este contentor de registos é a sua localização de armazenamento centralizada.

  • O _Required destino de registos encaminha para o _Required contentor de registos as entradas de registos que correspondem aos filtros do destino e que têm origem no projeto CentralStorage. Este contentor de registos não é uma localização de armazenamento centralizada. No entanto, pode armazenar centralmente todos os seus dados de registo. Para ver um exemplo, consulte o artigo Armazene registos de auditoria numa localização central.

Após a conclusão do processamento do destino agregado, a entrada de registo é enviada para o destino de registo _Required no recurso no qual a entrada de registo teve origem. Quando a entrada do registo corresponde ao filtro no sink de registo _Required, a entrada do registo é encaminhada para o contentor de registos _Required do recurso. Consequentemente, cada Google Cloud projeto na sua pasta armazena entradas de registo no respetivo contentor de registos _Required.

Centralize o armazenamento de registos para um conjunto de projetos

Também pode armazenar entradas de registo numa única localização quando não tem uma organização nem uma pasta. Por exemplo, pode fazer o seguinte:

  1. Crie um projeto com o nome CentralStorage.
  2. Para cada projeto, exceto CentralStorage, edite o sink de registo _Default e defina o destino como o projeto denominado CentralStorage.

Pode perguntar-se por que motivo o exemplo anterior define o destino dos _Default coletores de registos como um projeto, em vez do _Default contentor de registos nesse projeto. Os principais motivos são a simplicidade e a consistência. Quando encaminha entradas de registo para um projeto, os destinos de registo no projeto de destino controlam que entradas de registo são armazenadas e onde são armazenadas. Ou seja, centraliza a funcionalidade de filtro e destino. Se quiser alterar as entradas de registo armazenadas ou onde são armazenadas, só tem de modificar os destinos de registo num projeto.

Centralize o armazenamento de registos de auditoria

Pode armazenar centralmente entradas de registo que correspondam ao _Required destino do registo. Se quiser armazenar estas entradas do registo centralmente, faça uma das seguintes ações:

  • Crie destinos de registo que encaminham as entradas de registo que correspondem ao destino de registo _Required para um contentor de registo centralizado.

  • Configure os sinks de registo como nos dois exemplos anteriores e, em seguida, adicione um sink de registo no projeto de destino que encaminhe as entradas de registo que correspondam ao sink de registo _Required para um contentor de registos. Também pode editar os filtros no destino de registo _Default.

Antes de implementar uma estratégia deste tipo, reveja as diretrizes de preços.

Preços

Para saber mais sobre os preços do Cloud Logging, consulte a página de preços do Google Cloud Observability.

O que se segue?

Para ajudar a encaminhar e armazenar dados do Cloud Logging, consulte os seguintes documentos: