开发者学堂课程【阿里云可观测峰会：主会场】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/16101
主会场
七、Grafana 是什么及其目的
接下来学习 Grafana 是什么及其目的，下图是Engin提供的一个控制面板，图片中的界面来 checklyHQ，正在检查从全球各地访问他的网站的延迟情况、检查网站的可靠性、检查所有的API、检查所有的终端节点，确保网站一直在线并且能够在全球各地正常运作，这是
Grafana在IT领域的一个典型用例，很多人通过Grafana检测自己的应用，无论服务器是数据中心中的大型集群，还是Reddit帖子中提到的小型家庭实验室服务器，可以从Grafana中学到技术类工作的入门技能，这是Grafana非常神奇的一点，任何人都能使用不仅是免费的，还是开源的，能连接各种数据源
下图为另一个控制面板是某个人使用Fitbit创建的健康控制面板，Grafana不仅有IT方面的用例，在进行心率练习显示心率是多少、心率上限是多少、睡眠间隔时间有多久、睡眠质量怎么样以及运动量有多大、每天的活动量够不够，以上这些全部可以通过Grafana可视化，可以通过Grafana可视化的数据非常多。Grafana不仅有IT方面的用例，还可以通过监测运行中的蒸汽轮机的实时振动，在观察一段时间内的振动之后创建了一个自定义面板可以帮助可视化数据并显示蒸汽轮机的实际振动，这种工业方面的用例，或者更准确的说是过程控制方面的用例比如在发电和物联网领域变得越来越多，可以通过该软件进行可视化的对象是无限的
下图是另一个有趣的可视化的例子，显示的是绕地球运行的国际空间站上太阳能电池板的发电情况和位置，可以看到电压是多少伏以及阵列的位置都在Grafana中实现了可视化，可以看到Grafana有很多种不同的用例，不仅可以监测服务器、应用和容器都很常见。现在可以检测各种事物比如空间站上的太阳能板，使用交通信号灯可视化是一个很好的例子。
空气中的二氧化碳在监测安全性和空气质量，除此之外登上SOFIA机载天文台实际上是一架波音747飞机由MASA负责运行，飞行路径在Grafana中实现了可视化，可以看到气压高度，在飞机上有一台100英寸口径的望远镜能够拍摄宇宙边缘的红外照片，正在使用波音747机载望远镜研究恒星和黑洞的诞生，可以通过Grafana可视化的数据，以上是对Grafana的介绍，主要围绕数据可视化，Grafana是开源的，Grafana并不是唯一的开源项目，Grafana实验室还拥有Grafana Loki、Grafana Tempo和Grafana Mamir。
Grafana本身在过去几年里变得非常普及，该项目已经开展了7年。目前全球有超过900000个设施正在使用Grafana，Grafana在Github上获得了超过49000颗星，Grafana是适用于所有数据的最流行的开源可视化软件。Grafana已经变得越来越普及，相信开源软件将会在可视化领域和可观察性市场胜出，下图显示的是谷歌趋势中Grafana在中国市场的普及程度。
可以看到Grafana在过去六年非常受欢迎与其他的一些商业产品相比Grafana表现的非常棒，Grafana在中国越来越普及。
接下来讲解Grafana大帐篷理念，大帐篷的概念是希望促进交互操作，希望帮助整合数据不管数据存储在哪里希望能够让客户和用户能够选择想要使用的数据库、想要合作的供应商、想要运行Grafana的场合。提出大帐篷理念意味着Grafana能够拥有自己的可观察性策略以及数据策略，不会局限在一个数据库也不会局限在本地或云端，能够自己选择自己的命运，能够确保Grafana适用于所有指标数据库例如prometheus、influxDB或Timescale以及很多其他的指标数据库包括Datedog或NewRelic，还想要确保Grafana适用于所有的日志记录数据库，无论是Elasticsearch还是Grafana自己的Loki项目，甚至是像Spunk的日志记录数据库完全由自己选择。希望客户自己运行Grafana或者在选择的合作伙伴云端进行。
阿里云Grafana是一项新的服务可以进行注册试用，对于目前同处于一个生态系统中的各种互补的阿里云服务该服务可以发挥进一步的补充作用。Grafana作为一项官方服务是来自阿里云的一项完全托管服务，能够很好地确保数据传输的安全性以及大量的访问控制等，真正做到了可扩展和安全可靠，此外这项服务还能与其他阿里云产品完美集成，从 Prometheus服务到日志服务、云监控服务、阿里云Elasticsearch 服务再到 TableStore，Grafana都能很好的集成。
八、DEM 驱动可持续性发展
在2022年十四五、可持续性、后疫情都给客户的业务、IT以及运维带来了新的变化和挑战。
首先是十四五的数智化，特别是以金融为例银行从前几年金融与互联网的互动，从互联网金融到金融走向互联网完全以to C为目标进行营收，在金融科技里面是否需要反噬，提出的理念是改变整个金融科技以to C为中心转向以to B或者以to VIP为中心的想法和思路，需要强调的是里面完全是不同的逻辑，如果以to C为主是构建一个以应用为中心的逻辑就可以，比如保证了应用的可用、应用的稳定，C端用户基本可以。当转到以to B或者以to VIP为中心时是以用户为中心的逻辑，举例比如有一个单一用户投诉以to C为主的话，因为是单一用户并不会得到特别大的重视。
如果以VIP用户为主，一个单一用户的投诉可能意味着很多事情，是否需要将用户从头到尾的逻辑都查清楚，这是可观性的一个重要挑战，因为是实时的业务数据，是全新的逻辑和挑战，这是第一个部分。接下来谈第二个部分即可持续性，全球用户第一是提升用户的满意度，但是中国52%的用户选择了可持续性，可能是中国特色的需求，因为保证业务的可持续性先是很多企业的社会责任比如以银行为例一级事故如果半小时主营业务还没有恢复的情况下需要上报人行，是非常大的责任事故，因此保证业务的可持续性成为了全新的挑战，这个问题一直是存在的，之前都是以数字中心为中心，同城之间做双活数据中心就解决了可用性的问题。
但是现在有云的环境云原生、微服务有很多新的技术的研入，在兼容新老的情况下，实现可持续性，是全新的话题。在这时传统的运维逻辑已经全部失效，一个新的可观测性的平台才能完美的解决问题，这是在可持续性方面。第三个谈到的是后疫情时代，现场专家与技术运维人员，在后疫情时代没有那么多人去查看问题出在了哪里，专家也无法进入到客户的数据中心，而大行或者金融机构都不允许远程接入，这是一个悖论专家过不去现场的人没有被培训为专家，这时如果在现场进行跨域的排错跨部门的协同是一个全新的挑战，而且很明显疫情有很长一段时间在做疫情的过渡，确实三大挑战是存在的，为了能够理清楚以上问题进行了精细的调研，花费了大半年的时间将整个运维体系做了指标的白皮书，从代码生成开始到用户为止全数据链的过程需要经过哪些环节，需要哪些指标体系进行构建。由于屏幕有限展现的是几百个而已，但是后台统计是有2000多个指标需要监控，而且2000多个指标不是一个component，交叉组合是一个很可怕的结构，因此传统的网络运维、主机运维、开放平台、安全、云、数据分析，需要强调的是并不是一个科研机构需要投入多少钱财、人力和时间能解决可观测平台的提问，这是为什么阿里云想要给客户帮助的原因的真实所在。博睿数据之前一直在配合阿里云希望在可观测上给客户带来相关的帮助，下图为云栖大会上博睿称为阿里云的核心伙伴，同时在ARMS平台上也已云拨测为目标，实现ARMS平台的一个大块的功能，做的是DEM，DEM做的是Difital Experience Management的用户体验管理，发起是在外网拥有拨测的节点，最早使用PC后来发展到使用手机，无论是PC还是手机都是主动发起对网站的主动请求看用户的性能如何、用户体验如何，这是最早期的主动拨测的逻辑，发展到后期时开始发展到手机APP，这时需要做一些手机APP的SDK嵌板看到用户的真实体验，后来又有了小程序等都开始进入新一轮的用户体验管理过程，再后来像摄像头、汽车、IOT都存在于DEM的管理范畴，客户走出数据中心或云中心到达用户中心这个过程如果没有用户体验管理很明显是很大的欠缺，因此博睿数据配合阿里云平台构建了完善的云拨测功能，如果感兴趣可以到阿里云平台预配置可以得到很好的了解，看到一个DEM帮助用户做用户体验的提升。
应该考虑DEM的解决方案是否在提升用户体验之外还能帮助客户做业务可持续的提升，这是非常好的话题，接下来谈一谈想法。将DEM的主动拨测技术看做是一个RPA即远程的机器人，放在外网做云拨测判断的是各个地域、各个运行商、各种接入方式、各个浏览器的版本去访问一个应用时真实的用户体验，如果不仅仅将拨测的节点放在外网放在内网甚至是API服务上去判断每一个服务链条节点的服务状况结果是任何一个点当拨测发现点的性能下降或者是可用性下降时就认为业务可持续性的风险点并且进行快速的处理和判断。招行是大客户给出了一个建议是数字性80%的IT故障是和人相关的，里面特别谈到的两点是配置变更和灰度发布，数字化虽然现在很强但是人为的因素还很高占比80%左右。可以想象一个客户在整个配置变更和灰度发布的前后进行主动拨测的对比，这时完全可以实现在客户投诉之前快速的发现问题和判断问题，而且需要强调的是并不是探针的职务没有任何代码的变更只是在每个环节上进行了拨测的节点，去模拟一个用户的访问。
外网帮助判断的是运营商的链路整个传输带宽到达数据中心，从数据中心开始经过防火墙、路由器、计算机、负载均衡到达服务端，服务端有各种Poto有各种API的互相访问，每个环节每个节点都要进行设计。一旦任何一个节点出现状况时可以快速的认为此节点是风险点，需要对它进行定向的处理和解决，因此最大的好处是没有代码切入的情况下完全用主动拨测的方式快速的发现问题以及问题的根源。一个DEM技术不仅可以帮用户提升用户体验同时可以用主动拨测的方式帮助业务提升可持续性，提前发现问题和解决问题，这是很多客户在进行最佳实践进行了这方面的尝试，最重要的是将主动拨测用在一边，将外网、内网和API全部利用起来去做完整的拨测的平台。
接下来讲解后疫情时代如何用DEM帮助用户持续发展的逻辑，首先是业务方面，数字化转型是如何将一个IT部门转型成业务运营的部门，比如博睿最早是做互联网出身的，谈的是一个网站的用户体验如何提升，如果一个企业客户做一个大的开销之后开始做拉新、日活、月活使客户更加活跃一些。实际上提升用户体验的核心本质是提升客户在系统当中的留存时间，实践间是数字资产的累计，IT部门如何从成本中心转型成业务中心，在数字资产方面有非常大的可能去做。DEM用户体验管理是第一步，如果没有DEM能力无法谈到数字资产累计、数字资产体验，这是第一个模型。
第二个是业务的可持续性提升，需要强调的是很多大客户不愿意有代码的侵入，因为会造成可用性的风险、安全的风险和运维排障的麻烦，更希望是无代码侵入式的解决方案，比如以DEM为实现方法，以主动拨测在内网、外网、API进行全链路拨测的方法。
拥有可视化的平台做可观测的结果，首先可以非常快速的在无代码侵入的情况下帮助客户判断那个点存在认为故障的可能性，真正是80%d的人为切换比如割接、配置变更、灰度发布的过程中有一些人为的错误可以提前发现出来比如性能下降、可用性下降将风险点立刻抓出进行处理解决。快速解决是业务可持续性的保证，而且拨测的逻辑和后台是物理机、虚机、云主机还是微服务是无关的，是业务逻辑的模型，这是数字孪生的展现，反映了真实的数据中心互相访问的逻辑关系，通过串接主动拨测的方式数字孪生的展现出来，这是全新的想法和模型，最近做了非常多这方面的尝试帮助用户提升业务的可持续性是非常好的效果。提升可观测性在云原生和微服务的架构当中，如果没有新的可观测性的平台靠传统的metric已经完全失效。
理念是构建全新的平台走出数据中心或者云中心打通云管边端到达用户端，以用户为中心构建一套完善的数据采集能力以及数据的规制化、格式化和存储的能力并在上面构建相关的可观测性，这是一套真正的在提升用户体验的同时提升用户的可持续性，并且提升可观测平台的能力，不是很多产品很多工具的累计产生的最佳实践是不可能的，因为每个数据格式是不同的，希望用一个统一的平台进行数据的分析和展现，有一个统一的逻辑去实现BI或风控的业务。希望在后疫情时代配合阿里云帮助客户实现可持续性的发展。
九、跟踪日志记录和度量
首先看 Skywalking v9，v9将整个应用加入了层的概念，layer是v9的新概念从左侧的菜单栏可以发现agent的标准服务Service Mesh、Kubernetes、infrastructure包括 Windows、Browser、Database和自监控Self Observablity，整个环境涵盖了从最普通的业务应用到平台的整个云原生或者是在续集环境上的监控。
从数据的角度来说，最常见的数据是Metrics、Logging、Tracing，首先从各个部分回顾基本的数据。Tracing是近年来最热门的话题，提到Tracing会想到10年之久的 Google的Dapper的论文，里面提到了Trace概念、Span概念，stroken有自己的协议虽然能够接受zpn的数据，如果想使用更高级的特性，使用完全的trees分析指标，这不是zpn的trees可以做到的地方，更多的需要原生的叫做STAM是一篇以论文的形式发布的文章更多的介绍Skywalking为什么构建自己的trees为什么要有自己的结构为什么要有自己的上下文，从trees本身可以简单理解为增强了上下文的日志，日志实际上是请求和请求之间没有办法连续连接在一起的，应用和应用之间跨进程的时候不能联系到一起。
Dapper始终是低强率，在国内很多的应用商希望100%采样，这个过程需要更多的优化以及更多的特性，因此在此基础上会有自己的协议。
Metrics是最简单的以数为标准的系统，不管是广为人知的普罗米修斯中提出的几种结构还是传统的zapicks,Metrics是一个相对来说比较统一的状态，可以看到Skywalking有多中支持数据的格式包括Prometheus Fetcher、Zabbix Format 、OpenCensus、Envoy Metrics Service和Skywalking Meter的API接口上报数据，以及直接通过Telegraf发到Skywalking里面，下图是Skywalking监控Metrics的一部分，是来自KSM，Monitoring Kubernetes through kube-state-metrics系统通过cAdvisor，通过OpenTelemetry的整合，在新的页面上进行统一的展示，这样K8S的监控可以和应用的监控和open function的监控摆在一起成为一体化的监控的过程，Metrics是整个生态中做的最好的。
Logging 是流逝化的日志处理，日志更多的是收集、加工两个部分。从收集的层面上和许多层面也有接触比如 Fluentd、Fluentd-bit、Elastic FileBeat、Envoy Access Log、OpenTelemetry Collector和Envoy本身的日志，这些常见的格式现在是有的。日志在收集过程中很多还有日志的分析，由于时间限制就不讲的很详细可以在 Skywalking中定制分析脚本将Log进行加工或者根据需要进行采样甚至转变为某些 Metrics，基于log展示Metrics成本比较高需要比较谨慎的去做，因为扫日志意味着日志都要被收集都要被打出来，即使最终不入库在网络中的消耗很大，因此是比较谨慎的选择，其余除Metrics的策略实际上都支持。
下面是普通的比较常见的service和log和自己的trees进行绑定，右侧可以看到有treesID，每一条日志都是和trees和service进行了天然的绑定，通过service可以查到log，通过log可以关联到service的内容，有log转Metrics，也有trees转Metrics以及trees和Metrics的关联，这是传统的三大核心数据结构之间的转换的过程，在此过程中发现不能100%的解决问题，在之前提出了event的概念，event作为外界的触发每一个事件比如新的部署、服务的启停或者上下游的性能问题都会作为event作为外界的影响因子评估性能的变化是由于自己的原因引起的还是其他的服务，这是需要关注的一个内容，后面有几个重要的点是带来的新的特性。
第一个要强调的是profiling，之前有提到像dibug工具的功能，但是APM系统随着云原生的整合能力很多profiling已经集成了APM内部是按需触发或自动剖析、交互式剖析、连续剖析的概念，第一个是Agent/SDK based profiling，通过普通监控应用的agent，通过获取线程的对战进行线程栈的剖析，profiling可以和某个请求进行完全的绑定比如-SMD的请求即便有一个请求执行的时间比较长，想要知道进程在哪里执行的时间长，方法之间是什么样的关系，这时最适合进行agent profiling，agent profiling是有上下文的可以单个请求进行非常严格的绑定关系比较适合agent，这是Skywalking构建自己的agent的原因。
现在有java agent和python agent已经支持SDK profiling，可以进行任务下发因为本身有业务消耗，需要时进行交互式的任务让后台指定某一个服务进行某个慢的profiling可以达到最终的方法定位的问题，可以看到下面有方法、行数、执行的次数、执行的时间，通过这些可以很明确的定位到是哪个方法耗时多少。
另一个是eBFP profiling，这是在很早之前就进行实践的，在今年发布了一个Skywalking-rover的eBPF的探针，主要是针对c、c++、Golang、Rust的survices,目前看到的是cpu消耗的profiling针对的是apache里的imword，同样是交互式的profiling，过程中间可以对CPU ON和CPU OFF两种状态进行profiling直到Cpu花在哪，上下文切换耗时、周围的资源是否消耗过多的等待的时间，这是常见的火焰图的消耗里面有占比、消耗时长、数量，这些都是非常常见的profiling。在下一步会进行更深入的比如大的功能迭代体系里面会做的事情比如setcar之间有网络的损耗，网络损耗耗的是消耗的太多或者等待的时间太长，这是natail profiling。
讲到的三个功能continue连续剖析和自动剖析的机制一起在需要的时候在云原生的环境里在需要的应用里进行剖析并且把当时的拍照、记录留下来，随时可以反向查找，这是profiling的情况，中间可以定位到一些方法级别的错误，同时可以看到eBFP profiling是全局的即进程级别的包括请求进程绑定，善于定位整个应用里面通用的短板，不针对单个请求。当然如果请求比较繁忙可以借用环境定位到其中的问题。
另外新发布的On Demand Logging，之前提到了Logging的收集和存储是很大的消耗，trees Metrics也是需要消耗的，既想看日志又不想有很大的消耗，云原生上有自己的选择系统，应用打出来的日志Metrics已经收集到，会进行实时的集成叫做On Demand Logging是一个零消耗，因为本身读取的数据不在skyworking里面而是在目标的Metrics上，所以当service被探针或者被应用或者被Metrics系统确定是OpenTelemetry上的应用，用port标识和space的标识，logging可以直接通过关联关系指定的service大的port的日志直接拽出并且显示在页面上，数据可以滚动的显示。
通过这种方式可以按需查看日志也可以进行关键字的过滤，滤出想要的日志，这些过程可以帮助用户在低成本的消耗下查看应用的日志的内容，只是对传统的持久化的日志的补充，如果已经用到云原生的系统可以考虑降低在收集日志的采样、消耗，尽量更多的采用logging模式得到最基础的信息。
