京东如何建设基于云原生架构的监控-日志系统？
随着云计算的发展，我们发现很多系统都是基于云原生架构构建的，监控系统也不例外。云原生架构监控系统与传统架构监控系统到底有什么不同？韩超表示：“这两者的本质区别是云原生架构监控系统需要以 Cloud Native 的方式来进行部署运维。”
Cloud Native 是一个发展中的体系，简单来说，云原生架构需要融入 kuberneters 体系，让 Monitoring、Logging、Tracing 几大功能，按照 Cloud Native 的方式运作。从系统（kuberneters 或 PaaS）的视角来看，云原生架构的监控需要是一个标准的东西，而非把系统改得“七零八落“；从应用的视角来看，云原生架构的监控需要与系统融为一体，接入方式不能太复杂。
传统架构的监控系统与云原生架构的功能目标大致是相同的，但细节的把握不同，后者可以视为前者的“进阶“。当然，两种监控系统面临的挑战也各有不同。
传统架构的监控系统中，主要是面临多、快、好、省四个方面的挑战：
多：监控系统需要运作于数万主机、百万应用的环境中，而且开发、运维的负责度要做到 O(1)。
快：监控系统要随着主机、应用快速部署完成。一台主机交付上线，有没有监控的部署速度应该是相同的；一组应用交付上线，配套的监控应当同步具备；
好：监控的时效性、稳定性要强于应用。监控是应用的保障，发现问题的准确率、召回率是监控系统的关键指标。
省：监控系统需要省资源，监控的 CPU、Memory 开销是监控的关键指标。
而基于云原生架构的监控系统，其挑战大多是来自于 Cloud Native 模式本身，主要包括：
Cloud Native 体系本身就有快速部署、自动扩缩等功能，既然应用具有这种特性，那么监控系统也需要具备同类特性；
在云原生的 PaaS 中，Kuberneters 与应用层都是标准的，监控系统作为介于二者之间的部分，“采集端侵入“的危害会更加严重；
云原生秉承有标准化、自动化的核心理念，但是大型系统往往需要做“极限优化”，要满足标准化、自动化的“极限优化”，挑战就更大了。
最初，京东的应用程序全部都部署在物理机器上。这种部署方式不仅造成了物理机器资源的严重浪费，而且调度缺乏灵活性。由于物理机器的故障，应用程序迁移的时间要花数小时，无法实现自动扩展。
为了解决这些问题，京东从 2014 年开始尝试使用 Docker，并基于 OpenStack + Novadocker 架构创建了第一代容器引擎平台：JDOS1.0。此后，所有应用程序在容器里面运行，而不是在物理机器里面运行。其中，一个 OpenStack 分布式容器集群中最多有 10000 个计算节点，至少也有 4000 个计算节点。
2016 年，JDOS 1.0 的容器规模由 2000 个扩大到 100000 后，京东推出了新的容器引擎平台 JDOS 2.0，京东商城的“应用体系”从 OpenStack 切换到 Kubernetes。
JDOS 2.0 的平台架构
京东商城基础架构的 JDOS2.0 已经非常接近“云原生标准“，京东云原生监控 - 日志系统的发展和建设，与之同步。该系统的核心组成主要包括采集端、接入代理、存储模块、计算模块、服务控制中心、报警等。
最核心的底层是京东商场基础架构自研的存储模块；
中层则是其它各个核心模块，采用积木式可以进行排列组合；
在核心的监控 - 日志系统之上是基于 API 的扩展能力，比如业务定制扩展、AIOps 扩展等。
京东云原生监控 - 日志系统各模块之间也是以服务化的方式进行联系，看起来就像是普通的应用。其中采集端比较特殊，因为它要放到 Node 环境中，并且要求每机一个。这是所有监控 - 日志系统都绕不过去的事情，京东将其做成 K8s 的标准化组件，做到了“低侵入性“。
京东监控 - 日志系统本质上都是标准的 K8s 组件，与京东容器平台 JDOS 关系密切。
在 K8s 的视角，监控 - 日志系统是 DaemonSet、RS 的各个 Pod，并非改了系统。
在 JDOS 容器平台的视角，监控 - 日志系统可以视为 JDOS 容器平台的一个“插件“，并非强耦合。
从应用的视角来，监控 - 日志系统是一个“无需感知“的机制，例如上线无依赖。
大型系统建设升级的挑战大多来自上线，上线类似于“在开车的过程中加零件”，需要保证各种稳定性。京东监控 - 日志系统也不例外，在上线的过程中，新、老系统采用“临时冗余化“、双写并行运行的模式，解决了平滑切换的问题。同时，小流量机制，也解决了占用 double 机器资源的问题。
另外，监控 - 日志系统上线常常会遇到由于“强侵入性“导致的上线顺序左右为难的问题。因此，京东监控 - 日志系统在设计之初就避免了这种问题。
报警在整个监控系统中是一个定制化极强、需求极强的模块，一般来说报警包括两个层面的东西，一是短信、邮件、IM 等通道，二是报警规则的设置引擎。
京东商城的 app 监控系统采用了极其灵活的报警规则机制，规则的设置在于使用者，而不在于监控系统的开发运维。这种设计给了各个业务开发“自我平衡“的机会，在运作的过程中，将报警的量、级别调整到比较合理的状态。同时，报警多了容易发生召回率高、准确率低；报警少了容易召回率高、准确率低。虽然这两点永远是矛盾的，但京东在技术层面也做了一些小的优化，比如自动合并、调整时间轴等。
在韩超看来，目前京东商城的监控 - 日志系统最大的亮点在于：架构灵活 + 与时俱进。架构灵活是空间维度的概念，包括对标架构、拓扑关系、部署方式三个方面；与时俱进是时间维度的概念，包括维护成本、演进模式、技术发展三个方面。
当然，该系统也还有很多值得优化的地方，在韩超看来京东监控 - 日志系统应该优化的地方也是很多大型系统架构层面的固有问题。
多集群、多地域：整体架构超越了 K8s 集群的定义，监控 - 日志系统也需要进行应有的改变；
整个系统的监控对象其实既有普通 App，也有数据库、缓存、队列等中间件，这里面需要整合，才能让每个业务的开发者更能感受到 Serverless 的优势；
京东商城基础架构自研的 baudtime、baudlog 已经在很大程度上节省了存储资源，如果权衡读、写能力，仍有成本优化空间，查询体验也可以对标更好的 ELK。
韩超，技术栈全面、技术底蕴深厚的跨领域架构师，曾经是中国大陆嵌入式 Linux 的先行者，从事移动多媒体、Linux 平台、互联网架构等工作，当前主要技术方向是分布式基础架构。曾任 Motorola 资深工程师、Intel-WindRiver MTS、百度主任架构师，现任京东架构师。
QCon 全球软件开发大会（北京站）2021 官方讲师招募通道已经正式开启，如果您有一个优质的话题并乐于分享交流，点击【阅读原文】提交吧！期待你的精彩分享。
今日推荐文章
点个在看少个 bug 👇