共计 2641 个字符，预计需要花费 7 分钟才能阅读完成。
导语 | 鹰眼是由腾讯 PCG 技术运营部负责的海量级分布式实时监控和日志剖析零碎，为响应公司策略要求，将原先的业务迁徙上云，最终产生了可喜的变动。本文将介绍分布式日志零碎（鹰眼）的整体上云计划，心愿与大家一起交换。
一、鹰眼平台介绍
鹰眼是由 PCG 技术运营部负责的海量级分布式实时监控和日志剖析零碎，反对多语言的上报，域名为：_http://log2.oa.com/_
鹰眼的数据上报是通过 ATTA 提供的，ATTA 反对多语言的上报（JAVA，Python，C++ 等），上报之后，鹰眼从 ATTA 零碎拉取数据最终写入到 ES，通过 ES 的倒排索引机制，疾速查问性能，写入性能等。
应用 ES 的倒排索引机制，百亿数据秒级查问返回的能力，鹰眼提供了以下性能：
1. 实时日志查问服务数据
实时日志查问服务数据上报到 ATTA 之后，开发能够通过鹰眼及时查问到日志，定位问题，运维能够通过鹰眼提供的数据统计界面实时查问到业务的运行状况。
2. 数据分析能力
鹰眼数据入库后，用户能够通过 API 间接调用，进行 OLAP 剖析。
3. 谬误日志告警服务
程序如果呈现谬误之后，能够依照鹰眼标准来上报谬误日志，鹰眼进行分词，依据不同的错误码进行分钟级别的告警。
4. grafana 实时剖析告警
通过 grafana 对上报到鹰眼的数据进行实时的剖析告警。（因为 ES 不反对大并发查问，所以无奈对超大数据进行实时剖析）
二、上云的背景
公司策略调整，成立新的云事业群，外部成立“技术委员会”，启动“开源协同”和“业务上云”的两大策略方向。
在架构演进中，鹰眼团队上云能失去什么益处？上云的价值是什么？
1. 业务价值
- 聚焦业务，晋升研发效率；
- 放慢技术换代，放弃技术劣势（传统互联网 vs 云时代）；
- 应用更好的云开源组件服务（可用性、稳定性、文档 API…）；
- 计算资源重用，弹性伸缩，优化老本；
- 标准化 CI/CD 流程。
2. 工程师价值
- 扩宽技术视线，防止闭门造车；
- 把握的技能更有价值；
- 输入优良组件到云，进步影响力。
3. 腾讯云价值
- 为客户输入业务上云教训；
- 帮忙腾讯云打磨云组件。
三、组件上云架构选型
为了保障业务的延续性和架构的演进，数据导入过程中的主体流程并没有太大扭转，Kafka 间接应用到云上的 CKAFKA，ES 间接应用到云上的 ES。
ES 和 Kafka 间接应用云上组件，其余组件须要进行重构。
1. 重构 LogSender
生产者程序写入 Kafka 性能瓶颈特地大，高峰期丢数据特地重大。
生产者程序写数据流程：读取 BOSS 订阅 ->IP 解析 -> 写入 Kafka。
（1）IP 解析性能瓶颈
之前生产者程序是 C ++ 版本，通过打印日志，发现高峰期 IP 解析耗时特地重大。排查代码，发现 IP 解析加锁了。所以高峰期丢数据特地重大。解决办法是：将 IP 解析改为二分查找算法来进行 IP 定位，而后勾销锁，解决。
（2）Kafka 性能瓶颈问题
因为咱们生产者程序，一个程序会读取很多很多个 topic，而后写入到 Kafka，咱们尝试，应用一个 producer 和多个 producer 发送，性能都晋升不起来。
通过源代码排查，发现 Kafka 发送时，会依据 topic 分区来锁队列，当这个队列满的时候，就会发送一批音讯进来。所以解决方案为，每个 BOSSID 应该有独立的发送客户端。
- 数据量大的，有多个 Kafka 客户端
- 数据量小的一批 topic，能够共用一个 kafka 生产者。
优化之后：在数据量十分大的时候，因为程序性能起因，会导致一分钟单节点最多只能解决 13 万条左右的数据。改良后，单节点能解决 55w 条左右的数据。性能晋升 4 倍。
2. Kafka 选型
Kafka 整体来说，高版本比低版本反对的性能更多，如事务，磁盘间的数据转移等，写入性能并不会降落。此处选型选的是最高版本。
当然 CKAFKA 并没有给咱们抉择版本的机会，客户端写入的时候还是得留神下和 Kafka 服务端版本统一，防止不必要的问题。
如低版本的客户端写入高版本的 Kafka 时，如果应用数据压缩，则服务端承受到数据后，会进行解压，而后再依照对应的格局压缩（如果版本统一，则不会有此动作），减少服务端的运行老本。
Kafka 上云之后，单机性能能达到 400MB/s，而咱们自建的 Kafka，单机性能最多达到 100MB/s，性能晋升 4 倍。
3. 重构 Hangout
ES 写入局部，业界有很多组件，最闻名的是 Logstach，因为性能不够，咱们本人从新开发了一套读取 Kafka 写入 ES 的组件。
外围优化点如下所示：
因为磁盘 IO 的大幅缩小，能在极限优化下持续晋升性能 2 倍以上。整体来说，ES 写入晋升性能 6 倍左右。
4. ES 选型
ES 低版本反对 TCP 写入和 HTTP 写入两种形式，高版本只反对一种 HTTP 写入形式。实测发现有如下区别：
- TCP 写入比 HTTP 更快；
- HTTP 写入更稳固一点，TCP 写入是间接写到节点下面的，容易呈现负载不平衡，HTTP 更容易通过数据节点节点进行负载平衡。
因而咱们采纳了云版本 ES 6.8.2。
上云之后的成果：
- 均匀写入 1TB 数据，云下须要 80 核，256G 内存 12TB 磁盘（BX1 机型）；
- 云上须要 3 *（16 核 64GB 5TB 硬盘）；
- 均匀节俭资源 1 倍左右。
四、上云之后的变动
ES/Kafka 上云之后，统计有 50 多个 ES 集群，12 个 Kafka 集群.
1. 工作量的缩小
如果不上云的话，搭建这些集群均匀一个 ES 集群须要 20 台机器，从申请机器，到机器初始化，磁盘 RAID，装置 ES，均匀每个 ES 须要 3 - 4 人 / 天，则搭建老本就曾经须要 200 多人 (62*3-4)/ 天了，还没有谈到集群运维老本，远远超过鹰眼团队的人力。
2. 老本的缩小
上云之后，随同着各个组件的优化，整体性能晋升至多 2 - 3 倍，所须要的资源同比会缩小 2 - 3 倍、每年节省成本至多 2kw。
3. 工作更加聚焦
上云之后：
- 鹰眼聚焦于写入性能优化，大大晋升了写入效率；
- 监控体系的建设，数据上报到 ATTA 之后，就进行数据对账，及时发现数据的提早给出告警；
- 在新性能开发上，基于 ES 反对隔天查问，如果当日数据暴涨之后，通过建设备份索引的机制增大写入量。
五、后续架构演进
1. 监控体系建设
外围模块既要有日志，也要有监控，不同模块的监控维度对应起来，让外围的模块，日志和监控都有，当业务出现异常时，及时调出产生异样的根底数据（如 CPU/Mem 等），指标数据，日志数据等进行残缺的监控体系的建设。
2. 架构继续降级
目前自研 Hangout 写入只能保障 at least once，然而无奈保障 exactly once。尝试通过 flink 的 checkpoint 机制，保障数据链路的完整性。