我偶然发现了一个问题,决定征求意见,最终找到一个有同样业务需求(和问题)的人。
总结--我们最近将一个客户端的SQL服务从一个自托管的MySQL迁移到了Google CloudSQL MySQL 5.7服务,现在我们正在寻找一种方法,允许我们的客户端访问/查看和分析他们自己托管的ELK堆栈中的MySQL慢速日志。
这不是一个问题,因为我们可以访问SQL服务缓慢的日志文件,并设法“跟踪”,导出和索引这些日志在Elasticsearch中。下面是一个简单的示例,展示了一个特定的弹性搜索MySQL缓慢日志单文档的外观。
请注意,每一份文件都载有:
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导出程序(https://cloud.google.com/logging/docs/export)将GCP MySQL慢速日志拉到ELK堆栈中。为此,我们做了以下工作: 1.使用下面的过滤器( resource.type="cloudsql_database“cloudsql_database)创建了一个日志接收器(日志路由器),并在Google计算机引擎VM上导出到Google的Pub/Sub接收器服务。在问题3中,我们安装并配置了名为pubsubbeat的文件导出服务(服务类似于file节拍的pubsub输入方法),将SQL慢日志从GCP流到VM上的一个文件中。我们配置了file节拍服务,使其遵循GCP在VM上导出的日志,并使用include_lines: [‘textPayload’]只包含GCP所提取的每个JSON对象中的重要信息。
注: GCP MySQL慢速日志是通过google代理访问的,并使用单个数据类型LogEntry表示,该数据类型定义了所有日志条目的某些公共数据以及承载单个有效载荷。格式是JSON,每一行日志都封装成单独的JSON对象。示例:https://prnt.sc/sep2zk
当前的问题-- Pub/Sub为实现其高可用性和吞吐量做出了一些权衡,不幸的是,使消息无序是其中之一--换句话说,MySQL慢日志的顺序是混合的,我们不能通过定义每个单独的慢速日志对象以“^#Time”字符串开始来正确封装它--相反,我们有以下格式:https://prnt.sc/seoztj
因此,如果有人共享如何将多行日志文件(或MySQL慢速日志直接)从GCP导出到外部日志分析系统(作为ELK堆栈),那么我们就可以更好地理解在这种情况下什么是最好的方法。
发布于 2020-06-05 21:57:47
这是正确的。酒吧/Sub不保证交货顺序。您可以做的是通过publishTime订购。Pub/Sub文档中有一些样本。
或者,您可以向等式中添加一个Dataflow管道,并让它为您排序数据。然后,您可以根据客户的业务需要运行一个批处理作业。这种方法将需要大量的工作来配置,而且它的成本将大大增加。
我强烈建议您查看上面的一些示例,看看它们是否适合您的需要。
https://serverfault.com/questions/1017731
复制相似问题