云原生是实现可观测平台的唯一出路？码农：夸张了

一、可观测性发展

1、单体应用 - 手动日志排查

单个应用承载复杂逻辑，应用实例数量有限，本地Debug可以解决大部分问题。

2、分布式服务 - 基础指标+日志检索

业务逻辑模块化拆分，节点数量依然可控，简单节点指标检查和架构自带调用链可以满足诉求。日志检索问题初现。

3、容器化微服务 - Prometheus+ELK+Tracing

服务部署容器化，节点数量无法手动管理。K8s控制面+Prometheus成为标配，ELK协助日志汇聚，检索。Tracing诉求强烈，OpenTracing&OpenTelemetry出现。

4、无服务/网格 - Metric+logging+Tracing

运行时虚拟化，应用架构层次增多。复杂架构直接影响故障排查速度。

二、传统的日志架构

1. 后台⽇志：对异常uid进⾏染⾊，全量存储后台⽇志
2. 客户端⽇志：通过tcp长连接，捞取客户端⽇志
3. 单机⽇志->远程⽇志->染⾊⽇志
   
   对于日志，开始的时候我们单体应用是够用的，随着我们腾讯的一些业务的发展，其实我们逐渐的单机的话其实是查询起来是非常麻烦的，所以我们有了远程日志，然后有了远程日志的话，因为我们后台server在逐渐的增多，和远程日志也会数据量会非常的庞大，所以统计内部以前会有一个根据比如跟QQ号或者根据微信号uid进行染色的这样一种能力，来去减少我们后台就是这样一个量级。
   日志就是我们最常用的东西，但是它是一个非结构化的，不是我们没有办法去对日志去做一些指标，做一些告警的这样一种检测。所以说我们从日志里面去提取信息，我们得到了两个新的概念，抽象出了两个新的概念，一个叫指标，一个叫维度。
   维度的话其实比如说对于某台虚拟机，对于某个MySQL实力，它是一个维度组合，它是不会变的一个东西，比如说AP ID是什么，它的IP是什么？它的地域是什么？它的可用区是什么？
   然后指标的话，比如说像这里的错误数，比如说像CPU它是一个动态变化的，然后逐渐的衍生我们从日资这种完全无序的无结构化的数据里面去得到了这样一种从指标跟维度这样两种概念，然后我们抽象出了这样的概念之后，我们能够对它进行做更多的事情。同时因为指标它是一种结构化的数据，它能够更有效的去表示信息，让也能够给予与开发者一些规范，能够去上报更有效的一些数据，而且它是有一个聚合的特性，我们可以把数据聚合成。
   在单体时代的一种查问题的一种逻辑，就是我们先去配置这样的一个成功率的告警，然后当它出问题的时候他会发消息给我们，然后我们通过我们先去看他们有没有IP聚集，然后如果说它有IP，比如说是某个IP，因为以前是虚拟机时期，某个IP某个虚拟机出问题，它可能会聚集在这个Ip，然后这个时候把它先踢掉，然后先恢复服务就好了。
   如果说没有的话，我们再继续去通过它的反馈，然后到我们的详细的日志里面去查询，所以这个时候其实我们的指标跟日志已经是在做一个有机的结合，能够去查询一些问题的，然后逐渐的继续发展。

三、K8s架构

我们逐渐我们来到了容器时代，来了微服务来到了微服务时代，K8s架构给我们带来了很多很好的功能，比如说负载均衡，比如说我们的弹性可伸缩的能力，但是它其实本质上在我们整个的一个架构中间加了一层。
我个人认为K8s给我们开发者就是最大的一个关键点，就是它抽象出了Pod的这样一个概念。我们以前都是把服务部署在虚拟机上或者是物理机上面，现在我们的服务都是部署在一个个的Pod之上，Pod变成了一个逻辑性的概念，它并不是绑定到某一台机器，如果你的服务CPU消耗很大，或者说内存消耗很大，它可以去调度到比如说资源更大的这样的一个Pod的这样一个节点机器上面去，他提供了这样的一种很灵活的一种调度能力。
由于中间多个一层，给我们的监控给带来了一个比较大的挑战，也是随着k8s的这样的一种能去调度这样一种去编排一种架构的一种盛行的话，我们现在特别多的业务都是在微服务化，一个请求它会经过几十个服务生上百个，你还是通过这种单点的方式，其实没有办法去快速的定位到问题。
所以这个时候其实催生就应运而生的，我们有一个确实ID这样的一个唯一ID的东西，能够去把我们的不同的节点不同的服务之间给串起来。
我们有了这样一个东西，我们就能够画出一个拓扑图，能够很快的去能够看到到底哪里在出问题。
这就是我们微服务的我们K8s架构的发展，然后给我们监控带来的挑战，然后也是我们的推进的一个凸现，然后我也给我们带来了一些应对这样的复杂架构的一些可观测，然后去定位问题一种能力。

四、云原生应用的特点

1、效率要求越来越高

随着DevOps模式的普及，规划、开发、测试、交付的效率越来越⾼。

2、系统更加复杂

架构从开始的⼀体化到分层模式，再到现在的微服务架构模式。

3、环境动态性增强

容器化的部署模式动态性增强，每个实例的⽣命周期变得更短。

4、上下游依赖更多

云原⽣应⽤依赖云上的各类产品，上下游变得更多。

五、单体应用时代的问题定位

首先是我们的单体应用时代，通过指标，然后通过日志去解决问题，我们通过把非结构化的日志给抽象成了指标，然后我们能够去能够去产生一种告警，但其实大家仔细去想这个关系，我们的日志跟指标其实是串不起来的，很多时候我们是这样子去处理问题的，比如说我们收到一个指标的告警，比如说是一台机器的CPU的告警，或者是一个错误率的告警，这个时候一般我们开发者是怎么做的，其实大多数都是这样子，我们先去拿到对应的，比如说拿了一个apid或拿了一个uid这样的一种标识用户的信息，然后再拿到他的时间戳，然后可能再拿到返回码，可能还有一些比如说像一些什么接口名称，像一些应用名称等等这样的信息，我们拿了之后，我们再去到日志里面去搜索，我们去看这个时间段内用户他调用了这些接口，然后我们要一个个的把它们串起来，这个时候我们有日志有指标，但其实说实话它本质上他们是串不起来的，他们是在完全独立的去做一些事情。

当我们收到一个指标的告知，我们可以去点开任何一条链路，发现有问题的一个链路，然后确实ID能够去注入到这样一个日志里面去，这个时候我们就能够去把确实把tracing ID，然后将max跟log连给关联起来，这个时候其实我们就能够以一个比较快速的方式去定位我们的问题，就能够以一个远远高于以前的一种问题定位的效率去解决我们的日常的问题。

六、应用的可观测性

1、指标

衡量应⽤系统当前的状态，信息量少，可通过添加维度来添加额外信息，相同维度之间的指标可聚合（累加、平均），通过指标告警可以快速发现异常。

2、链路

⼀个请求从接收到处理完毕整个⽣命周期跟踪路径，相⽐指标多了请求相关的信息，通过排查链路可以快速定位问题。

3、⽇志

应⽤运⾏产⽣的事件或程序执⾏过程中产⽣的⽇志数据，可以详细的解释系统运⾏的过程，通过应⽤的⽇志来排除故障⽇志。

七、可观测一体化

应用层的统一可视化，多维分析告警等等这样的通用的能力，到我们的各个应用的场景，比如说我们的压测，然后从前端的一个视角的监控，从偏后台的一个视角的监控，尽可能的让用户以最小的成本最小的门槛去使用，不管是开源的监控产品，还是说各个云厂商的一个监控产品，因为协议是统一的，使用方式大概是统一的，所以能够在各个云厂商或者是开源项目之间能够很灵活的切换，谁的体验做得好就用谁的。

八、基础资源监控与告警

基础资源的一个监控跟告警，比如说像CPU使用率，像内存使用率这样的一些监控的告警，这些都是可观测平台技术中需要关注的关键点。

1、前端监控

从前端的视角，我们的监控的话，最重要的指标要一个手屏渲染时间，不管是在web端还是小程序端还是安卓端，因为之前c端有一个理论，我记得是比如说你的一个响应时间里，你比如说增多一一秒，然后你整个的一个用户的停留的几率的话，其实你会降低50%以上，所以这个指标是非常重要的。

2、后台监控

从后台接口的一个可能性分析，也就是刚刚我们提到的我们指标与日志的一个打通，其实再去抽象这个过程指标，确实我们的日志其实是一个宏观到微观的一个过程，也就是我为什么在这里强调是从指标到trace到日志，其实日志是最全的，日志是一个很详细的东西，因为日志太多了，查询起来会很复杂，而指标跟链路是一个从宏观到微观的过程，从指标的告警，到我们的链路的情况，这是一个很自然的过程，然后再去查日志，整体上我们通过这样的方式也能够去提高我们的一个定位问题的效率，而不是我们从很传统的一上来我们有任何问题，我们就直接去看日志。

3、服务治理

我们能够去绘制出我们整个服务的一个调用的拓扑图，不管是团队的技术负责人，或者是产品的负责人，其实看到右上角这样的这么凌乱的一个炒股图，就是你不会对你自己的自家的一个产品是有信心的，还是可以通过服务治理的手段，我们去捋清楚上下游的一个关系，然后能够去逐渐的把一些没有关系的微服务去掉，比如说像右上角的图，它这里有个四方形的这样一个拓扑的调用，其实就是一个非常奇怪的情况，我们能够绘制出这样的一个科普图的话，其实也能够让我们很容易的就能够发现我们的工作重点，再通过我们的分析，然后去把这样的一个拓扑图再进行一个微服务的架构治理。

九、整体架构

然后下面介绍一下整体架构，整体架构分三分为三层，第一层是我们的输入层，第二层是我们的中台的一个处理的数据处理层，第三层是我们的上层的一个应用层。然后从输入层的话，我们的数据其实分为两块，一块是我们的日志，另一块是指标的数据，指标的数据会通过我们的流处理进行一个聚合，日志的数据我们可以根据情况来看是否需要对它进行处理，比如说计算一些上下游的关系等等。

十、可观测实践

1. 单独集群做⾃监控—异地容灾
2. ⽹络调⽤RPC/http调⽤指标+合理告警—⽆侵⼊探针(APM/RUM)
3. Mysql，redis，es等存储相关调⽤告警—⽆侵⼊探针(APM)
4. 重点关注数据⼀致性相关问题的告警—业务指标埋点(prometheus)
5. ⽇志类数据通过中间件打印清楚上下⽂信息(⽐如appid，ip，返回码等等)
6. 重视从业务场景的拨测—持续集成测试(CAT)
7. 确保告警的有效性和数量限制
8. 通过压测去观测以上数据的情况

上一篇：Java学习路线总结，搬砖工逆袭Java架构师

下一篇：docker是干什么的，docker常用命令每日一练