Я наткнулся на проблему и решил спросить совета и в конечном итоге найти кого-то с такими же бизнес-потребностями (и проблемами).
Резюме - мы недавно перенесли службу SQL одного из наших клиентов из автономного MySQL в службу Google CloudSQL MySQL 5.7, и теперь мы ищем способ разрешить нашему клиенту доступ / просмотр и анализ медленной работы MySQL. журналы в своем собственном стеке ELK.
Раньше это не было проблемой, поскольку у нас был доступ к файлу журнала медленной работы службы SQL, и мы могли «отслеживать», экспортировать и индексировать эти журналы в Elasticsearch. Ниже показан быстрый пример того, как ранее выглядел конкретный единый документ с медленным журналом MySQL Elasticsearch: https://prnt.sc/sjitys
Обратите внимание, что каждый документ содержал:
Time
User@Host
Query_time
timestamp
Выберите / Вставить / Обновить / Удалить запрос и возможность анализа данных на основе lock_time, rows_queried, rows_affected, rows_returned и т. Д.
Вот пример того, как медленные журналы MySQL отображаются в средстве просмотра журналов GCP, к которому у нашего клиента нет доступа: https://user-images.githubusercontent.com/9348708/80950753-2418bf80-8dff-11ea-9a00-3f5131b5e0f3.png
Итак, наша цель - передать логи медленной работы MySQL в стек ELK способом, аналогичным тому, который использовался ранее.
Для достижения нашей цели мы попытались получить журналы медленной работы GCP MySQL с помощью модуля экспорта Pub / Sub (https://cloud.google.com/logging/docs/export) и передавать журналы в стек ELK. Для этого мы сделали следующее: 1. создали приемник журналов (маршрутизатор журналов) с помощью фильтра ниже: resource.type = "cloudsql_database" logName = "projects / XXX / logs / cloudsql.googleapis.com% 2Fmysql-slow .log "и экспортировали в службу приемника Google Pub / Sub 2. на виртуальной машине Google Computer Engine мы установили и настроили службу экспорта файлов с именем pubsubbeat (служба похожа на метод ввода pubsub в filebeat) для потоковой передачи медленных журналов SQL из GCP в файл на рассматриваемой виртуальной машине 3. настроил службу filebeat для отслеживания журналов, экспортируемых GCP на виртуальной машине, и с помощью include_lines: [‘textPayload’] для включения только важной информации в каждый объект JSON, извлеченный GCP
NB. Доступ к журналам медленных операций GCP MySQL осуществляется через агент google-fluentd, и они представлены с использованием одного типа данных, LogEntry, который определяет определенные общие данные для всех записей журнала, а также несет индивидуальную полезную нагрузку. Формат - JSON, и каждая строка журнала инкапсулируется в отдельный объект JSON. Пример: https://prnt.sc/sep2zk
Непосредственная проблема - Pub / Sub делает некоторые компромиссы для достижения своей высокой доступности и пропускной способности, и, к сожалению, получение сообщений не по порядку является одним из них - другими словами, порядок медленных журналов MySQL смешанный, и мы не можем должным образом инкапсулировать каждый отдельный объект медленного журнала указав, что он начинается со строки «^ # Time» - вместо этого мы имеем следующий формат: https://prnt.sc/seoztj
Поэтому было бы очень полезно, если бы кто-нибудь поделился, как они экспортируют многострочные файлы журналов (или медленные журналы MySQL напрямую) из GCP во внешнюю систему анализа журналов (как стек ELK), чтобы мы могли лучше понять, что лучший подход в этой ситуации?
Это верно. Pub / Sub не гарантирует порядок доставки. Что вы можете сделать, так это заказать publishTime. Есть некоторые образцы в документации Pub / Sub.
Кроме того, вы можете добавить в уравнение конвейер потока данных и упорядочить данные за вас. Затем вы можете запустить пакетное задание в соответствии с потребностями бизнеса вашего клиента. Этот метод потребует много работы по настройке и будет стоить значительно дороже.
Я настоятельно рекомендую вам изучить некоторые из приведенных выше примеров и посмотреть, соответствуют ли они вашим потребностям.
