Monitorar mensagens

Neste guia, descrevemos como monitorar as mensagens enviadas ao Manufacturing Data Engine (MDE), como elas fluem pelo pipeline de processamento e como diagnosticar problemas que podem ocorrer devido a configuração ou possíveis problemas no sistema.

Para monitorar as mensagens que passam pelo MDE, use a tabela do BigQuery operations-log. Sempre que uma etapa do pipeline de MDE não processa uma mensagem, ela é enviada para a tabela operations-log, indicando a etapa e o motivo da falha.

Todas as mensagens com falha são gravadas nessa tabela. No entanto, é possível configurar o MDE para gravar também as mensagens bem-sucedidas na tabela operations-log. Isso é útil ao depurar problemas, mas não deve ser deixado ativado, já que pode gerar muito tráfego adicional no sistema e prejudicar o desempenho na produção.

REST

Execute a seguinte solicitação da API REST para configurar a tabela operations-log:

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

Em que:

  • ALL: todas as mensagens serão enviadas à tabela operations-log para cada etapa no pipeline de processamento.
  • ERROR: somente as mensagens que falharam em alguma das etapas de processamento serão enviadas para a tabela operations-log.

Etapas de processamento

Para diagnosticar por que uma mensagem está sendo rejeitada ao passar pelo pipeline de processamento, é útil conhecer as diferentes etapas de processamento e entender o que elas fazem. Para mais informações, consulte Arquitetura do MDE.

  1. message-mapper: lê o JSON original, o corresponde à classe de mensagem correspondente e o processa usando o Whistle para emitir um ou mais registros.
  2. configuration-manager: cria uma nova tag no sistema se ela ainda não existir e adiciona ao registro todas as propriedades definidas no tipo apropriado (buckets de metadados, coletores e transformações).
  3. metadata-manager: resolve todas as referências de metadados desse registro, atualiza as instâncias de metadados do sistema se uma nova for recebida e adiciona metadados materializados ao registro se ele estiver configurado para isso.
  4. bigquery-sink: mapeia o registro para a estrutura de tipo apropriada e o envia para o tópico correspondente do Pub/Sub para ser gravado no BigQuery.
  5. pubsub-sink: mapeia o registro para a estrutura Proto ou JSON do Pub/Sub e o envia para o tópico correspondente.
  6. GCSWriter: grava dados brutos conforme são recebidos do tópico input-messages e dados processados depois que passam pelo gerenciador de metadados.
  7. BigtableWriter: grava dados no Bigtable.
  8. GCSReader: lê arquivos do Cloud Storage e envia as mensagens para input-messages.

Diagnosticar mensagens que não aparecem no coletor configurado

Se você enviar uma mensagem para o MDE e ela não estiver no receptor configurado, primeiro verifique se o tipo configurou o receptor corretamente (conforme explicado na seção "Tipo") e se você está consultando a tabela correta no BigQuery. A tabela recebe o nome do tipo.

Se isso estiver configurado corretamente, use a tabela operations-log para diagnosticar o problema. Você pode começar com uma consulta geral, ordenando por event_timestamp ou filtrando para quando a mensagem foi enviada, como mostra o exemplo a seguir:

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
ORDER BY
  event_timestamp desc
LIMIT 100;

Você também pode usar o source_message_id para filtrar uma mensagem específica. Esse ID é atribuído pelo Pub/Sub ao publicar uma mensagem. Se você usar a gcloud CLI para publicar uma mensagem na linha de comando, ela vai retornar o messageId da mensagem publicada.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) <= CURRENT_DATE()
  AND source_message_id = 'PubSubMessageId';

Se você não encontrar a mensagem ou houver muitas, filtre com base em um atributo da mensagem original. A mensagem é sempre registrada no campo payload com o estado em que a última etapa a deixou e é salva em um campo JSON. Assim, é mais fácil usar TO_JSON_STRING e % para procurar mensagens que contenham o texto desejado.

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
  AND TO_JSON_STRING(payload) LIKE "%TEXT-TO-FIND%"
ORDER BY
  event_timestamp DESC;

Depois de encontrar sua mensagem na tabela operations-log, consulte a coluna error-message para saber o motivo da rejeição. Os erros mais comuns são os seguintes:

  • Não foi possível corresponder a mensagem recebida a nenhuma das classes de mensagem registradas no gerenciador de configuração.
  • Nenhum analisador encontrado para a classe de mensagem <MESSAGE_CLASS_NAME>.
  • O processamento da mensagem foi ignorado porque não foi possível desserializar (a mensagem não é um JSON válido).
  • Não foi possível construir uma mensagem válida com o analisador <PARSER_NAME>. A mensagem não tem o campo de carimbos de data/hora.
  • Não foi possível construir uma mensagem válida com o analisador <PARSER_NAME>. A mensagem não tem o campo "tagName" ou ele está em branco.
  • Não foi possível construir uma mensagem válida com o analisador <PARSER_NAME>. O carimbo de data/hora da mensagem está fora dos limites aceitos.

Depois de encontrar e corrigir o erro que está causando a falha da mensagem, elas começarão a chegar aos respectivos receptores.