我偶然發現了一個問題，決定尋求建議並最終找到具有相同業務需求（和問題）的人。
摘要 - 我們最近將一個客戶的 SQL 服務從自託管 MySQL 遷移到 Google CloudSQL MySQL 5.7 服務，現在我們正在尋找一種方法來允許我們的客戶訪問/查看和分析 MySQL 慢速情況登入其自託管 ELK 堆疊。
以前這不是問題，因為我們可以存取 SQL 服務慢日誌文件，並設法在 Elasticsearch 中「追蹤」、匯出和索引這些日誌。下面顯示了特定 Elasticsearch MySQL 慢日誌單文件先前的樣子的快速範例： https://prnt.sc/sjitys
請注意，每個文件都包含：
Time
User@Host
Query_time
timestamp
選擇/插入/更新/刪除查詢以及基於lock_time、rows_queried、rows_affected、rows_returned等分析資料的能力。
以下是如何在我們的用戶端無權存取的 GCP 日誌檢視器中顯示 MySQL 慢速日誌的範例： https://user-images.githubusercontent.com/9348708/80950753-2418bf80-8dff-11ea-9a00-3f5131b5e0f3.png
所以我們的目標是以類似之前使用的方式將 MySQL 慢日誌串流到 ELK 堆疊。
為了實現我們的目標，我們嘗試透過 Pub/Sub 導出器拉取 GCP MySQL 慢日誌（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 VM 上，我們安裝並配置了名為pubsubbeat 的檔案匯出服務（該服務類似於filebeat 的pubsub 輸入法），以將SQL 慢日誌從GCP 串流傳輸到問題 3 中虛擬機器上的檔案include_lines: [‘textPayload’]。
注意：GCP MySQL 慢日誌透過 google-fluidd 代理程式訪問，並使用單一資料類型 LogEntry 表示，該類型為所有日誌條目定義某些通用資料並攜帶單獨的有效負載。格式為 JSON，每個日誌行都封裝為單獨的 JSON 物件。例子：https://prnt.sc/sep2zk
迫在眉睫的問題- Pub/Sub 做了一些權衡以實現其高可用性和吞吐量，不幸的是，消息亂序就是其中之一- 換句話說，MySQL 慢日誌的順序是混合的，我們無法正確封裝每個單獨的慢日誌物件透過定義它以“^# Time”字串開頭 - 相反，我們有以下格式：https://prnt.sc/seoztj
因此，如果有人分享他們如何將多行日誌檔案（或直接MySQL 慢日誌）從GCP 匯出到外部日誌分析系統（如ELK 堆疊），那麼這將是非常有幫助的，這樣我們就可以更好地了解什麼是在這種情況下最好的方法是什麼？
答案1
這是對的。Pub/Sub 不保證交付順序。您可以做的就是按以下順序訂購發佈時間。有一些樣品在 Pub/Sub 文件中。
或者，您可以將資料流管道新增至方程式並讓它為您排序資料。然後，您可以根據客戶的業務需求執行批次作業。這種方法需要大量的配置工作，而且成本會更高。
我強烈建議您查看上面的一些範例，看看它們是否適合您的需求。