开发者学堂课程【开源 Elasticsearch技术训练营：剖析全观测底层原理】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/898/detail/14314
剖析全观测底层原理
内容简介：
一. 监控和可观察区别
二. 如何实现可观测
三. IT运维发展方向
四. 什么叫全观测
五、技术生态
六. 实现全观测的主要流程
一、监控和可观察区别
全观和监控的其实是有很大的区别，在这边这张图上其实，他列出了一个这个区别，。那么其实从监控的角度来看。其实往往我们是部署了这个数据采集，以后其实主要是涵盖的最上面的这里。主要是高级。一个系统的这个状况的概括。，所以他从信号总量上来讲，其实他是比较小。
监控的话，往往我们看到的是他的一个。各种各样的这个状态。但是呢，当我们出现各种故障以后。其实我们就后续要进入到排错。然后分析各种性能。
然后更重要的是分析各种这个依赖。所以其实从可观测的这个角度来讲。他要获得的这个信号总量的程度再来，要远远大于我们传统的这个监控和告。
而且一层一层去这个地方的，其实他获得的这个数据。是会越来越多，往往拿到一个监控之后，其实并不知道我的系统究竟发生了什么。其实那你需要结合各种各样的这个日志系统，指标系统是不是APM的这个系统？
一层一层的去进行这样的排排查。然后拿到了一些线索之后还要进行。这个剖析爬哪个地方可以等会出错。然后甚至是还要把他服务间的这个依赖关系，能够给他找出来。
可以看到从可观测性的角度，要探查的这个内容就是要远远大于这个监控，这个范畴，所以这个是首先我们澄清一点监控和可观测。
二、如何实现可观测
如何实现可观测，因为如果都做不了可观测的话，就谈不上全面的可观测了，所以从可观测的这个角度呢，其实我们也是一个这个分部去构建一个可观测性的这个步骤的，我们怎么也一步一步去构建这个可观测性。
其实说我们往往会有一个检查各个系统的这个健康状况的，一个非常简单的这种这个检查机制，那么之后可能我们阿会搭建一个这个采集各种系统的这个性能指标啊，这种指标的这种系统，然后这不建完了之后呢，我们往往会考虑一个集中化的日志的平台。
把所有系统的这个日志把它汇总到我们的啊日志平台里边，那样那个解决问题的时候，我们就不用一台一台的去登陆各种分散的服务器，而且能够把各个服务器的日志，能够做一定程度的这个关联和串联串在一起，去帮助大家去解决这样的一个问题。
那么第三部，其实这个要求会更高一些，它是会涉及到我们的应用的分布式性能的追踪，那这个他是比较微观层面的一个，这个追踪了，他往往是从代码层面，API层面能够直接度量我们的这个服务的这个性能，各方面的指标的，所以一般来讲我们要构建可观测性能，可以从这四个方面去进行入手，
1.分阶段构建可观测性
（1）健康检查
广播
将状态信息封包，发送到网络上，更新自己和邻居的状态
注册表
服务的ip/域名的端口信息，写入/更新到etcd或Zk，最新服务清单
暴露
.利用服务默认的服务端口，编写应用特有的健康服务，等待外部工具的轮询
（2）指标里面观察什么
那么首先做件指标，这种系统的时候，收集哪些指标呢？
第一个很基础的就是我们所有系统的这个指标，那么这个指标里边就包含 cpu 这个网络呀，磁盘呀等等，各种我们的底层的那种系统级别的指标，因为这个是最最基础的，我们跑在 Linux 上，那我们这个 Linux 的各种性能指标是至关重要的，对于我们的整个应用来讲好。
那么，这个在系统程序上，就会涉及叫做应用级别的指标，那么这种级别的指标，这个往往是在应用开发的时候就需要这个有意识地去暴露很多这个指标，如果你的应用都不暴露的话，那这个东西就其实这个系统对我们的这个外国人来讲，他是不太好观测的，他一定需要有一定设计来暴露这样的这些指标，那么在这个里边，往往会包含一些什么出错率，
一些这个应用的性能的指标，那么这种暴露的方式就跟前面会有一些类似啊，它可以是通过 API 的形式来调用，去这个去可以让外围系统去轮询。
用的更多的是通过日志的方式去这个打打这个指标，特别是像很多这个交易系统，你要处理一笔一笔的交易，那在我们处理这种这个事物的时候，肯定会把这笔事务相关的这些元数据，包括处理这一笔事务，一步一步，可能花费的这个时间都给他达到日志里面，那么后续，可以通过这个日志的分析来获得，对于这个系统的这个这个性能，各方面的健康度。
这个的可观测性，那么这个地方在打应用指标的时候，其实有很多我们很传统的做法就是就直接很随意地达到这个日志里，反正是文本，但是其实现在更流行的是把它直接打成一些嗯结构化的，像 Jason 的这种格式去打在日志里面。
因为这个对后面我们日志处理的时候，他有很大的这个帮助，Jason 这样的结构化的数据，他在阿做这个提取的时候，它的性能会比通过我们正则表达式，这种要快很多很多。
那么在之上，可能是一些业务型的指标，那么业务型的指标呢，他其实会涉及到我们的很多的，哎的分析的，就比如说你处理的订单的数量啊营业，我们其实在很多的应用设计的时候并没有有有意识地把很多业务的指标达到，比如说治理，达到达到中央注册表去。
如果其实做了一个这样的业务指标的暴露的，其实可以比较实时的来反映这套系统，你上面支撑的这个各种业务量的这个数字，所以这个其实大家我觉得在构建指标系统之后，更需要这个进一步考虑的，因为前面几个的都其实已经考虑过了，但是像业务指标，这个可能大家并没有特别关注这个。
因为它可能不不，并不仅仅是涉及到这个排错呀等等，这个东西其实，但是他对于我们的运营啊，运营业务运营人员，他其实比较重要的。
从指标获得可观测性
（3）如何从日志获得可观测性
怎么从日志或者咱们的可观测性，其实日志大家打了很多了，再用日志里边，不包括系统日志应用日志打了很多，但是这个从日志角度来讲，他很多就是一串这个字符串，那如果你要从这个字符串里边要能够获得观测性的话很重要，很重的一步就是进行结构化的抽取工作，那么从这个图上大家可以看到从里边。
其实我们人眼是很容易看到各种各样的字段的，比如说这个 IP 地址，比如这个时间，还有进程号，还有你具体的请求的url是什么？还有它的响应码等等这些，那么对于我们的这个日志系统来讲，就需要把这个文本的字符串能够变成一个结构化的，这样的一个数据，那么其你要获得同日之中获得很大的观测性，那么这一步，其实最花精力和时间的就是做这样的结构化的提取工作。
把这样的一个文本流变成一个结构化的这个数据，然后各种类型，也能够啊，贴近我们也来个设置里边最贴近的数据类型，就比如说 IP 的这个类型，可能是这个 keyword 的类型，有些可能是这个number 的这种类型，这个就是很重要的结构化这个步骤，如果要获得更好的这个观测性，注意，其实你在打日志的时候是很有讲究的，就是说，你的日志你能够暴露多少状态，就意味着人家对你的监控，这个监测的程度能够做得多好。
现在这个指标，这个里边用的比较多的，像传统的在这还有像这个比较，像普罗米修斯这种系统是比较多的，在现实应用当中，那么这个，他从原理上来讲，就是从各个采集点这个采集点，可以使咱们业务暴露的这个 API 也可以是咱们的业务，到这个其它这个地方写到中央注册表啊等等，这都没有关系，那么他会有一些普罗米修斯提供的这个 agent，帮大家去这些里边去采集这样的这个结构化的这个数据，这个数据，会写入到普罗米修斯这样一个这个持续的这样的一个数据库。
然后可能会基于一些像广发那啊等等，这些 open source 的这种可视化展现工具来做到一个指标的这个可视化，那么从告警角度呢，这个地方啊，他也可以去写一些报警的这个规则，然后通过向web的这种方式，对外的进行这个报警，这个就是做指标系统。
如何获得更好的观测性
像这边的话就是一个比较好的这样的一个例子，就比如说除了常规的，什么时候发生的，他的这个等级级别是什么呢？
其实我们往往有的时候还是要考虑到一些其他的地方，就比如说他是一个什么样的服务了，这个地方可能会直接会打在里边，比如说它的开发的团队是谁，这个东西也很重要就比如说你这个东西，如果出现问题，我究竟是找哪个team去这个开发这个东西去找到，从运维角度去找到合适的人去解决这样的问题，然后这个我们编译代码时候，你究竟是哪个build哪个compete对吧，这个东西，如果能够一定程度打进去的话，那么也非常有助于暴露这个，帮我们去检查我们的问题所在。
那么还有，就是说大家可能没有注意到的是一些，比如说卡斯idea和游戏ID这种这种东西，因为这个的话可能会代表你这一笔处理异常，他影响到了哪个用户，因为这个是很重要的，因为很多时候我们往往是从用户侧去，首先拿到他们的这个，抱怨这个程序出错了，然后我们才到后台去查询啊，等等。
那么从这个地，如果我们有意识地把一些元数据能够打进日志里面，对我们后面做这个分析这个质量的这个服务等等，其实非常有帮助，所以如何很好地答，这个日志其实是非常值得这个研究和探讨的，特别是我们从运维角度的，要跟我们的程序开发人员一起去探索这个日志究竟应该怎么样去打得更好。
（4）如何从 APM 中获得可观测性
●服务间的调用堆栈
●服务内部的调用序列
●每一步花费的时间
●代码相关信息
●错误
三、IT 运维发展方向
Level 0
工具：具备多种IT运维工具，能够实现监控及日常运
维管理
Level 1
归档级：各级运维数据已实现归档及持久存无法全局搜索
Level 2
检索级：通过一个平台实现所有运维数据全局搜索
无法关联分析
Level 3.
分析级：通过关联所有运维数据从而分析解析原因并且能根据分析结果自动化运维无法事前预防
Level 4
预防级：根据历史所有运维数据和回归算法实现故障预防无法判断各种指标和故障之间的关系
Level 5
智能级：通过有监督的机器学习或者智能算法进行预测机器不断学习+经验积累
（2）IT运维成熟阶梯
四、什么叫全观测
1.定义：是传统运维的一个改进
2.传统运维的问题
●数据孤岛，分散在不同部门,分析排
查故障困难
●多个厂商的多种工具,无法自动化统.
--分析
●故障是立体的，日志指标APM都只能
看到一方面的可观察性
●只是收集，没有做到真正分析,不能
发挥出大数据的价值
（1）.统一的可视化分析视图
将日志、指标、APM的分析图表放在一个页面进行统一的分 析和趋势呈现
（2）.统一的监控和告警
在构建监控和告警规则的时候可以综合日志、指标、APM的数据，减少误报
（3）.统一的机器学习异常检测
可以对日志、指标、APM数据设置统一的机器学习规则， 将告警统一分析
（4）、实现全观测的难点
五、技术生态
1、数据采集生态
日志采集工具：Filebeat、Flume、Logstash、Fluentd
指标采集工具：Zabbix、Prometheus、Metricbeat
APM采集工具：Elastic APM 、Jaeger、Skywalking、Zipkin
2、数据存储搜索工具生态
（1）关系型数据库：
可以join
数据量承载
字段增减
大量字段
全文搜索
（2）时序数据库：
对于大量时序数据存储优化
维度有限
多维搜索不够灵活
大部分主要处理数值
有一些还不是分布式的
（3）ES搜索引擎
分布式大数据量
灵活的多维度搜索
支持大量字段
全字段索引
不能join
大量字段
●全文搜索
2、分析展示工具
六、实现全观测的主要流程
分为数据采集阶段数据处理数据搜索存储和可视化这么几个大的这个步骤，那么从数据采集这个地方，我们可以看到这个地方，是我们用各种工具去采集我们的日志，去采集指标去采集 PM，那么采集到这个数据，
我们像 kafka，这个是我们在真实项目当中经常会用到这个数据的汇聚层，因为这个采集的数据一个是量非常之大，所以，我们首先要能够保证他有一个可靠的落盘的地方，所以 kafka 是经常被使用的这个工具，产量数据可以比较，以经济连带的方式进入到这个卡不卡先能够安全的罗盘。
那么从数据处理层，工具就非常非常多了，相比较我们XX里的 last，他可以从卡进行消费，那么还有像 spark flink 这种流式处理，他也可以从卡里进行消费，然后还有一些像 APM server，因为 PM 数据的，它是有特定的这个结构的，
所以一般会有ATM专门的 APM server，他也可以从卡里面去进行数据的消费，那么他经过各种各样的这个数据处理，经过流失的处理，或者经过这个正则匹配，经过 APM server的这个数据加工，最后会流入到我们的数据存储层，那么也来这个社区里边会对数据进行索引，这样最后一步呢，是进行这样可视化的展现，那么可以再提拔上去进行可视化，也可以用第三方的呃工具进行这样的可视化。
