《2022云原生可观测性技术研究与应用.docx》由会员分享，可在线阅读，更多相关《2022云原生可观测性技术研究与应用.docx（60页珍藏版）》请在三一办公上搜索。
1、云原生可观测性技术研究与应用目录序言51.可观性概述81.1 TX原生可观测性发展81.2 可观测性定义92 .云原生可观测性成熟度102.1 监控112.2 基础可观测性112.3 因果可观测性142.4 主动可观测性183 .云原生观测体系能力构建213.1 云原生可观测性信号213.2 玄原生可观测能力构建283.3 核心能力-基于eBPF构建云原生数据采集技术334 .云原生可观测性应用场景404.1 故障分析404.2 事件预测404.3 日志审计414.4 监控474.5 微服务追踪504.6 安全检测分析535 .优秀云原生可观测项目介绍565.1 Prometheus项目565
2、.2 OpenTeIemetry项目595.3 SkyalkngIpl1163附件.引用文献67L可观测性概述1.1 云原生可观测性发展CNCF云原生定义对云生技术描述为：在现代动态环境（如公有云、私有云和混合云）中构建和运行可扩展的应用程序的能力。容器、服务网格、微服务、不可变基础设施和声明性APl均是基于云原生技术的特征。采用云原生技术使松散耦合的系统具有弹性、可管理和可观察性。结合强大的自动化功能，能够以最少的工作量频繁且可预测地进行高影响力的更改。Pivotal公司MattStine在2013年首次提出云原生概念。2017年MattStine将原生特征归纳为六大点，分别是： 模块化Mo
3、dularity 可观测性Observability 可部署性Deployability 可测试性Testability 可处理性Disposability 可替换性Replaceability作为六大特征之一的可观测性是保证云原生应用稳定性的基础。在云原生时代，应用规模不断扩大，复杂度愈来愈高，而其中潜藏的问题和风险也随之增多。这对支撑平台及业务自身的稳定性提出更高要求。能够支撑业务的快速迭代、故障快速响应能力、适应复杂的微服务拓扑、保证高效运维。在数字化大趋势下，云计算成为企业数字化转型的关键。以云上开发为核心的云原生技术得到了广泛的使用。云原生在企业上云和基础实施架构上的大量应用，也对企
4、业的运维监控安全提出了新的挑战。分布式、解耦合的新型系统架构，服务调用链长、系统行为复杂、软件系统稳定性保障困难，解决以上问题需要采用新的方式对系统进行观测。1.2 可观测性定义在控制理论中，“可观测性是从系统外部输出的数据衡量系统内部状态的程度”。可观测性是人类对机器可以观察、理解和处理所述系统状态的功能。可观测性是在没有考虑目标的情况下决定系统在实现时应该具有哪些输出。在IT领域，可观测性是在日志与监控指标组成的传统监控基础上，依据由日志、指标、链路追踪三种核心数据来洞悉系统运行状态。通过统一的链路追踪洞察系统服务调用链，并与日志、指标数据联动分析，可实现对云原生系统的高效故障定位与故障解
5、决，保障云原生系统稳定性。可观测性具有三个方面的特征，首先是度量能力，可观测性的度量能力能够帮助使用者在系统处于非常极端复杂的场景时，也能理解和解释系统当前的状态。其次是探索分析，可观测性不应该预定调试/排查模式和路径，而应该能够自由地对所有采集到的各类状态数据在各种维度和组合之间进行关联分析，不断探索分析出新的关联性。最后是按需改变，可观测性最好是在不改变原有代码的情况下，按需进行埋点。2.云原生可观测性成熟度研究可观测性成熟度模型的目标是提供一种可衡量、可复制的理论基础用以评估、改进可观测性体系能力。遵循PDCA模型通过对可观测性能力持续改进，提高对云原生系统的感知能力，缩短运维过程中寻找
6、根因、排除故障的时间。衡量和评估云原生系统可观测性的成熟度模型，可定义为如下四个级别：1.evel1监控(MOnitOring)1.evel2基础可观测性(BasicObservabiIity)1.evel3因果可观测性(CausalObservability)1.evel4主动可观测性(ProactiveObservability)可观测性成熟度模型的每个级别，建立在前一级别已实现的基础上。2.1 监控2.1.1 目标：确定系统组件是否按预期正常工作可观测性成熟度模型中，监控是第一个阶段。此阶段对资产、进程、资源使用等数据持续采样、度量和记录，获取实时或定期的信息和数据。跟踪单个系统组件的特
7、定参数，度量系统组件状态。系统组件运行状态如超出预设范围，触发警报、状态更改、通知。监控级的目标之一是设置实时警报，在系统出现问题或达到预定阈值时能够及时报警。2.1.2 能力在LeVell阶段，被监控的系统各组件之间无相关性，此级别主要目标是了解系统组件是否正常工作。监控级会开始对基本的性能数据进行采集，以确保系统在负载情况下不会受到显著影响。监控级的主要目标是建立起最基本的监控能力，以确保系统的基本稳定性和可用性。关键功能：系统输入：事件和组件级指标系统输出：报警、日志价值：获得基本信息，系统组件的健康状态出现问题时的警报和通知2.2 基础可观测性2.2.1 目标：确定系统故障可观测性通常
8、指基于对复杂系统外部输出的了解，能够了解其内部状态或状况的程度。系统越可观测，定位问题根本原因的过程就越快速越准确，而无需进行额外的测试或编码。为保证复杂动态的系统可靠运行，需要知道系统组件是否正常运行，还需要了解它为什么不运行。当出现问题时，希望遵循“5WIH”的原则了解问题详情：whowhen、wherewhat、why、how。1.evell监控措施基于预置规则实现告警、通知。预置规则依赖于一个关键性的假设，即能够在问题发生之前预测将会遇到的问题类型。这种方法不能覆盖足够多的场景，无法回答5W1H的问题。云原生环境是动态的、复杂的、多变的，无法事先预知可能会出现什么样的问题。因此云原生应
9、用下的可观测性方案，应可以根据更完整、更深入的可观测性数据，实时感知事件，并提供定位可能无法预料的问题根因的能力。可观测性成熟度LeVeI2相较于Level1的数据具有更大的广度和深度。可观测性系统主要关注三种关键类型的数据来提供系统洞察力：指标、日志和跟踪。可观测性的这三大支柱是从微服务、应用程序、数据库、云原生基础设施中收集的，旨在提供对系统行为的更为完整的视图。每种数据提供不同类型的信息： 指标：了解服务性能和状态的数值测量-四个黄金信号：延迟、流量、错误率和饱和度。 日志：了解系统在给定时间点的行为-统中发生的相关事件（例如事务、警告、错误）的时间戳记记录 追踪：解决性能问题-显示数据
10、如何从端到端流经应用程序的详细快照（例如，用户请求）可观测性强调数据的统一性，通过构建统一的平台来实现指标、日志和跟踪数据的汇聚与处理，突破单点工具的能力限制。建设统一数据平台可将各种可观测性工具整合在一个集中的界面，提高管理和维护系统的效率。通过手工关联数据来推断事件的可疑原因，需要跨系统手动查询。在Level2中，尚未涉及自动化方法来统一和关联来自各种工具汇聚的孤立数据，准确定位问题的根本原需要大量的人力投入。能力1.eVeI2阶段，理解可观测性数据之间的关系，将上下文数据结合。关键功能：系统输入：LeVel1+链路、指标、日志系统输出：LeVel1+图标、日志可视化综合仪表盘价值:通过从
11、更多来源收集数据，更深入、广泛、全面地了解整个系统健康状况，更好地支持问题诊断除已知故障类型外，还能够发现未知故障模式从各种类型的数据中获得有益的洞察力-例如，跟踪有助于识别性能瓶颈，指标可提供出色的KPI,日志可用于查找软件缺陷。2.3 因果可观测性2.3.1 目标：确定问题根本原因影响面及规避方法可观测性的核心价值在于提高排查问题的效率。可观测性工具通过分析数据，定位问题，进一步确认问题的根本性原因(RootCause)。可观测性体系用于因果判断，可以更深入全面地理解系统的运行和行为，得出系统中事件之间的因果关系。通过对因果关系分析理解，找出引发问题的根本性原因。具备因果分析能力的可观测性
12、体系可定义为“因果可观测性(CaUSalObservability)”。具备因果分析能力的可观测性体系，通过收集、分析和解析足够多维度的数据，达到理解系统内事件、状态变化之间的关系，从而更深入地洞察系统运行状态。因果可观测性强调在数据分析中寻找因果关系，并将这些关系转化为对系统事件之间关系的可视化呈现。因果可观测性与基础观测性有所不同，Level2强调数据，LeVeB强调关系。1.eVeI2基础可观测性关注收集、分析数据以理解系统的状态和行为，LeveB因果可观测性强调数据与数据、实体与实体、事件与事件或更多维度数据之间的联系。构建因果可观测性，涉及数据收集、关系收集、数据处理、关系处理、因果
13、推断等步骤，以揭示事件发生的因果过程。面对复杂性、不确定性和变化性的云原生应用场景，对事件因果的理解有助于更好地预测、解释、优化和管理系统。调查故障根因时，需收集事件发生的时间、空间、参数变化等数据，从而了解导致问题出现、传播，以及随着时间的推移而变化的事件状态。解决这些问题，需要引入新的能力：网络数据、拓扑数据、时间、空间地图、自动化关联技术。这些能力可以更全面地理解系统运行状态，定位问题的根本原因。为了建立因果可观测性，需要补充两种类型的数据要素：拓扑、时间。拓扑系统中各实体对象相互之间的连接关系（例如根据链路相关数据绘制的服务拓扑）时间持续抓取观测数据的时间维度表1两种类型数据要素拓扑是
14、因果可观测性的第一个必要维度。拓扑是IT环境中所有组件的映射，它跨越所有层，从网络到应用程序再到存储，显示一切是如何相关的。拓扑结合了组件之间的逻辑依赖性、物理接近性和其他关系，以提供人类可读的可视化和可操作的关系数据。拓扑信息（Topology）指的是系统中各主机、进程、容器、API、SerViCe之间的关系和连接方式。拓扑的价值在于提供系统的高级视图，帮助运维者理解不同实体之间的依赖关系、通信路径和层次结构。通过拓扑信息，能够更全面清晰地了解系统结构。拓扑信息在可观测性数据中扮演着一种定位和上下文的角色，辅助理解数据所涉及的组件、服务、资源以及它们之间的关系。拓扑信息是一个系统的结构图，展
15、示了系统内部各个元素之间的连接和依赖关系。这种结构图可以是物理上的（如网络拓扑、主机之间的连接），也可以是逻辑上的（如服务之间的依赖关系、数据流动路径）。将信息点连接至系统元素，使得每个维度的数据不是孤立的点。时间是因果可观测性的第二个必要维度。在充满微服务、云资源和容器不断变化的动态环境中，拓扑信息的变化是非常迅速的。系统状态可能在问题多次出现的过程中发生变化。为了确立因果可观测性，需要引入一个至关重要的维度：时间。为了深入了解现代IT环境的动态行为并获取实现因果可观测性所需的上下文。随着时间的推移，捕获拓扑信息的变化，并将其与可观测性数据进行关联，以跟踪整个堆栈的变化。当出现问题时，可以回
16、溯到问题开始的确切时间点，并查看是什么变化导致了这个问题。通过这种时间维度的关联，能够更准确地定位问题的根本原因，实现对问题的全面分析和解决。空间地图是拓扑的升维，提供IT环境中所有元素的关系映射，空间地图是一张三维的元素连接拓扑，涵盖水平的实体关系拓扑，垂直的依赖关系拓扑。空间地图结合了组件之间的逻辑依赖性、物理邻近性和其他关系，以提供可读的可视化和可操作的关系数据。水平拓扑：在相同类型的元素之间建立的连接关系地图，如进程到进程、服务到服务、主机到主机垂直拓扑：在不同类型的元素之间建立的连接关系地图，如数据中心到主机、主机到进程、进程到服务、服务到应用程序通过技术实现水平层、垂直层的空间地图
17、，自动化、实时性的绘制，将可观测性数据与空间地图的实体关联，拉动时间轴，展示随时间变化的空间拓扑、关联数据，能够比较变化前后的系统状态，是可观测性能力的集中式成果体现。2.3.2能力拓扑可以极大地提高因果判定的准确性和有效性，Level3对空间地图的引入是重大的进步。关键功能：通过拓扑为指标、链路、流量、日志提供上下文，随事件推移关联相关数据，追踪变化；系统输入：LeVeIl+Level2+网络+拓扑+时间系统输出：LeVeII+Level2+空间拓扑+数据关联+时序变化价值：通过统一时间序列拓扑中的孤立数据，获得统一、清晰、相关的环境状态上下文视图通过拓扑可视化和分析了解因果关系，显着加快根
18、本原因识别和解决时间基本自动化调查的基础，例如根本原因分析、业务影响分析和警报关联自动将与同一根本原因相关的警报集中在一起，从而减少噪音和干扰所需的上下文2.4主动可观测性目标：自动输出问题根因、自动化响应，智能预测、主动预防1.eVel4主动可观测性，典型特征是引入“AIOps”技术，通过自动化和智能化的方法实现更深入更准确的洞察力，将传统的被动式运维转变为主动式运维。将人工智能（AI）和机器学习（ML）技术融入到可观测性体系中。在这一阶段中，更加强调分析结果和答案，而不仅仅关注原始数据和分析过程。主动可观测性将分析结果呈现给用户，并辅助决策和采取行动。1.eVeI4主动可观测性建立在该成熟
19、度模型中因果可观测级别的核心功能之上。LeVeI4阶段添加了模式识别、异常检测和更准确的问题修复建议。对于主动可观测性而言，因果可观测性是一个必要的基础：时间序列拓扑提供了一个必要的框架。数据是原材料，原材料经过分析之后得出的答案。快速的把高质量结果和答案传达出来，快速做出决策、采取行动，是主动可观测性需要重点考虑的问题。任何一套可观测性解决方案或建设可观测性体系之前，都应解决三个最本质的问题： 通知：在问题出现并造成影响前后，能够在多快的时间内得到通知？ 诊断：能迅速地对问题进行分类，了解影响？ 理解：如何找到潜在的原因以快速解决问题？AlOPS利用因果关系，使用基于拓扑驱动的渐进式故障树分
20、析算法。AIOps具备强大的拓扑绘制能力，实时获得基础架构、流程和服务依赖关系的可视化关系，更好地理解系统的运行情况和交互关系。AIoPS依托拓扑地图、云原生系统产生的数据进行分析，能显示一个事件在垂直和水平方向的拓扑依赖关系，能够自动确定异常问题的根源。在Level4阶段，目标是关注更高效且无事故的IT运维。可观测系统基于Al/ML算法模型，感知服务或组件偏离正常行为的趋势，并在出现故障之前采取措施规避问题。对未发生事件的预测能力是LeVeI4阶段可观测系统的典型特征。2.4.2能力1.evel4,目前是IT技术领域中最高的可观测性成熟度级别。需要拓扑和时间提供的额外上下文，准确评估根本原因
21、、确定业务影响、检测异常并主动确定何时提醒SRE和DeVOPS团队。关键功能：系统输入：LeVelI+Level2+Level3+大数据分析/ML模型系统输出：LeVelI+Level2+Level3+空间拓扑+自动化RCA+预测价值：自动根因定位、自动化RCA、告警降噪、预测异常；借用Gartner2022年3月InnovationInsightforObservability文章中的一段话作为本章总结：“发现异常很容易，因为它们一直都在发生。当每天收集十亿个事件时，每两分钟就会发生一百万分之一的事件。可观测性工具的关键是发现与手头问题相关的异常，然后从可能相关的日志文件/指标中链接其他信息
22、。通过在上下文中显示相关信息，操作员可以更快地找出问题的潜在根本原因。-GartneruInnovationInsightforObservability,2022Mar,PadraigByrne&JoshChessman.3.云原生观测体系能力构建3.1云原生可观测性信号事件日志不是完全云原生可观测性的实现依赖于监控指标/监控度量（Metrics）、（Logs）和链路追踪（TraCeS）三种数据类型。这三种数据各有侧重,独立，三种数据之间有重合或者可以结合之处。RSMCKry SyuxlsVolumef3.1.1指标指标是数据的数字表示形式。它们分为两大类：已经是数字数据和提炼（聚合）成数字
23、的数据。前者的一个例子是温度，后者例如在Web服务器上观察到的HTTP请求计数器。数字是存储数据的最有效方式，随着时间的推移，所有成熟的行业都趋向于指标优先。指标的典型示例用例衡量主机（例如虚拟机）堆内存使用情况的仪表。我们称之为“堆内存字节”。指标由一个名称、一组标签（有时称为属性或标签）和每个时间点的数值（例如每秒一个值）组成。每个具有特定名称和标签的指标实例通常称为“时间序列”或“流”。3.1.2日志事件日志（Logging）：日志的职责是记录离散事件，应用运行过程会持续输出日志数据，这些日志数据是业务系统运行状态的各种事件及业务处理逻辑时输出的，通过这些记录事后分析出程序的行为，基本上
24、可以还原业务流程处理的全过程。事件日志可以详细解释系统的运行状态，但是存储和查询需要消耗大量的资源。日志是描述操作系统、应用程序、服务器或其他设备中的使用模式、活动和操作的一个或多个文本条目。日志可以分为不同的类别，例如： 应用程序日志应用程序内部事件创建的记录。日志可帮助开发人员了解和评估应用程序在运行过程中的行为模式。 安全日志-事件与系统中检测规则匹配后创建对该事件的记录。包括登录失败、密码更改、资源访问、资源更改、策略更改、发生时间。安全管理员通过安全日志可回溯与检测规则匹配的事件。 系统日志系统日志记录操作系统中的事件，包括处理物理和逻辑设备的内核级消息、引导顺序、用户或应用程序身份
25、验证以及其他活动、故障、资源状态消息。 审核日志事件和更改的记录。记录执行活动人员、执行活动内容以及系统如何响应。系统管理员根据业务需求确定审核日志收集内容。安全管理员可根据审核日志回溯人员对系统的使用。 基础架构日志涉及管理影响组织IT基础的物理和逻辑设备。在本地或云中通过API、SySIOg、主机代理收集获取。日志记录应用程序或系统在发生故障时的状态,在执行根本原因分析时，这些记录特别有价值。存储在日志中的信息是自由格式的文本，因此很难得出含义。在过去的30年中，已经进行了许多尝试将架构应用于日志，但它们尚未特别成功。使用统一架构的原因使提取相关信息更易于访问。通常是通过解析、分段和分析日
26、志文件中的文本来完成的。日志数据还可以转换为其他可观测性信号，指标和跟踪。一旦数据成为指标，它就可以用于了解随时间的变化。日志数据还可以通过日志分析技术进行可视化和分析。基于对数据获取不同颗粒度，日志可设置不同级别：“错误”、“警告”、“信息”和“调试”。错误是最不详细的日志级别，调试是最详细的日志级别。错误：传达发生情况并详细说明发生故障的原因 警告：需要注意的高级消息，不一定是失败信息 消息：系统的工作状态 调试：存储每个操作的详细信息。通常，仅在故障排除期间或具备充足得存储或性能而短期使用。3.1.3追踪链路追踪（TraCing）：链路追踪大都是依据谷歌在2010年发表的论文Dapper
27、:aLarge-ScaleDistributedSystemsTracingInfrastructureDapper理论来实现的，调用链记录的是串联单个事务内全过程的日志数据，通过对请求打标、透传、串联，最终可以还原出一次完整的请求，可以帮助工程师轻松分析出请求中异常点。但是链路追踪和事件日志一样有着相同的问题就是资源消耗较大，通常也需要通过采样的方式减少数据量。为了有效地进行分布式追踪，DaPPer提出了追踪（TraCe）与跨度（Span）两个概念：追踪（TraCe）：从客户端发起请求抵达系统的边界开始，记录请求流经的每一个服务，直到到向客户端返回响应为止，这整个过程就称为一次追踪O跨度(S
28、pan)：由于每次Trace都可能会调用数量不定、坐标不定的多个服务，为了能够记录具体调用了哪些服务，以及调用的顺序、开始时点、执行时长等信息，每次开始调用服务前都要先埋入一个调用记录，这个记录称为一个跨度。DaPPer使用以跨度为基本树节点的跟踪树构建跟踪模型，并为每个跨度记录了一个可读的spanname,spanid,parentid,这样就能重建出一次分布式跟踪过程中不同跨度之间的关系。没有parentid的跨度被称为根跨度。一次特定跟踪的所有相关跨度会共享同一个通用的traceid。换句话说每一个追踪实际上都是由若干个有顺序、有层级关系的跨度所组成一颗追踪树(TraceTree),如下
29、图2所示：(time)20图2追踪树1追踪（TraCing）通常表示一个具体的事务实例，即计算机通过特定程序的路径，使它们成为可观察性中的详细且昂贵的信号。跨度（SPanS）高度情境化，需要进行上下文关联。除此之外，跨度（SPanS）还记录有关启动它的“父”跨度（SPanS）的信息。这使得在分布式系统的不同参与者（如服务、队列、数据库等）之间建立因果关系成为可能。3.13.1 基于日志的追踪数据收集基于日志的追踪的思路是将Trace,SPan等信息直接输出到应用日志中，然后根据收集到的日志数据，从全局日志信息中反推出完整的调用链拓扑关系。基于日志的追踪数据收集的优点在于其对网络消息完全没有侵入
30、性，对应用程序只有很少量的侵入性，对性能影响也非常低。但其缺点是直接依赖于日志归集过程,日志本身不追求绝对的连续与一致，这也使得基于日志的追踪往往不甚精准。另外，业务服务的调用与日志的归集并不是同时完成的，也通常不由同一个进程完成，有可能发生业务调用已经顺利结束了，但由于日志归集不及时或者精度丢失，导致日志出现延迟或缺失记录，进而产生追踪失真。Dapper的跟踪记录和收集管道实现如下图所示，共分为三个阶段：1 .把SPan数据写入到本地日志文件2 .Dapper守护进程和采集器从主机中将日志他们拉取出来3 .将拉取出的日志写入DaPPer的BigtabIe仓库中，其中BigtabIe中的行表示
31、一次跟踪，列表示一个spaotraceidspan12span23span34span45span56123456nilnilni,246802nilnilEl357913nilnilnilnil.图3Dapper工作流程23.13.2 基于服务的追踪数据收集基于服务追踪的实现思路是通过某些手段给目标应用注入追踪探针(Probe),通过探针获取服务调用信息并发送给链路追踪系统。探针在结构上可视为一个寄生在目标服务身上的小型微服务系统，它一般会有自己专用的服务注册、心跳检测等功能，有专门的数据收集协议，把从目标系统中监控得到的服务调用信息，通过另一次独立的HTTP或者RPC请求发送给追踪系统。基
32、于服务的链路追踪劣势在于比基于日志的追踪消耗更多的资源，也有更强的侵入性。基于服务的链路追踪优势为这些资源消耗换来收益的直接结果是精确性与稳定性均有所保证，从而不必再依赖日志归集作为追踪数据的来源。基于服务的追踪被ZipkinSkyWaIking、PinPoint等追踪系统广泛采用。3.2云原生可观测能力构建3.2.1 信号关联有两种基本方法可以关联数据：运维人员建立或者利用现有数据建立相关性。应该对所有的信号使用相同的元数据结构。尽可能对日志使用相同的标签。如有必要，运维人员可自建标签，附加到所有类型信号的数据。连续收集所有可观测性信号，每条数据的范围都标记为某个时间戳。在不同的维度上，每个
33、可观测性信号都需要绑定到某个“目标”，能够查看目标的指标、跟踪和日志三个维度可观测性数据。通过一致的元数据来切换来自同一目标（例如，同一应用程序）的可观测性信号。利用基于拉取的系统，如PrometheUS或OPenTeIemetryPrometheUS接收指标，利用日志收集器（OpenTeIemetryFluentdFluentbit）收集日志。确保收集器附加一组一致的目标标签或属性，例如“集群”、“namespace、”IabeI“、“Pod”。在处理OTLP（指标、日志和跟踪）等多维度集合数据时，应用附加目标标签信息，确保数据一致性。运维人员可以基于相同的标签，在不同的可观测性信号之间切换
34、。允许从每个信号中选择与特定过程、组件、时间相关的信息，从而快速浏览具有相同标签信号的细节内容。日志中共享与请求相关的相同信息（请求ID、操作ID）o确保日志记录和跟踪的这些ID是相关联的，从而确保数据可基于事件请求ID紧密地相互关联。运维人员能够通过跟踪绑定到单条日志的请求ID标签，快速定位日志。3.2.2 典型业务架构可观测性业务架构可分为以下五层（数据源、数据采集层、数据存储层、应用展示层、智能化层）。五层架构可作为可观测性建设的内容，也是当前大多数企业正在实践的部分。典型可观测性业务架构如下图4所示:i 淅 -1PromThanoS或COrteX查看。服务拓扑是通过数据流向和调用关系，
35、以Ul的方式将服务依赖关系拓扑呈现出来。实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。可以在服务拓扑查看应用在指定时间内的调用及其性能状况。监控告警是最常用的场景，也是目前建设可观测系统的核心目标。监控告警通过事前配置好阈值，数据采集上来后通过计算与阈值比对，对于不符合规则要求的数据生成告警事件，通过告警渠道发送到目标设备。对于可观测性数据的应用除以上几项外，还可尝试将三者的数据进行关联，使同一个应用不同维度的事件立体化的展示出来。如请求发生异常时，应用一般会将请求以日志的方式输出，调用链路也会上报调用异常，这两类数据可以通过ReqUeStID或TraCeID进
36、行关联。3.2.2.5 智能化将人工智能和大数据应用于可观测性，辅助运维实现自动化、智能化，以达到业务服务高效稳定运行的目的。智能分析依托大数据和人工智能技术对采集的日志、指标和链路数据进行分析，按需产生有价值的结果。智能分析的主要应用有趋势预测、根因分析和智能决策三类不同场景。 趋势预测：预测可能会发生的事件； 根因分析：确定事件发生的根本原因； 智能决策：基于根本原因后提供智能决策的解决方案。3.3核心能力基于eBPF构建云原生数据采集技术随着大量应用基于云原生技术进行开发、适配和迁移，应用出现微服务激增、多语言开发、多通信协议特征，系统架构复杂度越来越高，传统可观测方法存在采集数据粒度不
37、够细致、资源消耗量大、外部代码侵入等问题。近年来，业界开始关注Iinux内核eBPF技术，独有特性能更有效地解决发展中问题。3S1Linux内核eBPF技术原理eBPF起源于LinUX内核，可以运行沙箱程序，安全有效地扩展内核功能，无需更改内核源代码或加载内核模块。eBPF全称“扩展的伯克利数据包过滤器(ExtendedBerkeleyPacketFilter),是一种数据包过滤技术，从BPF(BerkeleyPacketFiIter)技术扩展而来。BPF提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，这就让非内核开发人员也可以对内核进行控制。随着LinUX内核的发展，BPF逐步从
38、最初的数据包过滤扩展到网络、内核、安全、跟踪等，而且它的功能特性还在快速发展之中，这种扩展后的BPF被简称为eBPFoeBPF是基于寄存器的虚拟机，使用自定义的64位RlSC指令集，在Linux内核运行即时本地编译的eBPF程序。eBPF程序并不像常规的线程那样，启动后就一直保持运行，它需要由事件触发后才会执行。这些事件包括系统调用、内核跟踪点、内核函数和用户态函数的调用退出、网络事件，等等。借助于强大的内核态插桩（kprobe）和用户态插桩（IIPrObe）,eBPF程序几乎可以在内核和应用的任意位置进行插桩。eBPF程序通常包括4部分： 后端代码：在内核中加载和运行的eBPF字节码，它将数
39、据写入内核map和环形缓冲区的数据结构中； 加载器：它将字节码后端加载到内核中，当加载器进程中止时，字节码会被内核自动卸载； 前端代码：从数据结构中读取数据，并将其显示给用户 数据结构：后端和前端的通信手段。它们是由内核管理的map和环形缓冲区，可以通过文件描述符访问。需要在后端被加载之前创建，数据会持续存在，直到没有更多的后端或前端进行读写操作eBPF程序的运行流程，如下图5所示：图5eBPF程序的运行流程1.用户态编写RBPF程序2 .使用LLVM编译成bytecode的ELF文件3 .使用bpf系统调用，把程序加载进入内核4 .内核的Verifier会验证eBPF程序的合法性，确保其能够
40、安全、合规地在内核中运行5 .内核会使用JITcompiler把eBPF字节码编译成本地机器码6 .eBPF程序在内核中以VM方式安全运行332基于eBPF云原生可观测性技术架构云原生环境中每台机器（或虚拟机）只有一个内核，所有运行在该机器上的容器都共享同一个内核，内核了解主机上运行的所有应用代码。通过对内核的检测，基于eBPF可以同时检测在该机器上运行的所有应用程序代码。当将eBPF程序加载到内核并将其附加到事件上时，它就会被触发，而不考虑哪个进程与该事件有关。eBPF能够对基于广泛的可能来源的可视化事件的定制指标进行收集和核内聚合。基于eBPF在操作系统内核特性优势，与OPenTeIeme
41、try结合实现云原生观测数据收集处理的架构，极大增强云原生环境可观测性能力。基于eBPF的可观测性架构如下图6：图6基于 eBPF的可观测性架构可观测性 分析平台关键点在eBPF采集数据导入OpenTelemetryCoIIector,步骤如下:1数据接收：在kubernetes集群节点上基于eBPF的tracepoint和kprobe/kretprobe,将内核采集到的应用请求、系统调用、网络传输性能等数据放到内存中，在用户态eBPF程序读取数据，进行预处理；基于OpenTeIemetry规范实现Receiver,以事件订阅方式接收采集数据；2数据处理：基于C）PenTeIemetry规范实
42、现Processor,对采集数据进行协议解析和指标处理评估，然后填充kubernetesmetadata（元信息），实现eBPF采集的内核数据与kubernetes调度请求、上下文信息关联；3数据导出：基于OPenTelemetry规范实现Exporter数据导出到可观测平台进行分析。基于eBPF实现云原生可观测性数据采集具有以下优势：1 .能够采集更加全面的数据，数据指标覆盖从程序调用、网络传输性能、网络协议栈性能、服务黄金指标等各个层面；2 .资源消耗占比小，eBPF程序以本机机器指令运行，性能很高，基于内核进行数据采集，对应用零侵入、零改造；3 .更加灵活具备可伸缩性，eBPF程序可以在运行时动态附加到系统中，无需重新启动目标系统；4 .能够轻松应对容器启动、停止等动态
