十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Apache SkyWalking 8.1.0 版本全解析:Meter 系统、Kafka 传输层与 Java Agent 增强

Apache SkyWalking 8.1.0 版本全解析:Meter 系统、Kafka 传输层与 Java Agent 增强 Apache SkyWalking 8.1.0 版本全解析Meter 系统、Kafka 传输层与 Java Agent 增强【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalkingApache SkyWalking 8.1.0 是该系列中承上启下的一个重要版本其核心贡献在于为指标采集引入了全新的Meter 系统原生 Metrics API 与 Spring Sleuth 适配、将Kafka 扩展为可选的 Trace/JVM 指标/Profiling 快照/Meter 数据传输层并补齐了JVM 线程指标这一关键可观测性维度。本篇文章基于官方 changes-8.1.0.md 变更记录结合当前仓库源码与配置文件逐项拆解该版本在 Java Agent、OAP-Backend、UI 与安全层面的全部改动帮助你理解每个特性的实现位置与配置方式。一、版本总览8.1.0 的三大主线8.1.0 的变更集中在四个模块——Project项目级能力、Java Agent、OAP-Backend、UI外加一轮 CVE 安全修复。其中最具长期影响的三项为Kafka 成为可选的数据传输层支持承载 Trace、JVM 指标、Profiling 快照与 Meter 数据为大规模部署下「Agent → Kafka → OAP」的解耦架构铺路Meter 系统的诞生从这一版本起SkyWalking 拥有了统一的第三方指标接入框架后续的 Prometheus/OTel 指标接收器均建立在此之上JVM 线程指标上线OAP 侧新增ServiceInstanceJVMThread数据源并在 OAL 中定义了一整套线程状态指标。二、Meter 系统统一的指标接入框架2.1 什么是 Meter 系统8.1.0 在项目级新增了Meter 系统包含两层能力原生 Metrics API为 Java Agent 侧提供直接上报自定义指标的 API 通道Spring Sleuth 适配让使用 Spring Cloud Sleuth 的存量应用可以无缝将 Metrics 数据接入 SkyWalking。从 OAP 侧源码结构看Meter 系统的核心实现在 meter-analyzer 模块其关键类包括Analyzer.javaMeter 分析入口负责将接收到的 Sample 数据按规则转换为 OAP 内部指标MetricConvert.java按MetricRuleConfig规则执行指标转换PrometheusMetricConverter.java定义了一整套 Metric 表达式 DSL 的解析与执行位于 dsl 下的Expression、Sample、SampleFamily等类构成了表达式求值的运行时。2.2 MeterSystem 的指标创建机制OAP 核心模块中定义了 MeterSystem它是一个注册到模块管理器的 Service。其核心方法是create(String metricsName, String functionName, ScopeType type, ClassT acceptance)见 MeterSystem.java 附近负责根据指标名与聚合函数如sum、avg、percentile等动态创建指标流通过MetricsStreamProcessor.getInstance().create(...)将指标注册进流处理框架提供acceptableValue机制约束可接收的数据类型。AnalyzerTest见 AnalyzerTest.java使用spy(new MeterSystem(moduleManager))的方式对表达式求值与指标创建流程进行了完整单元验证可作为理解 Meter 系统行为的最佳测试样本。2.3 Meter 接收端与配置在 OAP 启动配置 application.yml 中Meter 接收模块默认启用receiver-meter: selector: ${SW_RECEIVER_METER:default} default:对应的 gRPC 服务端实现位于 skywalking-meter-receiver-plugin其中的MeterServiceHandler与MeterServiceHandlerCompat分别处理不同版本的 Meter 上报协议。规则配置示例可参考 meter-analyzer-config/config.yaml。三、Kafka可选的 Trace 与指标传输层8.1.0 将 Kafka 从单纯的「日志/指标采集」扩展为Trace、JVM 指标、Profiling 快照与 Meter 数据的可选传输层即 Agent 不再必须直连 OAP而是先写入 Kafka再由 OAP 的 Kafka Fetcher 消费入库。OAP 侧消费端配置在 application.yml 的kafka-fetcher段kafka-fetcher: selector: ${SW_KAFKA_FETCHER:-} default: bootstrapServers: ${SW_KAFKA_FETCHER_SERVERS:localhost:9092} namespace: ${SW_NAMESPACE:} partitions: ${SW_KAFKA_FETCHER_PARTITIONS:3} replicationFactor: ${SW_KAFKA_FETCHER_PARTITIONS_FACTOR:2} enableNativeProtoLog: ${SW_KAFKA_FETCHER_ENABLE_NATIVE_PROTO_LOG:true} enableNativeJsonLog: ${SW_KAFKA_FETCHER_ENABLE_NATIVE_JSON_LOG:true} consumers: ${SW_KAFKA_FETCHER_CONSUMERS:1} kafkaHandlerThreadPoolSize: ${SW_KAFKA_HANDLER_THREAD_POOL_SIZE:-1} kafkaHandlerThreadPoolQueueSize: ${SW_KAFKA_HANDLER_THREAD_POOL_QUEUE_SIZE:-1}关键参数说明参数环境变量默认值作用selectorSW_KAFKA_FETCHER空默认关闭置为default即启用 Kafka 消费端bootstrapServersSW_KAFKA_FETCHER_SERVERSlocalhost:9092Kafka Broker 地址列表partitionsSW_KAFKA_FETCHER_PARTITIONS3为各类数据 Topic 创建的分区数replicationFactorSW_KAFKA_FETCHER_PARTITIONS_FACTOR2Topic 副本因子consumersSW_KAFKA_FETCHER_CONSUMERS1每个 Topic 的消费者数量kafkaHandlerThreadPoolSizeSW_KAFKA_HANDLER_THREAD_POOL_SIZE-1自动消费处理线程池大小Fetcher 的具体实现位于 kafka-fetcher-plugin其测试用例kafka-fetcher-plugin 的 test 目录覆盖了 Trace、Meter、日志等多种数据类型的消费链路。使用前提Agent 端需配套配置 Kafka 上报插件如 kafka-plugin且 OAP 与 Agent 两侧的namespace需保持一致以保证 Topic 命名对齐。四、JVM 线程指标补齐线程维度可观测性4.1 数据源定义8.1.0 在 OAP 核心模块新增 ServiceInstanceJVMThread.java 数据源Scope 名ServiceInstanceJVMThread包含以下字段liveCount存活线程数daemonCount守护线程数peakCount峰值线程数runnableStateThreadCount/blockedStateThreadCount/waitingStateThreadCount/timedWaitingStateThreadCount按 JVM 线程状态细分的计数。4.2 OAL 指标定义对应指标在 java-agent.oal 中一次性补齐instance_jvm_thread_live_count from(ServiceInstanceJVMThread.liveCount).longAvg(); instance_jvm_thread_daemon_count from(ServiceInstanceJVMThread.daemonCount).longAvg(); instance_jvm_thread_peak_count from(ServiceInstanceJVMThread.peakCount).longAvg(); instance_jvm_thread_runnable_state_thread_count from(ServiceInstanceJVMThread.runnableStateThreadCount).longAvg(); instance_jvm_thread_blocked_state_thread_count from(ServiceInstanceJVMThread.blockedStateThreadCount).longAvg(); instance_jvm_thread_waiting_state_thread_count from(ServiceInstanceJVMThread.waitingStateThreadCount).longAvg(); instance_jvm_thread_timed_waiting_state_thread_count from(ServiceInstanceJVMThread.timedWaitingStateThreadCount).longAvg();由此UI 侧可直接通过「实例 JVM 线程」面板观测live、daemon、peak以及 Runnable / Blocked / Waiting / TimedWaiting 各状态线程数的实时曲线辅助排查线程池耗尽、锁竞争、死锁等问题。Agent 侧采集入口为 JVMSourceDispatcher.java负责将 Agent 上报的线程快照分派为上述 Source。五、Java Agent 增强逻辑端点与插件矩阵5.1 核心机制逻辑端点Logic Endpoint8.1.0 引入逻辑端点Logic Endpoint概念任何被特定 Tag 标记的 Span 或 Span Tag 都可以被 OAP 识别并聚合为一个逻辑端点进行分析。其测试用例 RPCAnalysisListenerTest.java 给出了两种典型用法局部 Span 标记给 Local Span 打上logic-span: true的 TagOAP 即将其 operation name如/logic-call作为端点来源扩展逻辑服务 Tag通过扩展 Tag如name: /GraphQL-service声明逻辑端点名称适用于 GraphQL 这类「一个 HTTP 端点承载多种业务语义」的场景。实现层面SpanTags.java 负责解析逻辑端点相关 TagRPCAnalysisListener.java 在其监听流程中完成逻辑端点到EndpointSource 的转换EndpointGroupingRule.java 则负责将逻辑端点名归并到分组规则。这一能力让 SkyWalking 可以分析 GraphQL、gRPC 等非传统 REST 语义下的「业务端点」。5.2 插件矩阵扩展8.1.0 新增/增强的 Java Agent 插件包括新增插件GraphQL、Quasar fiber协程、InfluxDB Java client、brpc百度 RPC 框架MySQL 插件增强新增对Call procedures存储过程调用的 Trace 支持logback v1 插件支持ConsoleAppendervert.x 插件优化端点命名Spring 注解组件名仅为 UI 可视化提供组件名称标注。5.3 核心稳定性修复[Core] 并发类加载器Concurrency ClassLoader并发访问 Bug 修复解决多线程场景下类加载器缓存的竞态问题[Core] 插件配置与核心层解耦插件配置从 core 层独立出来便于按插件单独管理[Core] 增强类缓存内存或文件支持将插桩类缓存到内存或文件中从而与 Arthas 等其他 Agent 共存对应 FAQ 文档 EnhanceRequireObjectCache-Cast-Exception.md 讨论的类增强兼容问题修复项WebFlux 插件并发访问 Bug、ShardingSphere 插件内部冲突、Spring MVC 端点重复、lettuce 插件偶发缺失 Span 层级、TagreturnedObject 取值 Bug、Mongo 语句过长优化。六、OAP-Backend 增强健康检查、采样与端点关系指标6.1 Jetty Server 高级配置OAP 支持对 Jetty Server 的线程池、连接数、超时等高级参数进行配置用于调优 gRPC/HTTP 接收端的吞吐与稳定性。6.2 OAP 与存储模块健康检查新增OAP 健康检查与存储模块健康检查运维侧可通过健康检查接口探测 OAP 进程及底层存储ES/MySQL 等的存活状态配合 backend-health-check.md 文档使用。6.3 动态配置中的采样率采样率支持通过动态配置中心下发运维人员可在运行时动态调整 Trace 采样比例无需重启 OAP。采样机制的策略文件入口见 application.yml 中的traceSamplingPolicySettingsFile与forceSampleErrorSegment配置采样开启时可强制保留部分错误 Segment。6.4 端点关系 SLA 与百分位指标8.1.0 为端点依赖关系EndpointRelation补齐了两个关键指标定义于 core.oalendpoint_relation_cpm from(EndpointRelation.*).filter(detectPoint DetectPoint.SERVER).cpm(); endpoint_relation_resp_time from(EndpointRelation.rpcLatency).filter(detectPoint DetectPoint.SERVER).longAvg(); endpoint_relation_sla from(EndpointRelation.*).filter(detectPoint DetectPoint.SERVER).percent(status true); endpoint_relation_percentile from(EndpointRelation.rpcLatency).filter(detectPoint DetectPoint.SERVER).percentile2(10); // Multiple values including p50, p75, p90, p95, p99endpoint_relation_sla端点依赖的成功率按status true计算百分比endpoint_relation_percentile端点依赖延迟的百分位p50 / p75 / p90 / p95 / p99。这两个指标直接支撑了 UI 侧新增的Endpoint Dependency Graph端点依赖图让「上游调用下游的延迟与成功率」可量化呈现。默认仪表盘模板见 general-endpoint-relation.json。6.5 组件注册扩展Python 插件组件Kafka、Tornado、Redis、Django、PyMysqlGolang SDK 组件随 Go Agent SDK 引入。6.6 集群协调与配置中心Nacos 1.3.1 回归重新支持 Nacos 作为可选的集群协调器与动态配置中心此前版本因兼容性问题移除Kubernetes ConfigMap 配置中心支持使用 k8s ConfigMap 作为动态配置中心见 cluster-kubernetes-plugin 及 dynamic-config-configmap.md集群协调配置入口集中在 application.yml 的cluster段支持standalone、zookeeper、kubernetes、consul、etcd等模式。6.7 存储与查询修复ES 查询增强提升指标查询稳定性修复searchServiceBugPrometheus 标签修复修复 Prometheus 分析上下文中标签缺失问题MySQL/TiDB修复列长度问题缩短自可观测性场景下的存储实体名长度修复模糊查询 SQL 注入详见下文 CVEInfluxDB修复时间桶time bucket转换问题修复二级聚合无数据、端点关系实体查询校验错误、OAL debug 标志引发的 Bug、MQ 与无探针代理场景下的端点依赖 Bug依赖升级k8s client 升级至 8.0.0。七、UI 与文档改进UI新增端点依赖图Trace/Profile 页面支持横向滚动x-scroll修复数据库选择器问题UI 模板新增柱状图类型bar chart文档新增后端配置词汇表 configuration-vocabulary.md、Windows 下 Tomcat9 安装 Agent 指南、istioctl ALS 命令文档修正 TTL 文档新增线程插桩 FAQMemory-leak-enhance-Worker-thread.md 同主题更新用户 Logo 墙。八、CVE 安全修复8.1.0 修复了一例安全漏洞MySQL/TiDB 存储中的模糊查询 SQL 注入。此前在基于模糊匹配的查询场景下用户输入可能被拼接进 SQL 语句造成注入风险该版本对查询参数做了正确的转义与参数化处理。升级建议使用 MySQL/TiDB 作为存储的用户应尽快升级到 8.1.0 或更高版本。九、升级与验证建议升级路径8.1.0 属于 8.x 早期版本升级前请参考 v8-version-upgrade.md 了解 8.x 系列的主要变更验证 Kafka 链路依次启用 Agent 侧 kafka-plugin 与 OAP 侧kafka-fetcher确认 Trace/指标经 Kafka 正确入库验证 Meter 系统使用 Spring Sleuth 应用或自定义 Metrics API 上报数据观察receiver-meter是否正常接收并在 UI 呈现验证线程指标在实例 JVM 面板确认instance_jvm_thread_*系列指标曲线出现安全MySQL/TiDB 存储用户确认已应用模糊查询注入修复。小结8.1.0 虽是一个增量版本却为 SkyWalking 后续的指标生态Prometheus/OTel 接收器、MQE 表达式与消息队列解耦架构奠定了基础。理解本版本的 Meter 系统、Kafka 传输层、JVM 线程指标与逻辑端点机制对掌握后续 8.x/9.x 的核心设计有直接的承接价值。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表