去哪儿网MySQL日志分析实践，80%数据丢失都给你救回来 _MySQL日志

一、背景

日志记录了一个系统的行为，对于了解系统、诊断问题、辅助审计等都有极其重要的作用。通常最近一段时间的日志访问频率是最高的，我们通过聚合日志，分析日志、汇总数据，帮助开发、运维、DBA了解业务的状态和行为。这次实践是针对MySQL的抓包日志进行分析，当前系统不足以支持新的需求，需要重构一套日志分析系统。

文章插图

【去哪儿网MySQL日志分析实践，80%数据丢失都给你救回来】现有抓包系统是将 MySQL 请求的所有 SQL 语句抓取并分析之后写入到 Clickhouse 中，数据可以用来分析数据库的操作。可以查找当前实例、库、表有多少 AppCode 在访问、数据库资源是否可以回收、辅助审计等功能。

Sniffer 抓包之后将数据写入到 Kafka 中，Clickhouse 直接消费 Kafka 的队列中数据，并将数据 merge 到 Clickhouse 中。由 Server 程序按照天级别定时读取 Clickhouse 中的数据，分析、汇总数据，并解析请求 IP 对应的服务信息等，最后将结果写入到 MySQL 中。

当前数据为日志数据，允许少部分丢失或重复，Kafka 队列中的数据约有 133w/s(单个队列最多 33W)，MySQL 中存储的结果数据规模大约在 4.6T 左右。

二、名词解释

AppCode

服务的名称，是一个服务的基本属性。

Clickhouse

一个用于联机分析(OLAP)的列式数据库。

Kafka

一个高性能的分布式队列服务。

Zookeeper

一个分布式的开源协调服务。

扩展性

在业务量上涨时，服务通过较低的代价就可以满足对业务量上涨的需求。

聚合比

将 N 条数据按照同一纬度聚合为 M 条数据，M 一定小于等于 N 。聚合比 = 聚合之后的数据条数/聚合之前的数据条数。

三、现状分析

1、消费能力不足导致数据丢失

Clickhouse 消费 Kafka 队列中的数据能力不足，延迟较高。并且 Kafka 中的数据只保留 3 个小时，根据测试四个节点 Clickhouse 消费的 Kafka 队列中的数据，约有 80% 的数据丢失，导致数据不完整。

2、服务信息计算不准确

Server 是天级别计算请求的服务信息。由于服务已经上云部署，单个服务的 IP 变动非常频繁，导致 Server 获取到服务信息有延迟(最高延迟 24 小时)，甚至很多计算的结果是错误的。这导致部分场景下分析出来的数据完全不可信。

3、汇总数据较少

当前只汇总了四个维度的请求数据，并且只有天级别的数据，粒度较大，无法下钻查询具体信息，展示的维度和明细信息较少。

4、服务监控&可用性

Server 节点目前只有一个，缺乏可用性并没有详细的监控信息。

四、需求

针对当前服务的不足，设计一套服务需要满足当前日志计算性能和业务需求，并且具备较好的扩展性。

五、目标

1、高性能、高扩展性、高可用

服务需要具备以下特性：

1）高性能

在有限资源的情况下，尽可能提高数据消费、聚合能力，降低数据丢失的概率，降低数据入库的延迟。

2）高可用

单个或多个节点出现问题时，不影响服务整体的可用性。

3）高扩展

在未来业务日志体量进一步增长时，仅通过增加部署节点或者修改配置，就可以满足增长的需求，无需额外的工作。

2、降低计算请求业务信息的延迟

从请求 IP 到获取服务信息的延迟降低在 1min 以内，确保 99.9% 的准确性。

3、更多维度汇总数据和下钻查询

支持更多维度的汇总信息查询，以及支持部分场景下的下钻查询。

4、监控

提供多种监控数据，方便展示服务情况，根据监控即可以方便定位到问题。

六、分析

当前 Clickhouse 消费能力不足可以通过扩展节点和调优参数进一步解决，但是服务信息计算是 Clickhouse 做不到的，并且 OLAP 类型的数据库对数据更新并不是太友好，尤其是大规模的更新。如果要解决【降低计算请求业务信息的延迟】这个问题可以有两个解决方案：