Importar registros do Cloud Storage para o Cloud Logging

Last reviewed 2024-01-02 UTC

Nesta arquitetura de referência, descrevemos como importar de volta para o Cloud Logging registros que foram anteriormente exportados para o Cloud Storage.

Esta arquitetura de referência é destinada a engenheiros e desenvolvedores, incluindo DevOps, engenheiros de confiabilidade do site (SREs) e investigadores de segurança que querem configurar e executar o job de importação de registros. Neste documento, consideramos que você já tem familiaridade com a execução de jobs do Cloud Run e sabe como usar o Cloud Storage e o Cloud Logging.

Arquitetura

O diagrama a seguir mostra como os serviços do Google Cloud são usados nesta arquitetura de referência:

Diagrama do fluxo de trabalho da importação de registros do Cloud Storage para o Cloud Logging.

Esse fluxo de trabalho inclui os seguintes componentes:

  • Bucket do Cloud Storage: contém os registros exportados anteriormente que você quer importar de volta para o Cloud Logging. Como esses registros já foram exportados, eles estão organizados no formato de exportação esperado.
  • Job do Cloud Run: executa o processo de importação de registros:
    • Lê os objetos que armazenam entradas de registro do Cloud Storage.
    • Encontra registros exportados para o ID de registro especificado, no período solicitado, com base na organização dos registros exportados no bucket do Cloud Storage.
    • Converte os objetos em estruturas LogEntry da API Cloud Logging. Várias estruturas LogEntry são agregadas em lotes para reduzir o consumo da cota da API Cloud Logging. A arquitetura processa erros de cota quando necessário.
    • Grava as entradas de registro convertidas no Cloud Logging. Se você executar o mesmo job várias vezes, poderá haver entradas duplicadas. Para mais informações, consulte Executar o job de importação.
  • Cloud Logging: ingere e armazena as entradas de registro convertidas. As entradas de registro são processadas conforme descrito na Visão geral de roteamento e armazenamento.
    • São aplicadas cotas e limites do Logging, incluindo as cotas e os limites da API Cloud Logging e um período de armazenamento de 30 dias. Essa arquitetura de referência foi projetada para trabalhar com as cotas de gravação padrão, com um mecanismo básico de novas tentativas. Se a cota de gravação for menor que a padrão, a implementação poderá falhar.
    • Os registros importados não são incluídos nas métricas com base em registros porque os carimbos de data/hora estão no passado. No entanto, se você optar por usar um rótulo, o carimbo de data/hora registrará o horário da importação e os registros serão incluídos nos dados das métricas.
  • BigQuery: usa o SQL para executar consultas analíticas em registros importados (opcional). Para importar registros de auditoria do Cloud Storage, essa arquitetura modifica os IDs de registro. Considere essa renomeação ao consultar os registros importados.

Caso de uso

Escolha implantar essa arquitetura se sua organização exigir uma análise de registro extra para investigações de incidentes ou outras auditorias de eventos anteriores. Por exemplo, é recomendável analisar as conexões com os bancos de dados sobre o primeiro trimestre do ano passado, como parte de uma auditoria de acesso ao banco de dados.

Alternativas de design

Nesta seção, descrevemos alternativas ao design padrão mostrado neste documento de arquitetura de referência.

Período de armazenamento e registros importados

O Cloud Logging exige que as entradas de registro recebidas tenham carimbos de data/hora que não excedam um período de armazenamento de 30 dias. As entradas de registro importadas com carimbos de data/hora anteriores a 30 dias no horário da importação não são armazenadas.

Essa arquitetura valida o período definido no job do Cloud Run para evitar a importação de registros com mais de 29 dias, deixando uma margem de segurança de um dia.

Para importar registros com mais de 29 dias, é necessário fazer as seguintes alterações no código de implementação e depois criar uma nova imagem de contêiner para usar a configuração do job do Cloud Run.

  • Remover a validação de 30 dias do período
  • Adicionar o carimbo de data/hora original como rótulo do usuário à entrada de registro
  • Redefinir o rótulo do carimbo de data/hora da entrada de registro para permitir que ela seja ingerida com o carimbo de data/hora atual

Ao usar essa modificação, você precisa usar o campo labels no lugar do campo timestamp nas suas consultas da Análise de dados de registros. Para mais informações sobre consultas e amostras da Análise de dados de registros, confira Amostras de consultas SQL.

Considerações sobre o design

As diretrizes a seguir podem ajudar você a desenvolver uma arquitetura que atenda aos requisitos da sua organização.

Otimização de custos

O custo da importação de registros usando essa arquitetura de referência tem vários fatores contribuintes.

Você usa os seguintes componentes faturáveis do Google Cloud:

Considere os seguintes fatores que podem aumentar os custos:

  • Cópia de registros: para evitar custos extras de armazenamento de registros, não execute o job de importação com a mesma configuração várias vezes.
  • Armazenamento em outros destinos: para evitar custos extras de armazenamento de registros, desative as políticas de roteamento no projeto de destino para evitar o armazenamento em outros locais ou o encaminhamento dos registros para outros destinos, como o Pub/Sub ou o BigQuery.
  • Mais CPU e memória: se o job de importação expirar, talvez seja necessário aumentar a CPU e a memória do job de importação na configuração desse job. Aumentar esses valores pode aumentar os custos gerados do Cloud Run.
  • Tarefas extras: se o número esperado de registros a serem importados a cada dia dentro do período for alto, talvez seja necessário aumentar o número de tarefas na configuração do job de importação. O job dividirá o período igualmente entre as tarefas, de modo que cada uma processará simultaneamente um número semelhante de dias no intervalo. O aumento do número de tarefas pode aumentar os custos gerados do Cloud Run.
  • Classe de armazenamento: se a classe de armazenamento do bucket do Cloud Storage for diferente de Standard, como Nearline, Disponibilidade durável reduzida (DRA, na sigla em inglês) ou Coldline, poderá haver cobranças extras.
  • Tráfego de dados entre locais diferentes: configure o job de importação para que seja executado no mesmo local do bucket do Cloud Storage de onde você importa os registros. Caso contrário, poderão ocorrer custos de saída de rede.

Para gerar uma estimativa de custo com base na projeção de uso, incluindo jobs do Cloud Run, use a calculadora de preços.

Eficiência operacional

Nesta seção, descrevemos considerações sobre o gerenciamento de consultas analíticas após a implantação da solução.

Nomes e consultas de registros

Os registros são armazenados no projeto definido no campo logName da entrada de registro. Para importar os registros para o projeto selecionado, essa arquitetura modifica o campo logName de cada registro importado. Os registros de importação são armazenados no bucket de registros padrão do projeto selecionado que tem o ID de registro imported_logs (a menos que o projeto tenha uma política de roteamento de registros que altere o destino de armazenamento). O valor original do campo logName é preservado no campo labels com a chave original_logName.

Considere o local do valor logName original ao consultar os registros importados. Para mais informações sobre consultas e amostras da Análise de dados de registros, consulte Amostras de consultas SQL.

Otimização de desempenho

Se o volume de registros que você importará exceder os limites de capacidade do Cloud Run, o job poderá expirar antes de a importação ser concluída. Para evitar uma importação de dados incompleta, aumente o valor de tasks no job de importação. Aumentar os recursos de CPU e memória também pode ajudar a melhorar o desempenho da tarefa ao aumentar o número de tarefas.

Implantação

Para implantar essa arquitetura, consulte Implantar um job para importar registros do Cloud Storage para o Cloud Logging.

Próximas etapas

Colaboradores

Autor: Leonid Yankulin | Engenheiro de relações com desenvolvedores

Outros colaboradores: