Я столкнулся с проблемой и решил обратиться за советом, чтобы в конечном итоге найти человека с такой же деловой потребностью (и проблемой).
Краткое описание: недавно мы перенесли службу SQL одного из наших клиентов с размещенной на собственном сервере MySQL на службу Google CloudSQL MySQL 5.7, и теперь мы ищем способ разрешить нашему клиенту получать доступ, просматривать и анализировать журналы медленных запросов MySQL в его размещенном на собственном сервере ELK.
Раньше это не было проблемой, поскольку у нас был доступ к медленному файлу журнала службы SQL, и мы могли "отслеживать", экспортировать и индексировать эти журналы в Elasticsearch. Ниже показан краткий пример того, как выглядел конкретный медленный журнал MySQL Elasticsearch Single Document: 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. создали приемник журналов (Log Router) с помощью фильтра ниже: resource.type="cloudsql_database" logName="projects/XXX/logs/cloudsql.googleapis.com%2Fmysql-slow.log" и экспортировали в службу приемника Pub/Sub от Google 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), чтобы мы могли лучше понять, какой подход является наилучшим в этой ситуации?
решение1
Это верно.Pub/Sub не гарантирует порядок доставки.. Что вы можете сделать, так это заказать повремя публикации. Есть некоторыеобразцыв документации Pub/Sub.
В качестве альтернативы вы можете добавить Dataflow Pipeline в уравнение и позволить ему упорядочить данные для вас. Затем вы можете запустить пакетное задание по мере необходимости для бизнес-потребностей вашего клиента. Этот метод потребует много работы по настройке и будет стоить значительно дороже.
Я настоятельно рекомендую вам ознакомиться с некоторыми из приведенных выше примеров и решить, соответствуют ли они вашим потребностям.