基于云原生的电话 SDK 日志收集系统

撰写于 2022年1月14日 修改于 2022年1月14日 分类 编程杂记 标签 Node.js /

部门内的电话 SaaS 业务提供了一个电话 SDK,可以方便有开发能力的客户在自己的系统和软件中集成电话功能。电话作为一种实时通信业务,有很多不同的状态,且涉及电信运营商和集成商,与网络状况、坐席状态、被叫号码状态都有着密切的关系,如果一通电话出现问题,开发同学想要复现难度很大,因此对日志的记录和上限显得尤为重要。电话 SDK 使用了一个自研的日志系统来实现日志上报,帮助开发同学在自己的浏览器上复现问题,利用问题现场的数据来进行断点调试,提升解决问题的效率。我在其中负责将浏览器中的日志提交到日志系统,对日志做一些处理、转换、存储,再提供接口给日志工具查询。

本文摘录自部门公众号 企点电话SDK的日志追踪系统 一文中我编写的部分,

日志的服务端存储和查询

电话 SDK 中的线索日志以还原用户现场为目标,因此日志中除了记录行为操作数据,还需要记录上下文情况,HTTP / Websocket 的请求和响应等等,相对于数据埋点中的日志,电话SDK日志单条长度更长、日志的内容也更多样。在查询日志时,会利用多种条件进行筛选,还需要支持准实时的检索能力。相对来讲,对日志的保存时间要求并不长,几天到几周即可,也没有复杂的聚合和分析需求,日志入库后,一般不会对其进行二次处理和再分析,根据日志的查询需求和空间占用情况,定期进行清理即可。前端收集到日志并提交到日志收集接口后,后续大概会有如下几个步骤:

  • 接口收到日志后,立即返回响应,并将收到的日志推入消息队列
  • 从消息队列中消费消息,对日志进行清洗、数据整理等操作
  • 将整理后的日志持久化
  • 提供日志的实时查询和统计服务,查询需要支持按字段检索和全文检索

日志系统的基本架构

对于常规的日志收集系统,主要可以分为接口层、日志处理层、日志存储层、数据展示层四大部分。

传统日志收集架构

接口层需要考虑日志的高并发、上传量大的特点,在确保接口稳定的前提下,提升接口返回速度,保证日志的完整性。通常情况下,这一层会加入负载均衡系统,根据一定的策略将日志分发给接口层服务,接口层服务一般不处理日志,只将日志转换为统一格式的消息,推入到消息队列。利用消息队列对日志进行缓存和分发,对日志生产进行消峰,只要消息积压不太严重,一般不需要调整接口层服务的数量。

日志处理层中会对日志进行解析,保证日志的结构正确,对于截断或损坏的日志进行单独的记录。由于电话 SDK 会有多个版本,不同版本之间提交的日志会不一样,有的字段的值类型不一样,有的同一字段位于日志 JSON 中的不同位置。都需要在这一步对日志格式化,做一些类型和含义上的转换,补充缺失的字段等。日志处理层通常是从消息队列中订阅和消费消息,进行上述的处理后,将日志存储到日志存储层。

日志存储层提供日志的存储、查询和聚合。一般日志按时间存储,即可便于查询,又能方便管理。例如 Elasticsearch 可以按时间创建索引,查询时可以根据时间来精确查询范围,提升查询的效率,也能方便快捷的删除过期的日志。

数据展示层主要是提供日志的查询接口,有些日志系统还需要 dashboard,提供对日志收集情况、日志本身的统计和分析能力,比如 Kibana 就提供了对 Elasticsearch 中的数据可视化、查询、索引管理、节点状态管理等功能。

日志存储的技术选型

传统的技术选型

根据对日志规模的初步估算,预计每天日志数量在千万级别,空间消耗数十G,对于主流的日志解决方案,基本都能满足需求,以 ELK 方案为例,可以使用 nginx 作为负载均衡,将请求转发到 Kafka 消息队列,用 Logstash 消费消息,处理数据,转存至 Elasticsearch。再构建一个服务,专门从 Elasticsearch 中查询日志。

基于 Nginx / Kafka / ELK 的日志收集构架

基于云原生的技术选型

虽然 ELK + Kafka 的方案可以满足我们的需求,但是这个方案还是需要搭建多个服务,并且可能还涉及到服务的扩容问题。经调研发现,腾讯云提供的云原生生态,也可以实现上述构架的相关功能。

云原生(Cloud+Native)是一套基于云来构建和运行服务的方法、体系、工具和服务,从设计之初就考虑利用云上的各种资源和服务,实现弹性伸缩的分布式架构,云原生代表性的技术包括微服务、容器化、DevOps等。

云原生架构非常适合日志系统。弹性伸缩可以轻松应对日志收集时的波峰问题,消息队列、日志处理、数据存储之间也是典型的分布式架构,利用云上的服务,通过简单的配置即可实现负载均衡、消息队列、数据存储这几大部分,只需要将精力集中在编写日志清洗和处理的代码,后期几乎没有运维成本,利用云原生的监控功能,可以方便的了解系统的整体运行状态。

Serverless Computing 无服务器计算是在 PaaS 的基础之上构建的一种代码执行平台,也叫Function as a Service,函数即服务。对于平台的使用方而言,不需要关注服务器的细节,只需要编写代码块,处理函数的输入和输出,即可直接使用云平台的计算资源。阿里云提供的函数计算,腾讯云和华为云提供的云函数,都是 Serverless 概念的实现。比如腾讯云的云函数服务,提供了一整套的开发工具,在开发环境中就可以直接编写和提交代码到云函数中,支持使用 Node、Python、Go、PHP、Java 编写代码。云函数根据函数的运行时间计费,通过设置最大并发数量,可以提升波峰的处理能力。

云函数本身并不能直接对外提供 http 服务,需要绑定到 API 网关才可以。API 网关可以实现对接口测试、预发布、发布的全生命周期管理,还提供了文档生成、测试、访问日志和监控、流量与权限控制等功能。API 网关本身部署在分布式集群上,可以承载较大的访问量,结合云函数,可以实现弹性伸缩。

借助云上已有的消息队列、Elasticsearch 服务,使用云函数处理请求、转换日志、存储日志,利用 API 网关对外提供日志提交接口,定时触发云函数来管理 Elasticsearch 的索引。

为了保证单个云函数的可维护性,一个云函数一般只完成一个功能,我们需要创建如下几个云函数:

接口云函数

触发方式为 API 网关,处理外部提交的日志,解析出请求中的日志数据,检查日志格式,将日志组合为 Kafka 的消息,并推送到消息队列。API 网关会根据当前接口的请求情况,动态增加云函数的实例数量,直到达到配额上限。

日志处理与转存云函数

触发方式为 Kafka ,当有新消息时会调用云函数,检查消息中的日志数据,根据具体规则进行格式化和转换处理,通过 Elasticsearch 的 API 接口来保存数据,为了提高效率,可以接收多个 Kafka 消息后,再合并多条日志,通过 Elasticsearch 的 Bulk 操作批量存储日志。本云函数在系统中较为重要,当出现日志格式问题、转换发生异常,或者存储出现错误时,可以触发警告。

日志查询云函数

触发方式为 API 网关,供 logViewer 插件日志展示时使用。处理日志的查询,主要是构造 Elasticsearch 的 DML 查询语句,再将结果作为接口响应返回。

Elasticsearch 索引管理云函数

定时触发,通过 Elasticsearch 的接口,查询当前的磁盘占用情况,超过一定比例时,根据索引名字中的时间,删除最早的索引,释放磁盘空间。

基于云原生的日志收集构架

基于云原生的日志收集架构,无需传统的负载均衡,可以自动根据并发数量弹性伸缩计算资源,各服务基本也是按使用情况计费,无需专门的维护人员,通过云平台提供的监控工具,可以直接查看系统的处理情况,能够低成本的满足我们的日志收集需求。

Site by Stiekel using Hexo & Random
© 2010 - 2022

Hide