开发者学堂课程【开源 Elasticsearch技术训练营：【训练营第四课—了解全观测行业应用】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/898/detail/14316
训练营第四课—了解全观测行业应用
内容简介：
一、全观测概念的介绍
二、全观测性应用场景
三、阿里云ES VS开源自建
一、全观测概念的介绍
1. 三方面：
（1）日志数据（文本）：
从采集开始到存储到查询介绍日志数据，在工作开发中，日志数据是避免不了这是一种文本，任何做开发的人或者是做运维，主要是做 it，这个日志数据是免不了的，加入腾讯，最经典的框架落败，都会用到来写日志，写各种系统日志啊业务日志，还有中间，还有自己自定义的一些格式，图中这个图，是一个例子是一个 PC 的一个 DC 的日志写入可以看到一般一个文本日志里面会包含几个重要信息第一个发生的时间，当然这个线程编号，其实无所谓，然后再就是发生的这个模块代表什么意思，然后最后就是这个日志的详细信息，那对于这种日志场景，业界已经也有非常多的产品可以做得到，但是强调的，为什么耶稣做的最好啊，这是因为啊yes的方面，想象一下这个场景想要在一套产品里面去做的，那只 es 可以做的到目前来说，所以对于日志来说，在 eS 这个领域，有诞生了很多，经典的产品叫wehook
（2）指标数据：从采集开始到存储到查询
高级抽象本质也是来自于本质，但是主要是定义用来做这些数值类型，给我们按照这个微商这种基层的管理，Na 指标数据的指标数值，你可以把中文处理它用来记录各种指标数据，比如像我们这个图上，
想知道 cpu，Cpu 图内存图迪斯科磁盘，然后应用程序，哪些消耗cpu最厉害，哪些消耗内存的厉害，然后这个历史的这个 cpu，占用比例，这是一种，很常见的一种，指标监控，这个对吧，可以想象一下对，然后再结合前面的日志，现在唯一这个世界上能做的比较全面的想一下，其实没有多少产品，可能很多同学这里会想着，我也原来用过，比如像X，还有普罗米修斯这些做指标，但是，我们刚说我们既然今天分享的主题叫全观测性，那肯定要做的事情就是一个要非常的全面，全面在一个平台，而不是只做一点。
（3）告警通知:自定义配置规则，人工和自动化并存
要告警通知我们既然这些日志，指标我们采取了，那要基于这上面做一些告警规则，比如第一个要告警，当我的日志中产生某一类特殊的日子，比如错误错误达到多少，然后比如某个数值，比如 cpu，在我们家 APP 里面，超过这个50%，超过百60，还有他负责数超过多少，他应该要有这样的一个能够自定义这样一个告警规则，同时，要支持这种通知，发一个通知给我，需要他给我发一个邮件或者是啊短信之类，现有的不可能直接会支持，比较好支持你这种，微信，这个没有的，所以，一般，都会在这个里面可以出一个叫微博，这个单词写错了没关系，就会推出一个叫微博后开这个啊概念，就是要通过我教你一个远程的IP端口IP接口来做到通知HP结构之后，你用自己去集成自己的一个短信平台语音平台电话平台，然后微信，或者是其他的都 M 工具都可以，
那第三点最重要的我觉得是，最重要的就是因为前面我们通过自定义规则去发起高级控制，这种很累，想要一个非常庞大的一个系统里面，或者做基础基础监控的，你公司管理的服务器上柏油上千段，但这个难度是非常高的啊，如果你想把各种告警的通用规则都能配好的话，所以这个难度很高，不亚于啊编写一个强大的一个系统啊所以智能化很长，非常重要，在整个这个全关心行业应用里面，任何产品如果不具备这个智能化，意味着人工的工作非常多。
2、elastic stack 技术栈主要四个产品站：
（1）Kibana：典型的日志探索页面,采集进去的数据不用考虑字数指标，会自己整理，可以用不来做高级告警通知，把日子的展示和数据的一体化
（2）Elasticsearch：数据存储 储存原始数据到es 上，支持海量数据，第二支持查询数据，第三分析数据，可以支持行式和列式的数据、
（3）Beats：可以采集各种日志文本，es 的日志直接是被整理好，非常细节。
它主要核心的话就有六七个，然后他的一个技术占主要是这样的，就是我们前面讲介绍个，指的是这三个，，应该是2015年以前最流行的一套啊，做这种采集最流行的一套啊技术站，后面呢VS 公司可以出了这个 b ci 产品啊这个，
大家可能有待了解，它的背景就是的，因为员工C是加血的，在做这种高性能的被子员要求比较高消费比较低的这种场景下，那个C显得很无助，因为去采集的数据居然还要装一个价位，编码环境，这个其实，是不太明智的，所以，必须加入这个产品，它是基于 go 语言编写，清亮也非常清亮，消耗的资源部署在服务器上消耗的资源，基本上你可以忽略，然后他这个技术战略，为了避免有太多的冲突，他们做了一些职责上的一些划分，主要用来专门做这种日志采集日志，Special原来他也可以做，现在依然可以做，但它在这个价格里面大家可以看到，
比如说我的日志各种，或者指标数据采集的时候，我们就叫数据采集的时候，如果遇到一些数据要做自定义转换那可以把这数据采集完之后首先传到螺丝，在写那个CT做完之后再写到eS里面
(4)Logstash：
可以支持各种数据文本，支持几百种，写成各种文本日志都可以
负责数据的存储查询计算聚合，在一个叫彼此彼此，主要是负责这个数据采集，原来，今年的这个 LG 里面的部分是如此的想要，就代表 Linux 下眼袋，也可以用来大量的做数据采集。
现在应该也是可以的，基本上就是我现在因为彼此带来就不能再做这个传统日志和指标，产品还有显得非常的笨重，所以他现在自己降级为转变角色，成为一个标准的一个轻量级的 ETF 工具，了解一下的可以赚点差价，在里面大量的这种作文，家乡的时候，全款自己大量的基本上是一笔资产，如果发现数据有需要做一些人工的这种加工之类的工作可以,需要借助这个楼盘要把数据开关一个介绍，可以去关注一下，然后，可以去查阅官方文档，接下来也是一个软件处理一下.
首先第一个介绍的是提拔，就该是一个原来是一个据说是一个运维人员开发的S公司，因为当时他原来不属于后面，是听说他们的基本是合作银行，这个是一个典型的一个日志的一个看守界面，交给KL选择一个所以日志，然后，可以看到这个采集的数据量按时间过去20，然后，下面那块地是一个日子的详细数据，所以从这个上面如果你采集的日子，不能去问，还是指标对他来说都是一样的存在，一方面是一样的，仅仅是展示的时候。王教授之类的这种方式。
3.总结
（1）.文本日志
taWeb logs
App logs
Database logs
Container logs
（2）指标日志
Metrics data
Host/container metrics
Database metrics
Network metrics
Storage metrics
（3）APM data
Real user monitoring
Transaction monitoring
Distributed tracing
Dependency mapping
（4）APM data
Real user monitoring
Transaction monitoring
Distributed tracing
Dependency mapping
二、全观测性应用场景
微服务平台
1. 分布式微服务系统：
大数据、高并发和快响应已经成为互联网系统的必然要求。在之前的单机系统中，大量的数据会导致查找数据的响应时间边长。高并发会使系统因为繁忙而变慢，从而影响响应速度，单机故障也会是系统崩溃。
为了解决单机系统带来的问题，互联网系统就从单机系统演变位多台机器的系统。分布式系统有一组为了完成共同任务二协调工作的计算机节点组成，它们通过网络进行通讯。
分布式系统能满足互联网对大数据存储、高并发和快响应的要求，采用了分而治之的思想
高性能：大量请求可以分摊到各个节点上，从而解决系统的大数据、高并发和快响应问题。
高可用：请求会避开存在故障的节点，使用其他节点，系统仍然可以继续工作。
可伸缩性：对于现有机器节点可以根据业务量灵活的进行增加或者减少。
可维护性：对出现故障的节点，进行处理之后可以重新上线。
灵活性：对于系统的更新迭代，可以在非高峰期，停止部分节点更新，然后交替去更新剩下的节点，从而更加灵活，不需要停止系统的工作。
2. Zookeeper 指标：
是一个开源的分布式协调服务,ZooKeeper 框架最初是在“Yahoo!"上构建的,用于以简单而稳健的方式访问他们的应用程序。
后来,Apache ZooKeeper 成为 Hadoop,HBase 和其他分布式框架使用的有组织服务的标准。 例如,Apache HBase 使用 ZooKeeper 跟踪分布式数据的状态。 ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单。
3. Kafka 消息队列：
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。
实现高性能、高可用、可伸缩和最终一致性架构。使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。
elasticseatch开源生态矩阵集合了多种，就是包括像文件，然后指标相关的这样一些数据 Asian，然后他能agent下拉到很多的机器上面，包括就是大家的一些雕刻服务器，或者一些就是这样一些服务器上面，然后去向他的下游去发送他的数据，那其实在这样一套生态取证中，就是除了btec的下游就基本上是我们的 boss,但是bibatala 大家应该也会也都不怕陌生。
是作为收集和过滤传输数据的一个工具，他能够去支持用户去做一些数据类型的转化，然后去针对各种各样的一些日志数据，或者是系统日志，审计日志，然后去做这样一些格式上的预处理和过滤，那其实除此之外，我们的数据经过了一些采集和处理之后，最后的这样的一个操作系统中去做存储之后，其实我们可以通过bibatala这样一套可视化的工具，进行业务上的一些可视化的报表。
分析大盘的这样一套大钱，其实从彼此到access到这样一套就是开源的生态矩阵，能够去帮用户去解决各种各样的问题，就我们刚刚看到的一些场景下的一些问题。
Beats是轻菜级数据采集工具，集合了多种单-用途数据采集器，它们从成百上午或成干上万台机器和系统向.
Logstash 成 Elasticsearch 发送数据
Logstash是收集，过滤，传输数据的工具。支持系统日志，审计日志。应用程序日志等类型，支持在传的时进行数操处理和过读。
Elasticearch 是构建于 Apache Lucene 搜索引擎库之上的分布式金文提索和分析引象，提供搜集，分析，存继数据三方面能力。
Kibana是灵活的可视化工具，支持多租户登示。可以方便的预建满足重务需求的可视化报表和分析大盘。
阿里云 Elasticsearch 提供全托管 Elastic Stack 服务，100%
兼容开源，免费提供X-Pack商业插件，即开即用，搜是付费。
深入功船与内核性的优化，提供更拿富的分析检索能力。以及更安全，离可用服务。
特性及优势
便成本
.免费提供每个节点价值6000美元的X Pack商业插件
.智能运维，高级监控告面容灾部署等，超低运很成本
.针对性场是调优，提高资源利用效率，多种产品价格架略功能与性和强助
.日志增强版内核，100%成本降位， 100%性能提升
.文本。视频，合须，图像，提供最全面的信息检素能力
.全国对齐等保2.0要求，企业级数据安全能力
.开放的二次开发能力，支持各种业务场最的封装
三、阿里云 ES VS 开源自建
在各个业务场景下，对比自建集群均带来了全方位的能力提升与性能优化、整体成本、群体管控、能力差异、安全性、高可用。
他有的主要对比，是从整体成本上，包括到管控上面，到包括核心的一些检索能力的差异，上面都有自己的一些优势和性能的提升，其实这里面看到，其实除了一套全营上的全体全部托管之外，其实我们会有包括一些超低的运维成本，然后去降降的，在一个就是大数据量存储的一些存储上面的成本，然后其实在管控之外，其实我们刚刚说到我们的整个4S服务是能够一键的拉起，然后并且一件的去去竞答集训的搭建的同时就是针对我们，其实包括大家在实际的业务场景，其实会有一些资源上的一些弹性伸缩的需求，然后在云上其实是非常匹配这样的一些场景的
集群的运维和监控上面，有非常全面的一些能力，一些核心的一些集群读写性能，包括一些搜索能力的上面，，除了一些向量检索分析器之外，在集群的稳定性，上面也会也会给大家提供包括一些 QS 的见，刘XX线，然后防止你当你的一些大流量的数据打打过来的时候，把你整体服务去做，这样也能去保证我们这样的一个以上服务的稳定性，然后还会在内核上面去做一些优化。
在安全性和高可用方面，其实大道这儿零上一定是我们会去做。
更多就是大家在自建的时候没有那么多精力去做的一些安全特性上的一些能力上的一些补充，包括我们帮大家去做一些APP的传输加密，然后还有一些内网环境的一些一些就是管控，那在就是整体的服务可靠性，因为很多用户他们都会说你这个提供这样的一套S服务，你对我们的可靠性是指需要多少？
我们即使整体在数据上面只有99.9%这样的一个数据可靠性，然后我们整体服务也是能够提供3%，就是三个九九十九点九，这样的一个服务可靠性就是我们的上面能够去尽可能的保证用户。
你在使用我们这样一套服务，下面就是能够去支持好的业务，然后不会受到各种各样不稳定因素的影响。
System 系统指标
这种把握那么同时进，所以我今天晚上就是基本上我们经常用的，再一个就是这个叫卡夫卡，我相信很多问题。讲到这个例子里面讲到这个微服务里面，那么多的数据，这么多的数据采集，想象一下个物流公司，几百个200个为服务，然后部署起来。
都快超过上千个了对吧，那这个压力很大，每秒钟采集的数据量很大的，所以这个时候一般会以后，在这个过程中承担一个消息到八分缓冲非常关键，非常重要，所以我们要对他进行一个完整的这样一个链路监控吧，也很重要，那这时候。也推出了这个。
专门监控，各种产品，直接对接。一般都部署在操作系统上不管你是用语音还是用自己的这种新房，所有人或者移民的监控至关重要。
监控操作系统
像这边的话就是一个比较好的这样的一个例子，就比如说除了常规的，什么时候发生的，他的这个等级级别是什么呢？
其实往往有的时候还是要考虑到一些其他的地方，就比如说他是一个什么样的服务了，这个地方可能会直接会打在里边，比如说它的开发的团队是谁，这个东西也很重要就比如说你这个东西，如果出现问题，我究竟是找哪个team去这个开发这个东西去找到，从运维角度去找到合适的人去解决这样的问题，然后这个我们编译代码时候，究竟是哪个build哪个compete，这个东西，如果能够一定程度打进去的，那么也非常有助于暴露这个，帮我们去检查我们的问题所在。
那么还有，就是说大家可能没有注意到的是一些，比如说卡斯idea和游戏ID这种这种东西，因为这个可能会代表你这一笔处理异常，他影响到了哪个用户，因为这个是很重要的，因为很多时候我们往往是从用户侧去，首先拿到他们的这个，抱怨这个程序出错了，然后我们才到后台去查询，等等。
那么，如果我们有意识地把一些元数据能够打进日志里面，对我们后面做这个分析这个质量的这个服务等等，其实非常有帮助，所以如何很好地答，这个日志其实是非常值得这个研究和探讨的，特别是我们从运维角度的，要跟我们的程序开发人员一起去探索这个日志究竟应该怎么样去打得更好。
总结：开发领域很大，有很大的市场，支持多种平台，怎么从日志或者咱们的可观测性，其实日志大家打了很多了，再用日志里边，不包括系统日志应用日志打了很多，但是这个从日志角度来讲，他很多就是一串这个字符串，那如果你要从这个字符串里边要能够获得观测性的话很重要，很重的一步就是进行结构化的抽取工作，那么从这个图上大家可以看到从里边。
其实我们人眼是很容易看到各种各样的字段的，比如说这个IP地址，比如这个时间，还有进程号，还有你具体的请求的 url 是什么？还有它的响应码等等这些，那么对于我们的这个日志系统来讲，就需要把这个文本的字符串能够变成一个结构化的，这样的一个数据，那么其你要获得同日之中获得很大的观测性，那么这一步，其实最花精力和时间的就是做这样的结构化的提取工作。
把这样的一个文本流变成一个结构化的这个数据，然后各种类型，也能够贴近我们也来个设置里边最贴近的数据类型，就比如说IP的这个类型，可能是这个 keyword的类型，有些可能是这个 number 的这种类型，这个就是很重要的结构化这个步骤，如果要获得更好的这个观测性，注意，其实你在打日志的时候是很有讲究的，就是说，你的日志你能够暴露多少状态，就意味着人家对你的监控，这个监测的程度能够做得多好。
现在这个指标，这个里边用的比较多的，像传统的在这还有像这个比较，像普罗米修斯这种系统是比较多的，在现实应用当中，从原理上来讲，就是从各个采集点，可以使咱们业务暴露的这个API也可以是咱们的业务，到这个其它这个地方写到中央注册表啊等，那么他会有一些普罗米修斯提供的这个agent，帮大家去这些里边去采集这样的这个结构化的这个数据，这个数据，会写入到普罗米修斯这样一个这个持续的这样的一个数据库。
这些 open source 的这种可视化展现工具来做到一个指标的这个可视化，那么从告警角度，这个地方，也可以去写一些报警的这个规则，然后通过向 web 的这种方式，对外的进行这个报警，这个就是做指标系统。
