xiaohack's Blog - 可观测性
type: channel
link: https://blog.xiaohack.org/tag/5357fd95-a7a5b0/
items: 解锁可观测性密码：一文掌握观测云日志监控器超能力
items: Envoy 可观测性实战：日志、指标与链路追踪的完整落地
items: 阿里云 RocketMQ 4.0 可观测最佳实践
items: 直播预告 | 多智能体协同下的可观测产品体系化演进
items: 全栈监控与告警设计——从SLO到告警规则，避免告警雪崩的分级体系
items: 阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
items: 阿里云全新发布的 UModel 是什么
items: 观测云接入 Zabbix 数据最佳实践
items: 艾体宝方案 | 重塑智能汽车OTA：构建全球级、高可靠、可观测的软件分发与管理系统
items: 掌握核心方法论，打造高质量业务仪表板

解锁可观测性密码：一文掌握观测云日志监控器超能力
type: item
date: 2026-02-02T18:10:40+08:00
description: 观测云提供一站式云、云原生、应用及业务的可观测解决方案，日志监控器是其核心功能之一，它不仅仅是一个被动的日志收集和存储工具，更是一个主动、智能的日志分析与监控告警平台。它的设计目标是帮助开发、运维和业务团队从海量的日志数据中快速发现问题、定位根因并及时响应。日志监控器的核心价值在于将非结构化的日志数据转化为可观测的结构化信息，并通过监控和告警机制，使其成为保障系统稳定性和业务连续性的有力工具。通知对象观测云支持向钉钉、企业微信、飞书等渠道发送通知，使用时需要先创建通知对象。点击「监控」 -「通知对象管理」-「新建通知对象」。填写消息推送机器人的 Webhook 地址。告警策略点击「监控」 -「告警策略管理」-「新建告警策略」。通过关联监控器与告警策略，系统可在异常发生时即时向指定对象发送通知。策略支持配置名称、描述、时区与操作权限等基础信息，并允许按告警等级、通知对象两个维度灵活定义通知规则。针对高紧急度场景可启用升级通知机制，同时支持自定义通知发送时段，以适配不同时段的业务需求。日志监控器「监控」 -「监控器」-「新建监控器」，选择“日志检测”，依次配置“检测配置”、“事件通知”、“告警配置”。检测配置如下图是按主机和服务的维度，统计 5 分钟内 mall-admin 服务中状态是 error 的日志条数。当错误数大于等于 2 条时触发致命告警。事件内容支持自定义事件通知的标题与内容。插入日志变量点击"变量"选择需要展示的变量名，比如 host、service。插入链接点击“链接”插入日志查看地址，实现告警界面一键跳转到观测云。附加信息点击"添加附加信息"选择日志字段（如 message），在告警内容中展示。点击“变量”插入 {{df_related_data.message}}，建议截取前200字符避免超出告警工具长度限制。告警策略配置告警策略后，系统将向对应对象发送通知。恢复事件连续两个周期无异常触发恢复事件，留空则不发送。告警通知告警触发后，事件中心关联事件的“通知”列显示企微图标即表示推送成功。在企微机器人群收到如下信息。问题排查企微未收到告警时，请在“事件中心”查找对应事件：无事件：检查监控器DQL配置事件存在但通知列无企微图标：检查通知对象与静默期设置通知列有企微图标：可能因告警过于频繁触发Webhook限流无事件排查打开监控器，复制上方的 DQL。复制出来的 DQL 如下：window("L('default')::RE(`.*`):(count(`*`)) { `service` = \"mall-admin\" AND `status` = \"error\" } BY `service`, `host`", '5m')打开「快捷入口」 -「DQL 查询」，粘贴 DQL，去掉外层的 windows 函数，去掉转义，检测区间选择和监控器相同，点击“执行”。如果无数据则不会触发告警。

Envoy 可观测性实战：日志、指标与链路追踪的完整落地
type: item
date: 2026-01-26T11:20:30+08:00
description: 前言本节详细聊一下基于envoy的可观测性日志首先是日志，配置日志的方式也很简单static_resources: listeners: - name: ingress_listener address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress_http ... access_log: - name: envoy.access_loggers.stdout typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog log_format: text_format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %BYTES_SENT% %DURATION% %REQ(X-REQUEST-ID)% \"%REQ(USER-AGENT)%\" \"%REQ(X-FORWARDED-FOR)%\" %UPSTREAM_HOST% %UPSTREAM_CLUSTER% %RESPONSE_FLAGS%\n" 该配置是将日志输出在控制台，也可以直接输出为文件，然后通过工具采集走path: /var/log/envoy/access.log也可以直接将日志输出至kafka，并且按比例采集、只采集4xx、5xx等都可以配置，这里就不在赘述了admin管理页面envoy有默认的admin页面，方便查看统计信息、打开某些功能的开关等admin: address: socket_address: address: 0.0.0.0 port_value: 9901 打开9901页面：可以查看相关的统计信息、也可以打开某些开关，功能还是很丰富的merics接入prometheus打开了admin之后，就默认提供了相关的prometheus stats http://10.105.148.194:9901/stats/prometheus这时只需在k8s集群外弄一个prometheus，并且采集该envoy即可prometheus.ymlglobal: scrape_interval: 5s evaluation_interval: 5s rule_files: - /etc/prometheus/*.rules scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: "envoy" metrics_path: /stats/prometheus static_configs: - targets: ["10.105.148.194:9901"] docker run -d --name prometheus \ -p 9090:9090 \ -v ./prometheus.yml:/etc/prometheus/prometheus.yml \ -v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime \ registry.cn-beijing.aliyuncs.com/wilsonchai/prometheus:v3.5.0traces接入jaegerjaeger的安装可以参考这里： opentelemetry全链路初探--埋点与jaegerjaeger启动之后，改造一下envoy的配置，这里要特别注意，不同版本的配置不一样，我这里envoy的版本是：v1.32static_resources: listeners: - name: ingress_listener filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: ... tracing:…

阿里云 RocketMQ 4.0 可观测最佳实践
type: item
date: 2026-01-23T18:04:15+08:00
description: 阿里云 RocketMQ 4.0 介绍阿里云 RocketMQ 4.0 产品是阿里云早期基于 Apache RocketMQ 构建的分布式消息中间件，主要面向企业级消息传递和异步解耦场景。RocketMQ 4.0 在发布时已具备高吞吐、低延迟、可扩展的核心特性，支持顺序消息、事务消息、定时/延时消息等多种能力，帮助开发者快速实现系统间的可靠通信。相比更高版本，RocketMQ 4.0 在弹性伸缩、可观测性和集成易用性方面能力有限，更多依赖人工运维和监控工具。但通过合理部署与监控，仍能够满足大多数分布式系统的消息传递需求，为业务提供基础的高可用性和可靠性保障。观测云观测云是一款专为 IT 工程师打造的全链路可观测产品，它集成了基础设施监控、应用程序性能监控和日志管理，为整个技术栈提供实时可观察性。这款产品能够帮助工程师全面了解端到端的用户体验追踪，了解应用内函数的每一次调用，以及全面监控云时代的基础设施。此外，观测云还具备快速发现系统安全风险的能力，为数字化时代提供安全保障。采集方法登录观测云控制台点击【集成】菜单，选择【云账号管理】点击【添加云账号】，选择【阿里云】，填写界面所需的信息，如之前已配置过云账号信息，则忽略此步骤点击【测试】，测试成功后点击【保存】，如果测试失败，请检查相关配置信息是否正确，并重新测试点击【云账号管理】列表上可以看到已添加的云账号，点击相应的云账号，进入详情页点击云账号详情页的【集成】按钮，在未安装列表下，找到阿里云 RocketMQ 4.0，点击【安装】按钮，弹出安装界面安装即可。关键指标Metric IdMetric NameDimensionsStatisticsUniReadyMessages已就绪消息量(Group)account_name,InstanceNameAverage,MaximumcountReadyMessagesPerGidTopic已就绪消息量(Group&Topic)account_name,InstanceNameAverage,MaximumcountReceiveMessageCountPerGid消费者每分钟接收消息数量(Group)account_name,InstanceNameAverage,Maximumcount/minReceiveMessageCountPerGidTopic消费者每分钟接收消息数量(Group&Topic)account_name,InstanceNameAverage,Maximumcount/minReceiveMessageCountPerInstance消费者每分钟接收消息数的数量(Instance)account_name,InstanceNameAverage,Maximumcount/minReceiveMessageCountPerTopic消费者每分钟接收消息的数量(Topic)account_name,InstanceNameAverage,Maximumcount/minSendDLQMessageCountPerGid每分钟产生死信消息的数量(Group)account_name,InstanceNameAverage,Maximumcount/minSendDLQMessageCountPerGidTopic每分钟产生死信消息的数量(Group&Topic)account_name,InstanceNameAverage,Maximumcount/minSendMessageCountPerInstance生产者每分钟发送消息数量(Instance)account_name,InstanceNameAverage,Maximumcount/minSendMessageCountPerTopic生产者每分钟发送消息数量(Topic)account_name,InstanceNameAverage,Maximumcount/minThrottledReceiveRequestsPerGid每分钟(GroupId)消费被限流次数account_name,InstanceNameAverage,Maximumcounts/minThrottledReceiveRequestsPerGidTopic每分钟(GroupId&Topic)消费被限流次数account_name,InstanceNameAverage,Maximumcounts/minThrottledReceiveRequestsPerInstance每分钟(Instance)消费被限流次数account_name,InstanceNameAverage,Maximumcounts/minThrottledSendRequestsPerInstanc…

直播预告 | 多智能体协同下的可观测产品体系化演进
type: item
date: 2026-01-23T15:44:13+08:00
description: 伴随多智能体系统的规模化落地与技术迭代，其跨智能体交互的动态性与决策链路的黑箱特性，使AI协作的复杂度呈指数级攀升。传统可观测体系以指标、日志、链路等系统运行数据为核心，主要解答“系统发生了什么？”的问题。但当面对多个自主决策、动态交互的AI智能体时，我们更需要解答：“智能体为何这样决策？”、“协作是否高效合理？”以及“如何保证结果可靠与成本可控？”等难题。多智能体不仅改变了应用架构，更从根本上对可观测性的深度与广度提出了新的要求：如何打通从数据获取、分析到决策的完整价值链，形成高效闭环？当自动配置、智能见解等核心能力孤立运行时，如何实现它们的协同联动，以精准应对复杂运维场景？又该如何突破当前自动化诊断的瓶颈，稳步迈向预测性干预与系统自愈的高阶智能化阶段？Bonree精彩直播，码上预约为深入探讨这一命题，博睿数据特别推出【前瞻2026：可观测技术风向与趋势洞察】专题直播，直播分为上下两期。下期直播，我们聚焦于可观测性产品本身的演进路径：1月28日（周三）14:00，博睿数据产品中心高级产品经理马倩，将带来 《多智能体协同下的可观测产品体系化演进》主题分享。本次直播将从实际产品视角出发，聚焦可观测性产品的演进路径，从产品内核、协同逻辑到突破方向，展开全方位、深层次的拆解与分析。博睿宏远，将在01月28日 14:00 直播已预约多智能体协同下的可观测产品演进本次直播我们将深入探讨技术趋势，助力大家洞悉多智能体时代可观测性领域的全新挑战与技术走向。立即预约直播，解锁多智能体协同下可观测产品体系化演进，获取该领域关键认知与演进逻辑！

全栈监控与告警设计——从SLO到告警规则，避免告警雪崩的分级体系
type: item
date: 2026-01-22T18:01:33+08:00
description: 写在前面，本人目前处于求职中，如有合适内推岗位，请加：lpshiyue 感谢。同时还望大家一键三连，赚点奶粉钱。本系列已完结，完整版阅读课联系本人现代分布式系统的可观测性不是简单的数据收集，而是基于业务目标的智能过滤与决策体系在掌握了风险可控的发布策略后，我们需要解决一个更根本的问题：如何准确判断发布是否成功？如何在海量监控数据中识别真正重要的信号？全栈监控与告警设计正是连接系统状态与人工干预的关键桥梁。本文将从SLO定义出发，深入探讨监控指标体系构建、告警规则设计、分级抑制策略的全链路实践，帮助企业构建既敏感又精准的可观测体系。1 监控体系的哲学转变：从数据收集到价值判断1.1 传统监控的局限性：数据丰富而洞察匮乏传统监控系统面临的核心矛盾是数据收集能力与价值提取效率之间的巨大鸿沟。随着微服务和云原生架构的普及，单个系统产生的指标数量呈指数级增长，但运维团队能够有效处理的告警数量基本恒定。监控数据的三个价值层次：基础指标：CPU、内存、网络等资源消耗数据（容易收集但价值有限）应用性能：请求延迟、错误率、吞吐量等业务相关指标（需要业务埋点）用户体验：真实用户感知的可用性和性能（最难测量但最具价值）根据行业数据，未经验证的监控告警中超过70%属于噪音或误报，导致团队产生"告警疲劳"，反而忽略真正重要的异常信号。1.2 SLO：监控价值的锚点Service Level Objective（服务等级目标）为监控系统提供了价值判断的基准。SLO将模糊的"系统健康"概念转化为可量化的目标，成为区分信号与噪音的核心依据。SLO的核心价值在于：目标一致性：使技术指标与业务目标对齐优先级判断：基于错误预算确定问题处理的紧急程度资源分配：根据SLO达成情况指导稳定性投入# SLO定义示例：API服务可用性目标 api_service_slo: availability: 99.9% # 每月最多43分钟不可用 latency_p95: 200ms # 95%请求延迟低于200ms error_rate: 0.1% # 错误率低于0.1% rolling_period: 30d # 滚动计算周期为30天2 全栈监控体系构建：从基础设施到用户体验2.1 监控数据的三位一体现代监控体系需要整合指标（Metrics）、日志（Logs）、追踪（Traces） 三类数据，形成完整的可观测性能力。指标监控提供系统量化度量，适合趋势分析和阈值告警：基础资源指标：CPU、内存、磁盘、网络（通过Node Exporter采集）应用性能指标：QPS、延迟、错误率（通过应用埋点暴露）业务指标：订单量、支付成功率、用户活跃度（自定义业务埋点）日志分析记录系统详细行为，用于故障排查和审计：结构化日志收集（Filebeat/Fluentd）日志聚合与检索（Elasticsearch）模式识别与异常检测（机器学习分析）分布式追踪提供请求全链路视角，优化性能诊断：请求级跟踪（Jaeger/SkyWalking）服务依赖拓扑自动发现瓶颈分析与链路优化2.2 监控数据采集的技术选型Prometheus生态已成为云原生监控的事实标准，其拉取模型和多维数据模型特别适合动态环境。# Prometheus配置示例 scrape_configs: - job_name: 'api-service' static_configs: - targets: ['api-service:8080'] metrics_path: '/metrics' scrape_interval: 15s # 指标Relabeling，增强元数据 relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: blackbox-exporter:9115多数据源整合是大型系统的必然选择。Zabbix适合传统基础设施监控，Prometheus擅长云原生环境，商业方案如CloudWatch提供开箱即用体验。2.3 监控数据建模与存储优化监控数据的时序特性要求专用存储方案。Prometheus TSDB适合短期数据存储，长期存储需考虑Thanos、Cortex或M3DB等分布式方案。数据降采样策略对成本控制至关重要：原始数据：保留2天，15秒精度5分钟聚合数据：保留30天1小时聚合数据：保留1年日级别聚合数据：永久保留3 从SLO到告警规则：精准告警的数学基础3.1 错误预算：SLO的可操作化表达错误预算将SLO转化为可消耗的资源，为告警触…

阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
type: item
date: 2026-01-22T16:32:58+08:00
description: 作者：杨易（青风）在云原生可观测性领域，OpenTelemetry 已经成为事实上的标准。相比于 Java 拥有成熟的字节码增强技术，Go 语言作为静态编译型语言，长期以来缺乏一种成熟、低侵入的自动插桩方案。目前的现有方案主要有：eBPF：功能强大但主要偏向系统调用层面，对应用层上下文（如 HTTP Header 传播）的处理较为复杂。手动埋点：代码改动大，维护成本高，不仅要改业务代码，还得改依赖库的调用方式，显式地在各个关键节点添加 Trace 和 Metrics 逻辑。为此，阿里云可观测团队和程序语言团队探索了 Go 编译时插桩解决方案，并将其核心能力捐赠给 OpenTelemetry 社区，形成了 opentelemetry-go-compile-instrumentation [ 1] 项目。在和 Datadog、Quesma 等公司的共同努力下，我们发布了首个预览版本 v0.1.0 [ 2] 。工作原理自动插桩工具的核心在于利用 Go 编译器的 -toolexec 参数。-toolexec 会拦截 Go 编译命令，替换成我们的插桩工具。这样，在代码被编译之前，我们就有机会对它进行分析和修改。整个过程可以概括为两个阶段：1. 依赖分析在编译开始前，工具会分析应用的构建流程（go build -n），识别出项目中使用的第三方库如 net/http, grpc, redis 等。然后，它会自动生成一个文件otel.runtime.go，将对应的 Hook 代码（监测逻辑，后面用 Hook 代码表示）引入到构建依赖中。2. 代码注入当编译器处理目标函数时，工具利用 -toolexec 拦截编译，然后修改该目标函数的代码，在函数入口插入一段蹦床代码（Trampoline Code），蹦床代码会跳转到预先写好的 Hook 函数中。进入函数前（Before）：Hook 记录开始时间，提取上下文信息（如 HTTP Headers），启动 Span。函数执行：执行原有的业务逻辑。退出函数后（After）：Hook 捕获返回值或 Panic，结束 Span，记录耗时。这种方式的优点是零运行时开销（除了必要的监测逻辑执行时间），因为插桩是直接编译进二进制文件的，不需要像 eBPF 那样在内核态和用户态之间切换，也不需要像 Java Agent 那样在启动时加载。HTTP 插桩示例让我们通过一个简单的 HTTP 例子来看看它是如何使用的。package main import ... func main() { http.HandleFunc("/greet", func(w http.ResponseWriter, r *http.Request) { w.Write([ ]byte("Hello, OpenTelemetry!")) }) log.Fatal(http.ListenAndServe(":8080", nil)) }手动插桩需要手动引入 OpenTelemetry SDK，手动创建 Tracer，在 Handler 里手动 Start 和 End Span。package main import ... func initTracer() func(context.Context) error { /* ...几十行初始化代码... */ } func main() { // 1. 初始化 Tracer shutdown := initTracer() defer shutdown(context.Background()) // 2. 包装 Handler handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // 3. 手动提取 Context，开始 Span tracer := otel.Tracer("demo-server") ctx, span := tracer.Start(r.Context(), "GET /greet") // 4. 确保结束 Span defer span.End() // 5. 可能还需要手动记录属性 span.SetAttributes(attribute.String("http.method", "GET")) w.Write([]byte("Hello, OpenTelemetry!")) }) // 6. ListenAndServe 也可能需要包装... log.Fatal(http.ListenAndServe(":8080", handler)) }对于成百上千个接口的微服务，这种改造成本是灾难性的。自动插桩下载工具：到 Release 页面 [ 2] 下载编译应用：./o…

阿里云全新发布的 UModel 是什么
type: item
date: 2026-01-22T16:20:28+08:00
description: 作者：望宸每个时代基础设施的变革，都始于对“混乱”的优雅重组。19 世纪，钢铁把不可控的垂直空间变成工程秩序，城市才得以向上生长；20 世纪，电网将分散的能源重新编排，工业生产才不再被河流左右。而如今的 IT 领域，我们正面临一场新的秩序重建，即如何让海量、碎片化、动态变化的观测数据，不再是噪音，而成为可理解、可推理、可优化智能体行为的燃料？要回答这个问题，我们先简单回溯下：IT 系统的可观测体系是如何走到今天的？IT 系统中可观测体系的发展最初，企业面向单一数据类型构建监控体系，CPU 使用率、内存占用、磁盘 I/O……一个个孤立的指标就像烽火台，只能通过局部视角告诉我们“什么地方出了问题”。但随着微服务、容器技术的普及，系统复杂度呈指数级增长。企业开始意识到：单点指标无法解释全局。于是开始对孤立的数据进行抽象，抽象出 Metrics（指标）、Traces（链路追踪）和 Logs（日志），并进行关联分析：Metrics： IT 系统是否有问题；Traces： 哪里出了问题；Logs： 问题是由什么原因导致的。发展至今，成为观测体系的三大数据支柱。但从海量、异构、动态变化的数据中准确推理并定位问题，本质上是一个极其困难的逆向工程。数据只是现象，而现象与本质之间往往存在巨大的认知鸿沟 [ 1] 。Metrics、Traces 和 Logs 这看似完整的三角，实则仍停留在现象观测层面，是 L1 级智能体的典型工作流，人工设计流程节点、人工配置触发、人工调用 API，再把指标、链路、日志喂给 AI，期望它自己找出因果，结果往往是幻觉式归因：把时间上的巧合当作逻辑上的因果。为什么？因为在 AI 面前，缺少对系统本质的建模。在 AI 时代，加剧了这种模式的挑战。一是 LLM 驱动的应用带来了上下文的碎片化。运维工程师每天要在不同的控制台之间切换，手动拼凑“发生了什么”。这就像在信息高速公路上骑自行车，工具很先进，但认知方式仍是人力驱动。二是相比由工程师写的代码定义的传统 IT 系统，AI 带来了更多的不确定性，指数级提升了原始数据自动化关联的难度，给准确推理并定位问题的挑战添了堵。总结起来，原本的认知鸿沟，被进一步分化成三层新的鸿沟 [ 2] ：数据鸿沟：原始数据混杂、碎片化、噪声多，99% 以上可能是无效信息，难以从中有效提取信号。模型鸿沟：AI 模型存在“黑盒”特性，推理过程难以解释；还可能出现“幻觉”，生成看似合理但不符合事实的结果。工程鸿沟：每天数 PB 级的数据采集、清洗、存储、计算，对性能、成本、安全性提出极高要求。数据到建模让一个没见过电路图的人，从一堆电压表读数中定位并恢复故障服务器，是不现实的。当前市面上大多数的 AI 运维助手，本质上仍是 L1 级智能体：它们被封装在一个封闭的对话框里，被动响应用户提问，背后是一连串预设的 if-else 规则或简单 RAG 检索。它们没有对系统结构的内生理解，无法主动推理依赖路径，更谈不上安全执行修复操作。而要迈向 L2 甚至 L3 级智能体，即能自主感知、规划、行动并持续学习的数字员工，就必须为其构建一个结构化的运行时上下文，不然只能靠人的经验来排查、定位和解决问题。这个上下文是经过建模、带有语义、支持查询与推理的图谱。有了这张图，智能体就能避免在数据海洋中盲目打捞，而是在一个有路标、有规则、有边界的城市中穿行。因此，出路不在更多的数据，而在更好的建模。先为 IT 系统建立一张认知地图。这张图要包含实体（主机、服务、数据库）、关系（调用、依赖、部署）、行为（日志事件、性能指标）以及它们之间的语义约束。只有在这张图上，智能体才能像经验丰富的老运维一样，快速定位故障并恢复生产。UModel 正是这张图的建模语言。我们需要从“数据驱动”转向“建模驱动”，从面向现象的观测，转向面向本质的建模，构建一个统一的上下文图谱，这正是 UModel 的使命。什么是 UModelUModel（Universal Observability Model）是基于图模型的可观测数据建模方法。又是图模型，又是建模，一听就很学术。通俗易懂的讲，就是用“画图”的方式，把一堆随机事件之间的概率关系理清楚，让复杂变简单，让模糊变清晰。因此，UModel 旨在通过标准化的数据建模方式，实现可观测数据的统一表示、数据建模与具体存储的解耦，从而实现智能分析。有了 UModel，智能体才能像经验丰富的老运维那样快速定位故障并恢复生产，成为可能。UModel 可以看成是阿里云可观测体系的数据建模基础。总的来讲，UModel 的核心思想，是为可观测领域打造一个认知操作系统，是一套标准化的数据建模方法，旨在弥合前文所述的三重鸿沟，为 AIOps 提供可解释、可扩展、可自动化的基础。接下来，我们从 UModel 的构成和使用方式来…

观测云接入 Zabbix 数据最佳实践
type: item
date: 2026-01-21T18:27:40+08:00
description: Zabbix 介绍Zabbix 是一个开源的企业级监控解决方案，它可以监控各种网络参数，服务器健康状态，应用程序性能等，并提供灵活的告警机制和丰富的报表功能。1、Zabbix Server核心组件，负责接收和处理所有监控数据，生成报警和报表。需要一个数据库来存储所有配置和监控数据。2、Zabbix Agent部署在被监控的设备上，负责收集本地资源和应用数据，并发送给 Zabbix Server。支持多种操作系统，包括 Linux、Windows 和 Unix。其中 Agent 分为 Zabbix Agent 和 Zabbix Agent 2，后者是增强版 Agent，支持插件，适合大规模监控。3、Zabbix Proxy用于分担 Zabbix Server 的负载，尤其适用于大规模分布式监控。可以在远程网络中收集数据并转发给 Zabbix Server。4、Zabbix Web Interface基于 PHP 的 Web 界面，用于配置、管理和查看监控数据。提供用户管理、权限控制、仪表盘和报表等功能。5、数据库存储所有的配置、监控数据、历史记录等。支持多种数据库，如 MySQL、PostgreSQL、Oracle、SQLite。观测云观测云是一款专为 IT 工程师打造的全链路可观测产品，它集成了基础设施监控、应用程序性能监控和日志管理，为整个技术栈提供实时可观察性。这款产品能够帮助工程师全面了解端到端的用户体验追踪，了解应用内函数的每一次调用，以及全面监控云时代的基础设施。此外，观测云还具备快速发现系统安全风险的能力，为数字化时代提供安全保障。部署 DataKitDataKit 是一个开源的、跨平台的数据收集和监控工具，由观测云开发并维护。它旨在帮助用户收集、处理和分析各种数据源，如日志、指标和事件，以便进行有效的监控和故障排查。DataKit 支持多种数据输入和输出格式，可以轻松集成到现有的监控系统中。（注意，请安装完整版 DataKit，Lite 版本 DataKit 没有 Zabbix 相关采集器。）登录观测云控制台，在「集成」 - 「DataKit」选择对应安装方式。这里使用主机方式安装。复制一键安装命令，登陆到目标服务器执行该命令即可实现一键安装。执行 datakit monitor 命令查看 DataKit 运行状态。指标数据采集Zabbix API 方式（zabbix >= 5.0)DataKit 方式1、配置 pythond 配置文件进入 DataKit 的配置文件目录 conf.d，进入 pythond 目录，复制 pythond.conf.sample 为 pythond.conf, 修改如下配置：inputs.pythond # Python input name name = 'zabbix_collect' # required # System environments to run Python #envs = ['LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH',] envs = ['ZABBIX_HOST=http://127.0.0.1/zabbix', 'ZABBIX_USER=Admin', 'ZABBIX_PASSWD=zabbix', 'ZABBIX_VERSION=7.0', 'COLLECT_TYPE=api'] # Python path(recomment abstract Python path) cmd = "python3" # required. python3 is recommended. # Python scripts relative path dirs = ["zabbix"]其中 ZABBIX_HOST，ZABBIX_USER，ZABBIX_PASSWD，ZABBIX_VERSION 填写实际 Zabbix 的地址用户名密码和版本。保存并退出。2、复制脚本进入 DataKit 目录，进入 python.d 目录，创建 zabbix 目录，点击下方链接下载脚本到 zabbix 目录下：https://static.guance.com/integrations/zabbix/zabbix-collecto...3、重启 DataKitdatakit service -R4、检查采集任务，出现 zabbix_collect 任务则说明采集任务开启成功datakit monitorFunc 方式1、安装采集脚本登录 Func，点击「脚本市场」，选择预装脚本市场，点击管理按钮，进入预装脚本市场的脚本列表页。在过滤搜索框中输入 ，过滤出 zabbix 采集脚本。点击安装按钮，并在弹出的确认框点击确认按钮。点击确认…

艾体宝方案 | 重塑智能汽车OTA：构建全球级、高可靠、可观测的软件分发与管理系统
type: item
date: 2026-01-21T09:52:37+08:00
description: 摘要软件定义汽车（SDV）的时代，空中升级（OTA）能力已从“功能”演进为汽车的“生命线”。它承载着功能迭代、安全修复与用户体验提升的核心使命。然而，面对千万级的庞大车队、GB级的升级包体、跨洲际的网络环境以及绝对零容忍的升级安全要求，传统OTA架构在效率、可靠性与智能化方面面临严峻考验。本方案提出，以Redis企业版为核心实时数据引擎，构建新一代智能OTA平台。该平台不仅能够实现升级包的全球分钟级同步与智能边缘分发，更能支撑全链路可观测的灰度发布与秒级触达的安全回滚，将OTA从一项高风险运维活动，转变为稳定、高效、可运营的数字化服务。一、OTA演进下的核心挑战现代智能汽车OTA已超越简单的“推包安装”，成为一个复杂的分布式系统工程：挑战一：分发规模与成本的指数级增长：单一车型的软件版本可能超过100GB，而一次全量升级活动需覆盖百万辆汽车。采用中心化分发将产生天量的跨境带宽成本与漫长的下载时间，用户体验难以保障。挑战二：灰度发布与流量调控的精细化管理：为控制风险，升级必须遵循从1%到100%的精细化灰度节奏。平台需要实时、动态地管理海量车辆的分组、策略与状态，并能根据故障指标（如安装失败率、系统崩溃率）自动决策暂停或回滚，这对状态管理和决策实时性要求极高。挑战三：升级安全的“零信任”与“可追溯”：升级过程必须保证数据的完整性（包体未被篡改）、原子性（要么完全成功，要么完全回退）和可审计性（每一步操作皆有记录）。任何环节的纰漏都可能导致车辆“变砖”，引发大规模安全事故。二、Redis企业版：OTA系统的智能数据中枢Redis企业版凭借其独特的技术组合，成为化解OTA复杂性的战略性组件：全球智能分发网络基石：Active-Active地理分布式部署支持升级包元数据与任务指令在全球多个数据中心间实时同步，为构建私有化、低延迟的内容分发网络提供了数据层基础。结合自动分层（Auto Tiering） ，可将高频访问的最新升级包置于内存，将历史版本透明下沉至SSD，实现性能与成本的最佳平衡（存储成本降低约70%）。高性能、高可靠的任务编排引擎：Redis Stream 与 Sorted Set 数据结构是构建复杂任务队列的理想选择。它们能够以毫秒级延迟管理数百万车辆的升级状态流转（待推送、下载中、安装中、成功/失败），并支持基于优先级、区域、车型等多维度的灵活调度。全链路可观测性与自动化触发器：Redis TimeSeries 模块可高效存储和聚合全量升级过程的性能指标与日志。RedisGears 的函数功能允许在数据库内部设置复杂触发器，例如，当“安装失败率”在5分钟内超过0.1%时，自动暂停当前批次任务并告警，实现从“监控”到“动作”的闭环自动化。坚如磐石的数据持久化与高可用：通过同步持久化（AOF with fsync always） 与跨区域复制，确保每一次任务分配、每一条车辆状态更新都不会丢失。其99.999%的高可用性保障了OTA管理控制面自身7x24小时不间断服务。架构方案：云边协同的智能OTA平台以下架构描绘了以Redis企业版为“智能中枢”的下一代OTA平台，如何协同云端与边缘，完成从包管理到安全回滚的全流程。核心工作流解析：升级包全球同步与边缘预热：新的升级包在“包工厂”生成并完成签名后，其元数据（版本号、车型、依赖、哈希值）通过 Active-Active 同步至全球所有区域的Redis集群。智能调度器根据各区域车辆分布，将包体文件提前推送至各边缘节点Redis集群的SSD层。当车辆发起下载请求时，边缘节点可快速从本地SSD或内存提供服务，下载速度提升300% 以上。精细化灰度发布与实时调控：运维人员在控制台创建升级任务，定义灰度批次（如：内部员工1% -> 先锋用户5% -> 全面推送）。该任务被转化为一个主任务Stream和多个批次Sorted Set（按车辆VIN分片）。智能调度器作为消费者，从Stream中读取任务，并根据规则从相应批次的Sorted Set中获取车辆列表，通过Pub/Sub或指令通道向车辆下发升级通知。车辆端上报的每一个状态（下载进度、安装结果）都实时更新到该车辆对应的状态Hash中。RedisGears 脚本持续监控聚合指标，一旦触发预设规则（如失败率超标），则自动修改任务状态或触发回滚流程。安全回滚与全链路追溯：回滚被设计为一个标准的“升级任务”，其回滚包已在边缘节点就绪。当自动或手动触发回滚时，调度器会优先为受影响车辆创建高优先级的回滚任务。整个升级生命周期的所有事件（任务创建、指令下发、状态变更、异常告警）均作为时间序列数据存入 Redis TimeSeries，并与具体的车辆VIN、任务ID关联，提供毫秒级精度的全链路追溯能力，满足最高级别的审计要求。关键场景与价值量化结语在软件…

掌握核心方法论，打造高质量业务仪表板
type: item
date: 2026-01-20T13:51:48+08:00
description: 前言在数字化运维与业务监控的实践中，仪表板（Dashboard）与汽车的仪表盘同等重要，它不仅是数据可视化的载体，更是团队快速定位问题、洞察数据趋势的核心工具。观测云在平台中内置了大量通用组件、云服务的仪表板模板。但如果你希望从零开始构建个性化的仪表板，又或者对自己绘制的仪表板不够满意，那么这篇文章将教授你几个小技巧，帮助你有效提升仪表板的质量。观测云简介观测云是一个统一实时监测平台，它提供全面的系统可观测性解决方案，帮助用户快速实现对云平台、云原生、应用及业务的监控需求。观测云的核心功能包括：基础设施监测，日志采集和分析，用户访问监测（RUM），应用性能监测（APM），服务可用性监测（拨测），安全监测，智能监控等等。这款产品能够帮助工程师全面了解端到端的用户体验追踪，了解应用服务的每一次调用，以及全面监控云时代的基础设施。此外，观测云还具备快速发现系统安全风险的能力，为数字化时代提供安全保障。更多信息可以访问观测云官网：https://www.guance.com基础仪表板的绘制让我们进入到观测云，创建一个属于您自己的仪表板。首先，你需要找到仪表板的入口「场景」-「仪表板」，点击「新建仪表板」-「新建空白仪表板」。其次，可以从侧滑窗口中选择适合展示数据的图表类型，拖拽到左边的空白画布中。以常用的「时序图」为例，拖动到画布中即可打开「新建图表」弹窗，此时通过数据筛选控件来选择需要展示的指标。如图所示，我们已经展示了一条指标曲线，它代表的含义为：指标集为 cpu，指标名为 usage_total，按照 host 进行分组并统计 Avg 平均值，只显示 host=DESKTOP-F9E75IG 的值（过滤条件），点击右下角的保存即可。此时你已经完成了第一张图表的制作，通过一张张图表的叠加，你很快能得到一个完整的仪表板，不过它看上去有些简陋，我们需要更多技巧对仪表板的美观程度和易读性进行优化。仪表板的优化新增标题和描述恰当的标题能让用户第一时间知道图表展示的指标及其含义，而图表的描述能够起到有效补充说明。我个人的习惯是将图表名设置为指标的英文名，然后在「描述」中补充该指标的中文含义。如下所示：保存生效的效果如下，图表左上角将展示标题，而鼠标 hover 到帮助按钮上则会悬浮显示描述。数据单位一部分指标在采集到观测云后没有单位，因此在绘制仪表板时需要注意补充单位。别名图表的曲线会显示对象的名称，并且对象名称会随着分组条件的增多而变得复杂。例如下图，由于添加了 namespace，pod_name 等多个分组条件，对象名称显得很长，很不直观。好在我们可以通过配置「别名」来简化对象名称的显示。在图表配置的「别名」处，我们选择对应的指标序列，并用 {{}} 将分组条件包起来作为变量，例如下图中的分组条件 pod_name 就写为 {{pod_name}} ，效果如下所示。我们也支持用多个变量作为别名，写法为 {{分组条件1}}-{{分组条件2}} ，例如 {{namespace}}--{{pod_name}} ，效果如下图所示：现在，曲线上显示的对象名称已经比原始的名称简洁、清晰了很多。图例图表默认没有带上图例，除非将鼠标 hover 上去，否则无法看到什么颜色的曲线代表哪一个对象，如下图的左侧所示。而「图例」则可以将对象的名称和统计值显示到图表中，如下图的右侧所示。添加图例的方式如下，可选择将图例放置在图表的底部或者右侧，并显示单个或者统计值，将 Avg、Max、Last 一起显示出来是个不错的选择。分组当仪表板中需要展示很多张图表时，使用「分组」来将不同含义的图表分门别类地归类就十分有必要了，这会让仪表板的显示更具有条理，用户能通过分组快速找到自己关注的图表，如下图所示。给仪表板添加分组时，只需要在侧滑菜单中找到「分组」这个图表类型，拖动到左侧画布即可。取一个有意义的分组名称，选择一个与众不同的颜色，保存即可。下图即为新创建的分组，后续添加的图表即可拖动到该分组下。锁定时间如果你希望每次进入到仪表板，都查看到固定时间区间（例如最近1天）的数据，应该如何实现呢？我们很容易注意到仪表板的时间控件，可以在这里固定整个仪表板的时间。如果需要将单个图表的时间进行固定，而其他图表的时间则跟随仪表板的时间控件，也很好实现。我们进入单个图表的编辑窗口，打开「高级配置」，将时间锁定为指定区间即可。配置完成后，这个图表的右上角会出现你锁定的时间区间，该时间不受仪表板整体的时间区间控制，如下图所示。视图变量视图变量允许用户通过下拉菜单来选择特定对象的监控数据，从而根据自身需求动态筛选和分析数据。如下图所示，该仪表板包括了 Cluster、Namespace 和 Node 三个视图变量，用户可以进行自由筛选。我们首先添加一个简单的视图变量，需求是通过选择 ho…