kibana组件使用环境（日志平台设计脱离kibana）

kibana组件使用环境（日志平台设计脱离kibana）因为我们有专门的数据处理层，所以我们不需要在采集端进行业务的处理，只需要 把日志收集起来。轻量级，占用业务资源少是我们的优先考虑的指标。Logstash 本身有性能和资源消耗过大两个问题，Flume 占用资源比较重，而且占用资源不可控，相对来说也比较重量级，因此，我们选择 Go 语言编写、轻量级的 Filebeat，实践也证明选择的正确性！采集层有三个可选的组件：Filebeat、Flume、Logstash。追求：查询快，低成本。放弃：强一致性、完全精确、高 QPS 查询。2.2 技术选型

一、背景

每日优鲜早期日志系统和监控系统情况比较相似，只有几个业务线有自己的日志系统，并没有推广到公司的级别。已知的交易平台有一套自己的 mlist，搜索组有自己搭建的 EFK，这两个日志系统存在各自的弊端，其余的业务线更是处在一种最原始的状态-直接登录服务器查看日志，随着每日优鲜业务的急速扩张，一个统一的大型日志平台迫在眉睫！

二、架构设计

2.1 核心挑战

1. 性能

• 每日优鲜大促期间，日志写入的峰值大约60w/s，为保证系统的稳定性以及考虑到后续业务的拓展，我们把写入目标设定到了百万级/s，同时根据业务特点，三天内的日志定为热点日志，数量级别300亿左右，我们希望在这个量级上，各维度99%的查询能秒级返回。

1. 稳定性

• 日志疯狂写入超过上限值，保证日志系统稳定运行。
• 日志系统某些组件出现问题，保证最终数据的完整性。
• 连续海量数据查询，ES 不能查崩溃。

1. 成本

• ES 特点，一是快，二是贵。除此之外，日志存储的是海量数据（PB 级别），同时要求保存的时间比较长，因此对存储的要求就比较高。
• 公司正在搞降本提效，因此成本是绕不开的一个话题。

1. 运维管理

• 每日优鲜总的应用400 ，涉及到到服务器3000 ，如果没有一套完整的工具去管理维护，难度是不可想象的。包括：ES 等组件的维护、采集端的维护、接入流程的自动化、应用原数据管理等。

1. 服务跨云部署

• 优鲜业务主要部署 UC 云和 TC 云上，之间网络互通走的专线，如果要实现整个链路的查询，跨云走专线不可避免，但是日志特点之一就是数据量大，我们需要找到一种方式，尽量少的用专线或者高效的用专线带宽，并且不对专线上的其它业务产生影响。

每种方案都不是完美的，系统到达一定的规模，我们就需要根据实际的业务需求做取舍。我们可以分析一下日志的特点：只新增；时间有序；越旧的数据访问越少；写多查询少。

我们根据上述特点做了如下的取舍：

追求：查询快，低成本。

放弃：强一致性、完全精确、高 QPS 查询。

• 强一致性：流量高峰期，允许非核心业务日志延迟进入 ES，保障最终一致性。
• 完全精确：不允许丢失，但是允许少量日志重复，因为这对问题的排查是没有影响的。
• 高 QPS 查询：这是业务特点决定的，如果没有问题，一般很少去查询日志。

2.2 技术选型

1. 采集层

采集层有三个可选的组件：Filebeat、Flume、Logstash。

因为我们有专门的数据处理层，所以我们不需要在采集端进行业务的处理，只需要 把日志收集起来。轻量级，占用业务资源少是我们的优先考虑的指标。Logstash 本身有性能和资源消耗过大两个问题，Flume 占用资源比较重，而且占用资源不可控，相对来说也比较重量级，因此，我们选择 Go 语言编写、轻量级的 Filebeat，实践也证明选择的正确性！

1. 缓冲层

像每日优鲜这种电商平台，类似于双11的大促或者抢购活动总是不可避免的，这样的场景下，日志量会瞬间激增，对于整个日志平台的冲击会非常大，如果有一层缓冲层，就可以在常规的资源下处理掉激增的日志，在实时性和资源方面做一个平衡。

日志场景下，百万吞吐的 Kafka 是首选，RocketMQ 也是一个选项，但是它更适合交易等敏感业务场景，相同资源配置的情况下，吞吐量要比 Kafka 小很多。

1. 存储层

公司有很多的业务 ES 集群，本身有运维的经验，而且业界最通用的方案就是 ES，因此我们选择了ES。

1. 数据处理层

数据处理层主要是两个实时分布式实时计算框架的对比：Storm 和 Flink。

因为老的监控系统就是用的 Storm 处理数据，因此Storm 成了我们的选项之一。

最后经过权衡后，最后选择Flink，有以下几个原因：一是Flink 性能要比 Storm 好，Flink 吞吐量基本是 Storm 的5倍；二是Flink是流式架构，更契合日志场景；三是 Flink 是近期备受关注的新型框架；四是为了日志平台融入更多新的技术，尤其是弥补ES在统计方面的不足。

1. 可视化

Kibana 作为 ELK 的数据展示层，是可选的一个组件，但是 Kibana 有几个弊端绕不开：

• 莫名其妙的界面，例如：不熟悉 Kibana 的同学，估计都不知道 Discover 是查询的。
• 查询界面过于复杂。
• 功能单一：不能支持链路查询；不支持实时日志。
• 性能没法优化：因为是现成的产品，没法对查询进行优化，经常造成查询超时。

因此我们开发了自己的可视化日志查询平台。

2.3 架构设计

|

1. 核心流程：Filebeat 采集数据发到Kafka存储，Flink 实时处理Kafka 消息，存储到ES，日志查询平台直接查询 ES 集群，ES 中历史数据会定时存储到对象存储。
2. 日志的接入下放到业务，业务直接通过工单系统可自动接入。MAX 发布系统中的应用扩容以及重新部署Filebeat 等，都可以通过 Ansible 任务管理平台自动化部署。
3. 应用日志的原信息（日志路径、热点数据保存时间等）通过管理平台保存，索引的创建和删除根据原信息定时新增和删除。Pinpoint 中的链路信息也会同步到管理平台，作为链路查询关联应用的依据。

2.4 难点实现

1. 百万/秒的写入速度：核心是调优ES

• 云 SSD：性能是普通磁盘的10倍；而且本身支持数据备份。
• 不同应用，不同索引：索引越大，写入性能越差，通过增加索引数量来提高写入性能。
• ES DOC 自动生成 id：日志没有更新操作，ES 自动生成 id，可避免写入时的查询操作，极大提高写入性能。
• 异步落盘：如果宕机，是有丢失数据的风险。我们采取乐观的方式，宕机允许丢数据，通过其他手段修复数据而不是保障写入的数据不丢失。

1. 百亿数据秒级查询

• 主要解决思路有两个：
• 减少筛选的数量级。
• 减少不必要的操作。
• 下图是链路查询的原理：

1. 数据延迟控制

• 不同应用，不同的延迟时间：低延迟对 ES 写入影响非常大的，将会耗费更多的资源，根据业务特点，核心应用保证秒级入 ES，B端应用或者大的任务系统分钟级别如 ES。

1. 成本的控制

• 按需接入。
• 应用日志保证7天可实时查询，相应的对本地日志存储要求降低，通过降低创建机器的磁盘容量来控制成本。
• 实时写入非压缩，稳定的热点数据压缩：实时写入的日志采用非压缩策略，来提高 CPU 的利用率，对于当天之前的热点日志，采取段合并和压缩的策略来压缩日志提高磁盘的使用率。压缩后日志大小为原来的70%左右。
• 历史数据入对象存储：历史数据保存30天，如果全部存入磁盘的话，磁盘存储的费用也是扛不住的。我们会把最不活跃的历史数据放入对象存储，好处是对象存储要比磁盘便宜的多得多，缺点是不能查询，但这也正好符合日志的特点，历史数据查询非常少，当需要查询时，对象存储的数据恢复到 ES 进行查询。

1. 管理的自动化

• 提高配置，降低机器数量。
• 接入的自动化：通过工单接入日志，同时元信息采集下放到业务方。
• 扩容的自动化：MAX 发布系统支持自动扩容，通过 Ansible 任务管理平台自动部署。
• 监控报警：Filebeat、Kafka、Flink、ES 全部接入监控报警平台。

1. 跨云的实现

• 根据日志特点：查少写多。数据流转及写入落盘在自己的云上（不占用专线带宽），查询走专线（查询少占用的专线带宽少）。
• UC 建立主集群、TC 集群建立副集群，因为公司大部分应用在 UC 上，这样查询时只有小部分 TC 数据走专线。

1. 稳定性保障

• 大流量写入：根据应用级别，暂停日志收集，流量低峰期重新从原来的点收集。
• 超大数据集查询：时间范围跨度限制，链路层级限制，通过滚动方式查询而不是直接全量查询。

1. 单机热点

每个应用每天有三种类型日志（wf/log/info），会对应 ES 的三个索引，因此集群中会有几千个索引，ES 本身的平衡策略是根据索引数量平衡，但是每个索引的写入量差别很大，因此就会出现某台机器写入量超高的情况。

我们的解决方案是：把ES集群划分逻辑集群，把大索引固定在某个逻辑集群，做到隔离和性能的平衡。

三、平台特色

1. 链路日志

全链路日志：通过 requestId 或者 traceId，我们可以把一个请求经过的所有模块的日志都打印出来，当有问题的时，我们可以快速定位到异常的模块。

1. 上下文日志

上下文日志：某应用中一次请求的全部日志，可以按照时间排序，能看到一次请求在本模块完整的生命周期，对于定位问题点帮助很大。

|

1. 前后日志

当我们定位到一条日志后，我们需要看这条日志周围的日志信息，看看有没有相关性，协助我们定位问题原因。

1. 实时日志

1. 日志下载

有时我们可能需要把日志下载下来更精确的分析，平台提供了下载日志功能，后续将提供更加灵活的日志下载格式。

1. 日志订阅。

为自动化测试平台提供海量真实数据，节省测试成本，提高服务质量。

1. 快捷方便的使用方式：所见即所想

• 降低使用难度：不用关心 DSL 语法，所有的参数界面表单化。
• 快捷查询：可以把查询条件保存，下次查询直接选择筛选条件即可。
• 一键复制功能：直接点击复制按钮，就能完成复制功能。
• IP 筛选：可灵活选择 IP，排除 IP。
• 便捷的时间选择快捷按钮

四、现状

五、未来规划

5.1 容器化

随着公司服务容器化的进行，日志平台将成为唯一查询日志的入口！这对日志稳定性提出了更大的挑战，如果日志缺失，因为没有了本地文件可查询，极有可能会导致业务出现问题的时候无法排查。

1. 避免容器切换日志的丢失。
2. 在容器内应用日志中体现容器信息。
3. 采集器的稳定性、隔离性、可监控。

5.2 全日志平台

日志平台后续会有两个重点方向：

1. 收集更多的数据源
2. 日志信息的挖掘

除了业务数据外，日志作为另一个维度的数据来源，其中包含珍贵的信息，需要我们更深入的挖掘，发现更大的价值。