OTel可观测性
可观测性 什么是可观测性？ 马克·安德森（Marc Andreessen）说过这样一句话：“软件正在吞噬世界 ”。这句话发表于2011年，但是十多年后的今天，我想它更好的演绎应该是“云原生正在吞噬世界，万物皆可上云”。面对云原生这个新赛道，BAT、美团、字节跳动、快手等一线大厂都在加速推进业务的容器化、云原生化。 也正是由于各大厂商对云原生的奔赴，传统的技术架构面临着巨大的冲击，我们的监控对象也由传统的单体结构，变成了分布式的多个微服务。监控，被架到了一个不得不革自己命的位置。在这样的背景之下，可观测性（Observability）脱颖而出。 CNCF 早在定义云原生的概念时就提到了可观测性 ，它声称可观测性是云原生时代的必备能力。而随着可观测性的概念明晰化，相关产品纷纷涌现，“可观测性”越来越成为云原生一个绕不开的话题。 在计算机系统和软件领域，可观测性的含义：它可以从系统和应用对外输出的信息（包括你可能已经知道的指标、日志和链路），来帮助我们了解应用程序的内部系统状态和运行情况。 可观测性能够架起开发人员和运维人员构建合作的桥梁，运维人员使用可观测性来发现问题，给故障现场提供足够的数据让开发人员进行分析，而开发人员可以使用可观测性来指导运维人员定位问题，并使用工具来质疑和验证假设； 从单机电脑时代的Windows任务管理器，Linux一堆Top、PS等命令帮助我们知道操作系统的运行转台；再到局域网时代的C/S架构、互联网时代的B/S架构的网络监控工具；再到如今移动互联网时代，出现了大量的可观测性技术。ELK方案、基于时序数据库的监控软件（如Prometheus、Telegraf + InfluxDB 等，APM 则出现了 ZipKin、Jaeger、Pinpoint、Skywalking 这些软件）然而，如果我们要完整地“观测”一个互联网系统，还是需要将各种形态的开源监控产品组合起来使用。 OpenTelemetry 这个组织的出现标志着业界意识的产生，也就是，我们需要将系统的可观测性变成一种统一的标准和规范。OpenTelemetry 致力于推动更多的应用和服务遵循这一规范，同时也会提供相应的可观测性能力。这也是我们今天这节课的重点 Metrics 指标 是对一段时间内基础设施或应用程序的数值数据的汇总。由于指标最大的特点是聚合性，它生成的数值反映了预定义时间段内系统状态的汇总报告，在此期间处于活动状态的所有请求的行为都会汇总为一个数值，因此缺乏细颗粒度。同时这些指标很可能都是彼此不相关的，没有关联性。 Log 日志 是一种带时间戳的文本记录，可以是结构化，也可以是非结构化的。 结构化日志 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 { "timestamp": "2024-08-04T12:34:56.789Z", "level": "INFO", "service": "user-authentication", "environment": "production", "message": "User login successful", "context": { "userId": "12345", "username": "johndoe", "ipAddress": "192.168.1.1", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" }, "transactionId": "abcd-efgh-ijkl-mnop", "duration": 200, "request": { "method": "POST", "url": "/api/v1/login", "headers": { "Content-Type": "application/json", "Accept": "application/json" }, "body": { "username": "johndoe", "password": "******" } }, "response": { "statusCode": 200, "body": { "success": true, "token": "jwt-token-here" } } } 非结构化日志 ...