Me deparei com um problema e decidi pedir conselho e, eventualmente, encontrar alguém com a mesma necessidade (e problema) de negócios.
Resumo: migramos recentemente o serviço SQL de um de nossos clientes de um MySQL auto-hospedado para o serviço Google CloudSQL MySQL 5.7 e agora estamos procurando uma maneira de permitir que nosso cliente acesse/visualize e analise o MySQL lento registra em sua pilha ELK auto-hospedada.
Isso não era um problema antes, pois tínhamos acesso ao arquivo de log lento do serviço SQL e conseguimos "seguir", exportar e indexar esses logs no Elasticsearch. Um exemplo rápido de como era antes um documento único de log lento do Elasticsearch MySQL específico é mostrado abaixo: https://prnt.sc/sjitys
Observe que cada documento continha:
Time
User@Host
Query_time
timestamp
Selecionar/inserir/atualizar/excluir QUERY e a capacidade de analisar dados com base em lock_time, rows_queried, rows_affected, rows_returned e etc.
Aqui está um exemplo de como os logs lentos do MySQL são exibidos no visualizador de log do GCP ao qual nosso cliente não tem acesso: https://user-images.githubusercontent.com/9348708/80950753-2418bf80-8dff-11ea-9a00-3f5131b5e0f3.png
Portanto, nosso objetivo é transmitir os logs lentos do MySQL para a pilha ELK de maneira semelhante à usada anteriormente.
Para atingir nosso objetivo, tentamos extrair os logs lentos do MySQL do GCP por meio do exportador Pub/Sub (https://cloud.google.com/logging/docs/export) e transmitir logs para a pilha ELK. Para isso, fizemos o seguinte: 1. criamos um coletor de log (Log Router) usando o filtro abaixo: resource.type="cloudsql_database" logName="projects/XXX/logs/cloudsql.googleapis.com%2Fmysql-slow .log" e exportado para o serviço de coletor Pub/Sub do Google 2. em uma VM do Google Computer Engine, instalamos e configuramos o serviço de exportação de arquivos chamado pubsubbeat (o serviço é semelhante ao método de entrada pubsub do filebeat) para transmitir os logs lentos do SQL do GCP para um arquivo na VM em questão 3. configurou um serviço filebeat para seguir os logs exportados pelo GCP na VM e usando include_lines: [‘textPayload’]para incluir apenas as informações importantes dentro de cada objeto JSON extraído pelo GCP
Observação: os logs lentos do MySQL do GCP são acessados por meio do agente google-fluentd e são representados usando um único tipo de dados, LogEntry, que define determinados dados comuns para todas as entradas de log, além de transportar cargas individuais. O formato é JSON e cada linha de log é encapsulada para separar o objeto JSON. Exemplo:https://prnt.sc/sep2zk
Problema imediato - o Pub/Sub faz algumas compensações para alcançar sua alta disponibilidade e taxa de transferência e, infelizmente, obter mensagens fora de ordem é uma delas - em outras palavras, a ordem dos logs lentos do MySQL é misturada e não podemos encapsular adequadamente cada objeto de log lento separado definindo que ele está começando com a string “^# Time” - em vez disso, temos o seguinte formato:https://prnt.sc/seoztj
Portanto, seria de grande ajuda se alguém compartilhasse como estão exportando arquivos de log multilinha (ou logs lentos do MySQL diretamente) do GCP para um sistema externo de análise de log (como pilha ELK) para que possamos entender melhor qual é o melhor abordagem nesta situação?
Responder1
Isto está certo.O Pub/Sub não garante a ordem de entrega. O que você pode fazer é encomendar pelopublicarTime. Há algunsamostrasna documentação do Pub/Sub.
Como alternativa, você pode adicionar um pipeline do Dataflow à equação e fazer com que ele ordene os dados para você. Você pode então executar um trabalho em lote conforme necessário de acordo com as necessidades comerciais do seu cliente. Este método envolverá muito trabalho para configurar e custará significativamente mais.
Eu recomendo fortemente que você dê uma olhada em alguns dos exemplos acima e veja se eles atendem às suas necessidades.