Me encontré con un problema y decidí pedir consejo y, finalmente, encontrar a alguien con la misma necesidad (y problema) comercial.
Resumen: recientemente migramos el servicio SQL de uno de nuestros clientes desde un MySQL autohospedado al servicio Google CloudSQL MySQL 5.7 y ahora estamos buscando una manera de permitir que nuestro cliente acceda/vea y analice la lentitud de MySQL. inicia sesión en su pila ELK autohospedada.
Esto no era un problema antes, ya que teníamos acceso al archivo de registro lento del servicio SQL y logramos "seguir", exportar e indexar esos registros en Elasticsearch. A continuación se muestra un ejemplo rápido de cómo se veía antes un documento único de registro lento de Elasticsearch MySQL en particular: https://prnt.sc/sjitys
Tenga en cuenta que cada documento contenía:
Time
User@Host
Query_time
timestamp
Seleccione/Insertar/Actualizar/Eliminar CONSULTA y la capacidad de analizar datos en función de lock_time, rows_queried, rows_affected, rows_returned, etc.
A continuación se muestra un ejemplo de cómo se muestran los registros lentos de MySQL en el visor de registros de GCP al que nuestro cliente no tiene acceso: https://user-images.githubusercontent.com/9348708/80950753-2418bf80-8dff-11ea-9a00-3f5131b5e0f3.png
Entonces, nuestro objetivo es transmitir los registros lentos de MySQL a la pila ELK de una manera similar a la utilizada antes.
Para lograr nuestro objetivo, intentamos extraer los registros lentos de MySQL de GCP a través del exportador Pub/Sub (https://cloud.google.com/logging/docs/export) y transmitir registros a la pila ELK. Para ello, hicimos lo siguiente: 1. creamos un receptor de registros (Log Router) utilizando el siguiente filtro: recurso.type="cloudsql_database" logName="projects/XXX/logs/cloudsql.googleapis.com%2Fmysql-slow .log" y exportado al servicio receptor Pub/Sub de Google. 2. En una máquina virtual de Google Computer Engine, instalamos y configuramos el servicio de exportación de archivos llamado pubsubbeat (el servicio es similar al método de entrada pubsub de filebeat) para transmitir los registros lentos de SQL desde GCP a un archivo en la VM en la pregunta 3. configuró un servicio filebeat para seguir los registros exportados por GCP en la VM y usarlo include_lines: [‘textPayload’]para incluir solo la información importante dentro de cada objeto JSON extraído por GCP
Nota: Se accede a los registros lentos de GCP MySQL a través de un agente con fluidez de Google y se representan mediante un único tipo de datos, LogEntry, que define ciertos datos comunes para todas las entradas del registro, además de transportar cargas útiles individuales. El formato es JSON y cada línea de registro se encapsula en un objeto JSON independiente. Ejemplo:https://prnt.sc/sep2zk
Problema inmediato: Pub/Sub hace algunas concesiones para lograr su alta disponibilidad y rendimiento y, desafortunadamente, desordenar los mensajes es una de ellas; en otras palabras, el orden de los registros lentos de MySQL es mixto y no podemos encapsular adecuadamente cada objeto de registro lento por separado. definiendo que comienza con la cadena “^# Hora”; en su lugar, tenemos el siguiente formato:https://prnt.sc/seoztj
Por lo tanto, sería de gran ayuda si alguien compartiera cómo exportan archivos de registro de varias líneas (o registros lentos de MySQL directamente) desde GCP a un sistema externo de análisis de registros (como la pila ELK) para que podamos comprender mejor cuál es el mejor enfoque en esta situación?
Respuesta1
Esto es correcto.Pub/Sub no garantiza el orden de entrega.. Lo que puedes hacer es ordenar por eltiempo de publicación. Hay algunosmuestrasen la documentación de Pub/Sub.
Alternativamente, puede agregar un canal de flujo de datos a la ecuación y hacer que ordene los datos por usted. Luego puede ejecutar un trabajo por lotes según las necesidades comerciales de su cliente. Este método implicará mucho trabajo de configuración y costará mucho más.
Le recomiendo encarecidamente que consulte algunos de los ejemplos anteriores y vea si se adaptan a sus necesidades.