Implante o streaming de registros do Google Cloud no Splunk

Last reviewed 2023-11-16 UTC

Neste documento, descrevemos como implantar um mecanismo de exportação para fazer streaming de registros dos recursos do Google Cloud para o Splunk. É necessário já ter lido a arquitetura de referência correspondente para este caso de uso.

Estas instruções são destinadas a operações e administradores de segurança que querem transmitir registros do Google Cloud para o Splunk. Você precisa conhecer o Splunk e o Splunk HTTP Event Collector (HEC) ao usar estas instruções para operações de TI ou casos de uso de segurança. Embora não seja obrigatório, a familiaridade com pipelines do Dataflow, Pub/Sub, Cloud Logging, Identity and Access Management e Cloud Storage é útil para essa implantação.

Para automatizar as etapas de implantação nessa arquitetura de referência usando infraestrutura como código (IaC, na sigla em inglês), consulte o repositório terraform-splunk-log-export do GitHub.

Arquitetura

O diagrama a seguir mostra a arquitetura de referência e como os dados de registro fluem do Google Cloud para o Splunk.

Conforme mostrado no diagrama, o Cloud Logging coleta os registros em um coletor no nível da organização e os envia para o Pub/Sub. O serviço Pub/Sub cria um único tópico e assinatura para os registros e os encaminha para o pipeline principal do Dataflow. O pipeline principal do Dataflow é um pipeline de streaming do Pub/Sub para o Splunk que extrai registros da assinatura do Pub/Sub e os entrega para o Splunk. Paralelo ao pipeline principal do Dataflow, o pipeline secundário do Dataflow é um pipeline de streaming do Pub/Sub para o pipeline do Pub/Sub para reproduzir mensagens se uma entrega falhar. No final do processo, o Splunk Enterprise ou o Splunk Cloud Platform atua como um endpoint HEC e recebe os registros para análise posterior. Para mais detalhes, consulte a seção Arquitetura da arquitetura de referência.

Para implantar essa arquitetura de referência, execute as seguintes tarefas:

• Executar tarefas de configuração.
• Criar um coletor de registros agregado em um projeto dedicado.
• Crie um tópico de mensagens inativas.
• Configurar um endpoint de HEC do Splunk.
• Configurar a capacidade do pipeline do Dataflow.
• Exportar registros para o Splunk.
• Transformar registros ou eventos em andamento usando funções definidas pelo usuário (UDF) no pipeline do Dataflow do Splunk.
• Tratar falhas de entrega para evitar a perda de dados devido a possíveis problemas de configuração ou de falha temporária da rede.

Antes de começar

Conclua as etapas a seguir para configurar um ambiente da sua arquitetura de referência do Google Cloud para o Splunk:

• Criar um projeto, ativar o faturamento e as APIs.
• Conceda papéis do IAM.
• Configurar o ambiente.
• Configure uma rede segura.

Criar um projeto, ativar o faturamento e as APIs

1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

3. Ative as APIs Cloud Monitoring API, Secret Manager, Compute Engine, Pub/Sub, and Dataflow.

   Ative as APIs

Conceder papéis do IAM

No console do Google Cloud, verifique se você tem as seguintes permissões de Identity and Access Management (IAM) para recursos da organização e do projeto. Saiba mais em Como conceder, alterar e revogar acesso a recursos.

Permissões	Papéis predefinidos	Recurso
logging.sinks.create logging.sinks.get logging.sinks.update	Gravador de configuração de registros (roles/logging.configWriter)	Organização
compute.networks.* compute.routers.* compute.firewalls.* networkservices.*	Administrador de rede do Compute (roles/compute.networkAdmin) Administrador de segurança do Compute (roles/compute.securityAdmin)	Projeto
secretmanager.*	Administrador do Secret Manager (roles/secretmanager.admin)	Projeto

Se os papéis predefinidos do IAM não incluírem permissões suficientes para você executar suas tarefas, crie um papel personalizado. O papel personalizado oferece o acesso de que você precisa e ajuda a seguir o princípio do privilégio mínimo.

Observação: para criar o coletor de registros agregados da organização, você precisa ter o papel Gravador de configuração de registros atribuído a você na hierarquia da organização. Se você não tiver acesso para alterar permissões no nível da organização, peça ao administrador da sua organização do Google Cloud para criar o coletor de registros de toda a organização para você. Para mais informações sobre o controle de acesso do Cloud Logging, consulte Papéis predefinidos do Cloud Logging.

Configure seu ambiente

1. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

2. Defina o projeto para sua sessão ativa do Cloud Shell:

   gcloud config set project PROJECT_ID
   

   Substitua PROJECT_ID pela ID do seu projeto.

Configurar uma rede segura

Nesta etapa, veja como configurar uma rede segura para poder processar e exportar registros para o Splunk Enterprise.

1. Crie uma rede e uma sub-rede VPC:

   gcloud compute networks create NETWORK_NAME --subnet-mode=custom
   gcloud compute networks subnets create SUBNET_NAME \
   --network=NETWORK_NAME \
   --region=REGION \
   --range=192.168.1.0/24
   

   Substitua:

   • NETWORK_NAME: o nome da sua rede
   • SUBNET_NAME: o nome da sub-rede
   • REGION: a região que você quer usar para essa rede.

2. Crie uma regra de firewall para as máquinas virtuais (VMs) de worker do Dataflow se comunicarem:

   gcloud compute firewall-rules create allow-internal-dataflow \
   --network=NETWORK_NAME \
   --action=allow \
   --direction=ingress \
   --target-tags=dataflow \
   --source-tags=dataflow \
   --priority=0 \
   --rules=tcp:12345-12346
   

   Essa regra permite o tráfego interno entre as VMs do Dataflow que usam as portas TCP 12345-12346. Além disso, o serviço Dataflow define a tag dataflow.

3. Crie um gateway do Cloud NAT:

   gcloud compute routers create nat-router \
   --network=NETWORK_NAME \
   --region=REGION
   
   gcloud compute routers nats create nat-config \
   --router=nat-router \
   --nat-custom-subnet-ip-ranges=SUBNET_NAME \
   --auto-allocate-nat-external-ips \
   --region=REGION
   

4. Ative o Acesso privado do Google na sub-rede:

   gcloud compute networks subnets update SUBNET_NAME \
   --enable-private-ip-google-access \
   --region=REGION
   

Criar um coletor de registros

Nesta seção, veja como criar o coletor de registros em toda a organização e o destino do Pub/Sub com as permissões necessárias.

1. No Cloud Shell, crie um tópico do Pub/Sub e a assinatura associada como o novo destino do coletor de registros:

   gcloud pubsub topics create INPUT_TOPIC_NAME
   gcloud pubsub subscriptions create \
   --topic INPUT_TOPIC_NAME INPUT_SUBSCRIPTION_NAME
   

   Substitua:

   • INPUT_TOPIC_NAME: o nome do tópico do Pub/Sub a ser usado como destino do coletor de registros.
   • INPUT_SUBSCRIPTION_NAME: o nome da assinatura do Pub/Sub para o destino do coletor de registros

2. Crie o coletor de registros da organização:

   gcloud logging sinks create ORGANIZATION_SINK_NAME \
   pubsub.googleapis.com/projects/PROJECT_ID/topics/INPUT_TOPIC_NAME \
   --organization=ORGANIZATION_ID \
   --include-children \
   --log-filter='NOT logName:projects/PROJECT_ID/logs/dataflow.googleapis.com'
   

   Substitua:

   • ORGANIZATION_SINK_NAME: o nome da organização.
   • ORGANIZATION_ID: o ID da organização

   O comando consiste nas seguintes sinalizações:

   • A flag --organization especifica que o coletor de registros está no nível da organização.
   • A sinalização --include-children é necessária e garante que o coletor de registros no nível da organização inclua todos os registros em todas as subpastas e projetos.
   • A sinalização --log-filter especifica os registros a serem roteados. Neste exemplo, exclua os registros de operações do Dataflow especificamente do projeto PROJECT_ID, porque o pipeline do Dataflow de exportação de registros gera mais registros enquanto os processa. O filtro impede que o pipeline exporte os próprios registros, evitando um ciclo possivelmente exponencial. A saída inclui uma conta de serviço na forma de o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Conceda o papel de IAM de Editor do Pub/Sub à conta de serviço do coletor de registros no tópico do Pub/Sub INPUT_TOPIC_NAME. Esse papel permite que a conta de serviço do coletor de registros publique mensagens no tópico.

   gcloud pubsub topics add-iam-policy-binding INPUT_TOPIC_NAME \
   --member=serviceAccount:LOG_SINK_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/pubsub.publisher
   

   Substitua LOG_SINK_SERVICE_ACCOUNT pelo nome da conta de serviço do coletor de registros.

Criar um tópico de mensagens inativas

Para evitar possíveis perdas de dados quando uma mensagem não é entregue, crie um tópico de mensagens inativas do Pub/Sub e uma assinatura correspondente. A mensagem com falha é armazenada no tópico de mensagens inativas até que um operador ou engenheiro de confiabilidade do site possa investigar e corrigir a falha. Para ver mais informações, consulte a seção Repetir mensagens com falha da arquitetura de referência.

• No Cloud Shell, crie um tópico de mensagens inativas do Pub/Sub e uma assinatura para evitar a perda de dados, armazenando mensagens não entregues:

  gcloud pubsub topics create DEAD_LETTER_TOPIC_NAME
  gcloud pubsub subscriptions create --topic DEAD_LETTER_TOPIC_NAME DEAD_LETTER_SUBSCRIPTION_NAME
  

  Substitua:

  • DEAD_LETTER_TOPIC_NAME: o nome do tópico do Pub/Sub que será o tópico de mensagens inativas.
  • DEAD_LETTER_SUBSCRIPTION_NAME: o nome da assinatura do Pub/Sub para o tópico de mensagens inativas

Configurar um endpoint de HEC do Splunk

Nos procedimentos a seguir, você configura um endpoint de HEC do Splunk e armazena o token de HEC recém-criado como um secret no Secret Manager. Ao implantar o pipeline do Splunk Dataflow, você precisa fornecer o URL do endpoint e o token.

Configurar o HEC do Splunk

1. Se você ainda não tiver um endpoint do HEC do Splunk, consulte a documentação do Splunk para saber como configurar o HEC do Splunk (em inglês). O HEC do Splunk é executado no serviço Splunk Cloud Platform ou na sua própria instância do Splunk Enterprise.
2. No Splunk, depois de criar um token de HEC do Splunk, copie o valor do token.
3. No Cloud Shell, salve o valor do token de HEC do Splunk em um arquivo temporário chamado splunk-hec-token-plaintext.txt.

Observação: para alcançar alta disponibilidade e saber como escalonar com tráfego de alto volume, consulte os documentos do Splunk sobre como escalonar o HEC (em inglês) distribuindo a carga entre vários nós usando um balanceador de carga HTTP(S).

Armazenar o token do HEC do Splunk no Secret Manager

Nesta etapa, você cria um secret e uma única versão do secret subjacente em que armazenar o valor do token HEC do Splunk.

Observação: O Secret Manager tem suporte a partir deModelo do Pub/Sub para Splunk Dataflow versão 00/03/2022_RC00 de dois minutos. Esta arquitetura de referência usa a versão mais recente do modelo.

1. No Cloud Shell, crie um secret para conter o token HEC do Splunk:

   gcloud secrets create hec-token \
    --replication-policy="automatic"
   

   Para mais informações sobre as políticas de replicação de secrets, consulte Escolher uma política de replicação.

2. Adicione o token como uma versão do secret usando o conteúdo do arquivo splunk-hec-token-plaintext.txt:

   gcloud secrets versions add hec-token \
    --data-file="./splunk-hec-token-plaintext.txt"
   

3. Exclua o arquivo splunk-hec-token-plaintext.txt porque ele não é mais necessário.

Configure a capacidade do pipeline do Dataflow

Observação: antes de continuar, verifique se você tem cota suficiente de CPU e IP na região escolhida para provisionar o número máximo possível de VMs do Dataflow (definidas com o --max-workers). Para mais informações sobre como verificar e solicitar um aumento nas cotas, consulte Cotas de alocação.

A tabela a seguir resume as práticas recomendadas gerais para definir as configurações de capacidade do pipeline do Dataflow:

Configuração	Prática recomendada geral
Sinalização --worker-machine-type	Defina como o tamanho da máquina de base n1-standard-4 para conseguir o melhor desempenho com a relação ao custo
Sinalização --max-workers	Defina como o número máximo de workers necessários para lidar com o EPS de pico esperado de acordo com seus cálculos
Parâmetro parallelism	Defina como 2 x vCPUs/worker x o número máximo de workers para maximizar o número de conexões HEC paralelas do Splunk
batchCount parâmetro	Definido como 10 a 50 eventos/solicitação de registros, desde que o atraso máximo de armazenamento em buffer de dois segundos seja aceitável

Lembre-se de usar seus próprios valores e cálculos exclusivos ao implantar essa arquitetura de referência no seu ambiente.

1. Defina os valores para o tipo e a contagem de máquinas. Para calcular valores adequados ao ambiente de nuvem, consulte as seções Tipo de máquina e Contagem de máquinas da arquitetura de referência.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Defina os valores de paralelismo e contagem em lote do Dataflow. Para calcular valores apropriados para o ambiente de nuvem, consulte as seções Paralelismo e Contagem de lotes da arquitetura de referência.

   JOB_PARALLELISM
   JOB_BATCH_COUNT
   

Para mais informações sobre como calcular os parâmetros de capacidade do pipeline do Dataflow, consulte a seção Considerações de design para otimização de desempenho e custos desta arquitetura de referência.

Exportar registros usando o pipeline do Dataflow

Nesta seção, você implantará o pipeline do Dataflow seguindo estas etapas:

• Crie um bucket do Cloud Storage e uma conta de serviço de worker do Dataflow.
• Conceda papéis e acesso à conta de serviço do worker do Dataflow.
• Implante o pipeline do Dataflow.
• Visualizar registros no Splunk.

O pipeline entrega mensagens de registro do Google Cloud ao HEC do Splunk.

Criar um bucket do Cloud Storage e uma conta de serviço de worker do Dataflow

1. No Cloud Shell, crie um novo bucket do Cloud Storage com uma configuração de acesso uniforme no nível do bucket:

   gsutil mb -b on gs://PROJECT_ID-dataflow/
   

   O bucket do Cloud Storage que você acabou de criar é onde o job do Dataflow organiza arquivos temporários.

2. No Cloud Shell, crie uma conta de serviço para os worker do Dataflow:

   gcloud iam service-accounts create WORKER_SERVICE_ACCOUNT \
      --description="Worker service account to run Splunk Dataflow jobs" \
      --display-name="Splunk Dataflow Worker SA"
   

   Substitua WORKER_SERVICE_ACCOUNT pelo nome que você quer usar para a conta de serviço do worker do Dataflow.

Conceder papéis e acesso à conta de serviço do worker do Dataflow

Nesta seção, conceda os papéis necessários à conta de serviço do worker do Dataflow, conforme mostrado na tabela a seguir.

Papel	Caminho	Purpose
Administrador do Dataflow	roles/dataflow.worker	Ative a conta de serviço para atuar como administrador do Dataflow.
Worker do Dataflow	roles/dataflow.worker	Permitir que a conta de serviço atue como um worker do Dataflow.
Administrador de objetos do Storage	roles/storage.objectAdmin	Ative a conta de serviço para acessar o bucket do Cloud Storage usado pelo Dataflow para preparar arquivos.
Editor pub/sub	roles/pubsub.publisher	Ative a conta de serviço para publicar mensagens com falha no tópico de mensagens inativas do Pub/Sub.
Assinante do Pub/Sub	roles/pubsub.subscriber	Ative a conta de serviço para acessar a assinatura de entrada.
Leitor do Pub/Sub	roles/pubsub.viewer	Ative a conta de serviço para ver a assinatura.
Assessor de secret do Secret Manager	roles/secretmanager.secretAccessor	Ative a conta de serviço para acessar o secret que contém o token HEC do Splunk.

1. No Cloud Shell, conceda à conta de serviço de worker do Dataflow os papéis de administrador e worker do Dataflow necessários para executar operações de job e tarefas de administração do Dataflow:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.admin"
   

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.worker"
   

2. Conceda à conta de serviço do worker do Dataflow acesso para visualizar e consumir mensagens da assinatura de entrada do Pub/Sub:

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.subscriber"
   

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.viewer"
   

3. Conceda à conta de serviço do worker do Dataflow acesso para publicar qualquer mensagem com falha no tópico não processado do Pub/Sub:

   gcloud pubsub topics add-iam-policy-binding DEAD_LETTER_TOPIC_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.publisher"
   

4. Conceda à conta de serviço do worker do Dataflow acesso ao secret do token HEC do Splunk no Secret Manager:

   gcloud secrets add-iam-policy-binding hec-token \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
   --role="roles/secretmanager.secretAccessor"
   

5. Conceda à conta de serviço do worker do Dataflow acesso de leitura e gravação ao bucket do Cloud Storage a ser usado pelo job do Dataflow para preparar arquivos:

   gcloud storage buckets add-iam-policy-binding gs://PROJECT_ID-dataflow/ \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com"
   --role=”roles/storage.objectAdmin”
   

Implantar o pipeline do Dataflow

1. No Cloud Shell, defina a seguinte variável de ambiente para o URL do HEC do Splunk:

   export SPLUNK_HEC_URL=SPLUNK_HEC_URL
   

   Substitua a variável SPLUNK_HEC_URL usando o formulário protocol://host[:port], em que:

   • protocol é http ou https.
   • host é o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) ou endereço IP da instância do HEC do Splunk ou, caso você tenha várias instâncias do HEC, o HTTP(S) associado (ou baseado em DNS) ).
   • port é o número da porta HEC. É opcional e depende da configuração do endpoint do HEC do Splunk.

   Um exemplo de uma entrada de URL de HEC do Splunk válida é https://splunk-hec.example.com:8088. Se você estiver enviando dados para o HEC no Splunk Cloud Platform, consulte Enviar dados para o HEC no Splunk Cloud para determinar as partes host e port acima do URL específico do HEC do Splunk.

   Cuidado: a não correspondência ao formato do URL do HEC do Splunk descrito nesta etapa causará erros de validação de entrada do Dataflow, e os dados não serão entregues ao Splunk Endpoint HEC. Em vez disso, os registros de streaming serão enviados para o tópico não processado.

   O URL do HEC do Splunk não pode incluir o caminho do endpoint do HEC, por exemplo, /services/collector. No momento, o modelo do Pub/Sub para o Splunk Dataflow aceita apenas o endpoint /services/collector para eventos formatados em JSON e anexa automaticamente esse caminho à entrada de URL do HEC do Splunk. Para saber mais sobre esse endpoint do HEC, consulte a documentação do Splunk para endpoint de serviços/coletor.

2. Implante o pipeline do Dataflow usando o modelo do Pub/Sub para o Splunk Dataflow:

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --staging-location=gs://PROJECT_ID-dataflow/temp/ \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://splk-public/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   Substitua JOB_NAME pelo formato de nome pubsub-to-splunk-date+"%Y%m%d-%H%M%S".

   Os parâmetros opcionais javascriptTextTransformGcsPath e javascriptTextTransformFunctionName especificam uma UDF de amostra disponível publicamente: gs://splk-public/js/dataflow_udf_messages_replay.js. O exemplo de UDF inclui exemplos de código para transformação de eventos e lógica de decodificação que você usa para reproduzir as entregas com falha. Para mais informações sobre UDF, consulte Transformar eventos em andamento com UDF.

3. Após a conclusão do job do pipeline, encontre o novo ID do job na saída, copie o ID do job e salve. Insira esse ID de job em uma etapa posterior.

Visualizar registros no Splunk

Os workers do pipeline do Dataflow levam alguns minutos para serem provisionados e estarem prontos para entregar registros ao HEC do Splunk. Verifique se os registros foram recebidos e indexados corretamente na interface de pesquisa do Splunk Enterprise ou Splunk Cloud Platform. Para ver o número de registros por tipo de recurso monitorado:

1. Abra o Search & Reporting no Splunk.

2. Execute a pesquisa index=[MY_INDEX] | stats count by resource.type, em que o índice MY_INDEX está configurado para seu token do HEC do Splunk.

   

3. Se você não encontrar eventos, consulte Como tratar falhas de entrega.

Transformar eventos em andamento com a UDF

O modelo do Pub/Sub para o Splunk Dataflow é compatível com uma UDF em JavaScript para transformação de eventos personalizados, como adição de novos campos ou configuração de metadados de HEC do Splunk com base em evento. O pipeline implantado usa esta UDF de amostra.

Nesta seção, saiba como editar a função de UDF de amostra para adicionar um novo campo de evento. Esse novo campo especifica o valor da assinatura do Pub/Sub de origem como informações contextuais adicionais. Em seguida, atualize o pipeline do Dataflow com a UDF modificada.

Modificar a UDF de amostra

1. No Cloud Shell, faça o download do arquivo JavaScript que contém a função da UDF de amostra (em inglês):

     wget https://storage.googleapis.com/splk-public/js/dataflow_udf_messages_replay.js
     

2. No editor de texto de sua escolha, abra o arquivo JavaScript, localize o campo event.inputSubscription, remova a marca de comentário dessa linha e substitua splunk-dataflow-pipeline por INPUT_SUBSCRIPTION_NAME:

   event.inputSubscription = "INPUT_SUBSCRIPTION_NAME";
   

3. Salve o arquivo.

4. Faça upload do arquivo para o bucket do Cloud Storage:

   gsutil cp ./dataflow_udf_messages_replay.js gs://PROJECT_ID-dataflow/js/
   

Atualizar o pipeline do Dataflow com a nova UDF

1. No Cloud Shell, interrompa o pipeline usando a opção "Drenar" para garantir que os registros já extraídos do Pub/Sub não sejam perdidos:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Executar o job do pipeline do Dataflow com a UDF atualizada.

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://PROJECT_ID-dataflow/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   Substitua JOB_NAME pelo formato de nome pubsub-to-splunk-date+"%Y%m%d-%H%M%S".

Processar falhas na entrega

Podem ocorrer falhas de entrega devido a erros no processamento de eventos ou na conexão com o HEC do Splunk. Nesta seção, veja como introduzir uma falha na entrega para mostrar o fluxo de trabalho de tratamento de erros. Além disso, aprenda a visualizar e acionar o reenvio das mensagens com falha para o Splunk.

Acionar falhas de entrega

Para introduzir uma falha de entrega manualmente no Splunk, siga um destes procedimentos:

• Se você executar uma única instância, interrompa o servidor do Splunk para causar erros de conexão.
• Desativar o token do HEC relevante da configuração de entrada do Splunk

Resolver problemas de mensagens com falha

Para investigar uma mensagem que falhou, use o console do Google Cloud:

1. No console do Google Cloud, acesse a página Assinaturas do Pub/Sub.

   Acessar "Inscrições" no Pub/Sub

2. Clique na assinatura não processada que você criou. Se você tiver usado o exemplo anterior, o nome da assinatura será: projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME.

3. Para abrir o visualizador de mensagens, clique em Ver mensagens.

4. Para visualizar mensagens, clique em Pull e deixe a opção Ativar mensagens de confirmação desmarcada.

5. Inspecione as mensagens com falha. Preste atenção no seguinte:

   • O payload de eventos do Splunk na coluna Message body.
   • A mensagem de erro na coluna attribute.errorMessage.
   • O carimbo de data/hora do erro na coluna attribute.timestamp.

A captura de tela a seguir mostra um exemplo de mensagem de falha que você recebe se o endpoint HEC do Splunk estiver temporariamente inativo ou inacessível. Observe que o texto do atributo errorMessage é The target server failed to respond. A mensagem também mostra o carimbo de data/hora associado a cada falha. Use esse carimbo de data/hora para solucionar a causa raiz da falha.

Repetir mensagens com falha

Nesta seção, você precisa reiniciar o servidor do Splunk ou ativar o endpoint do HEC do Splunk para corrigir o erro de entrega. Em seguida, é possível reproduzir as mensagens não processadas.

1. No Splunk, use um dos seguintes métodos para restaurar a conexão com o Google Cloud:

   • Se você interrompeu o servidor do Splunk, reinicie-o.
   • Se você tiver desativado o endpoint do HEC do Splunk na seção Acionar falhas de entrega, verifique se ele está funcionando.

2. No Cloud Shell, tire um snapshot da assinatura não processada antes de reprocessar as mensagens nela. O snapshot evita a perda de mensagens caso haja um erro de configuração inesperado.

   gcloud pubsub snapshots create SNAPSHOT_NAME \
   --subscription=DEAD_LETTER_SUBSCRIPTION_NAME
   

   Substitua SNAPSHOT_NAME por um nome que ajude a identificar o snapshot, como dead-letter-snapshot-date+"%Y%m%d-%H%M%S.

3. Use o modelo do Pub/Sub para Splunk Dataflow para criar um pipeline do Pub/Sub para o Pub/Sub. O pipeline usa outro job do Dataflow para transferir as mensagens da assinatura não processada de volta para o tópico de entrada.

   DATAFLOW_INPUT_TOPIC="INPUT_TOPIC_NAME"
   DATAFLOW_DEADLETTER_SUB="DEAD_LETTER_SUBSCRIPTION_NAME"
   JOB_NAME=splunk-dataflow-replay-date +"%Y%m%d-%H%M%S"
   gcloud dataflow jobs run JOB_NAME \
   --gcs-location= gs://dataflow-templates/latest/Cloud_PubSub_to_Cloud_PubSub \
   --worker-machine-type=n1-standard-2 \
   --max-workers=1 \
   --region=REGION \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME,\
   outputTopic=projects/PROJECT_ID/topics/INPUT_TOPIC_NAME
   

4. Copie o ID do job do Dataflow na resposta ao comando e salve-o para mais tarde. Você inserirá esse ID do job como REPLAY_JOB_ID ao drenar seu job do Dataflow.

5. No console do Google Cloud, acesse a página Assinaturas do Pub/Sub.

   Acessar "Inscrições" no Pub/Sub

6. Selecione a assinatura não processada. Confirme se o gráfico Contagem de mensagens não confirmadas está abaixo de 0, conforme mostrado na captura de tela a seguir.

   

7. No Cloud Shell, drene o job do Dataflow que você criou:

   gcloud dataflow jobs drain REPLAY_JOB_ID --region=REGION
   

   Substitua REPLAY_JOB_ID pelo ID do job do Dataflow que você salvou anteriormente.

Quando as mensagens são transferidas de volta para o tópico de entrada original, o pipeline principal do Dataflow entrega as mensagens com falha novamente ao Splunk de forma automática.

Confirmar mensagens no Splunk

1. Para confirmar que as mensagens foram entregues novamente, abra o Search & Reporting no Splunk.

2. Pesquise delivery_attempts > 1. Esse é um campo especial que a UDF de amostra adiciona a cada evento para rastrear o número de tentativas de entrega. Expanda o intervalo de tempo de pesquisa para incluir eventos que possam ter ocorrido antes, porque o carimbo de data/hora do evento é a hora original de criação, não o momento da indexação.

Na captura de tela a seguir, as duas mensagens que falharam originalmente agora são entregues e indexadas no Splunk com o carimbo de data/hora correto.

Observe que o valor do campo insertId é igual ao valor exibido nas mensagens com falha quando você visualiza a assinatura não processada. O campo insertId é um identificador exclusivo que o Cloud Logging atribui à entrada de registro original. O insertId também aparece no corpo da mensagem do Pub/Sub.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados na arquitetura de referência, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o coletor no nível da organização

• Use o seguinte comando para excluir o coletor de registros no nível da organização:

  gcloud logging sinks delete ORGANIZATION_SINK_NAME --organization=ORGANIZATION_ID
  

Excluir o projeto

Depois de excluir o coletor de registro, prossiga com a exclusão de recursos criados para receber e exportar registros. A maneira mais fácil é excluir o projeto que você criou para a arquitetura de referência.

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

• Para acessar uma lista completa de parâmetros de modelo do Pub/Sub para o Splunk Dataflow, consulte a documentação do Pub/Sub para o Splunk Dataflow.
• Para acessar os modelos correspondentes do Terraform para ajudar você a implantar essa arquitetura de referência, consulte o repositório do GitHub terraform-splunk-log-export. Ele inclui um painel pré-criado do Cloud Monitoring para monitorar o pipeline do Splunk Dataflow.
• Para mais detalhes sobre as métricas personalizadas e a geração de registros do Splunk Dataflow, para monitorar e solucionar problemas dos pipelines do Splunk Dataflow, consulte este blog Novos recursos de observabilidade para os pipelines de streaming do Splunk Dataflow de dois minutos.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.