解锁可观测性密码：一文掌握观测云日志监控器超能力
观测云提供一站式云、云原生、应用及业务的可观测解决方案，日志监控器是其核心功能之一，它不仅仅是一个被动的日志收集和存储工具，更是一个主动、智能的日志分析与监控告警平台。它的设计目标是帮助开发、运维和业务团队从海量的日志数据中快速发现问题、定位根因并及时响应。日志监控器的核心价值在于将非结构化的日志数据转化为可观测的结构化信息，并通过监控和告警机制，使其成为保障系统稳定性和业务连续性的有力工具。通知对象观测云支持向钉钉、企业微信、飞书等渠道发送通知，使用时需要先创建通知对象。点击「监控」 -「通知对象管理」-「新建通知对象」。填写消息推送机器人的 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 可观测性实战：日志、指标与链路追踪的完整落地
前言本节详细聊一下基于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: provider: name: envoy.tracers.opentelemetry typed_config: "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig service_name: envoy-proxy grpc_service: envoy_grpc: cluster_name: jaeger_otlp_collector ... clusters: ... - name: jaeger_otlp_collector type: LOGICAL_DNS connect_timeout: 5s lb_policy: ROUND_ROBIN http2_protocol_options: {} load_assignment: cluster_name: jaeger_otlp_collector endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 10.22.12.178 port_value: 4317 ... 修改完成之后重启下envoyjaeger成功接收到了来自envoy的trace由于只在envoy配置了trace，没有和后端服务联动，所有只显示了envoy这一段的trace信息，如果要联动后端，可以参考这个系列的文章： 全链路监控配置小结至此，logs、metrics、traces三大可观测的指标建设完成，envoy可观测性的建设也结束了联系我联系我，做深入的交流至此，本文结束在下才疏学浅，有撒汤漏水的，请各位不吝赐教...
阿里云 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/minThrottledSendRequestsPerInstance每分钟(Instance)发送被限流次数account_name,InstanceNameAverage,Maximumcounts/minThrottledSendRequestsPerTopic每分钟(Topic)发送被限流次数account_name,InstanceNameAverage,Maximumcounts/min场景视图登录观测云控制台，点击「场景」 -「新建仪表板」，输入 “阿里云 RocketMQ”， 选择 “阿里云 RocketMQ4监控视图”，点击 “确定” 即可添加视图。监控器（告警）ReadyMessagesPerGidTopic 消息堆积量异常简要描述：消息堆积量异常通常表示某个 Group 或 Group&Topic 维度下的待消费消息数持续增加，说明消费者处理速度低于生产速度。这可能会导致消息延迟变大，甚至出现业务处理超时或丢弃风险。及时监控和处理堆积量异常，有助于发现消费性能瓶颈或消费者实例异常，保障消息系统的稳定性与业务的连续性。ReceiveMessageCountPerGid / PerTopic简要描述：消费者接收消息速率异常通常表示某个 Group、Topic 或整个实例的消费吞吐量低于预期。这可能源于消费者宕机、线程不足、消费逻辑耗时过长或网络瓶颈。持续的消费速率下降会导致消息堆积增加，从而影响业务的实时性。监控该指标可帮助及时发现和定位消费环节的问题，确保生产与消费之间的速率平衡。总结通过将阿里云 RocketMQ 4.0 的监控数据接入观测云，用户可实现更直观的运行监控与异常告警。观测云能够采集并展示消息堆积量、消费速率等关键指标，及时发现消费者性能瓶颈或消息延迟问题。借助智能告警与可视化视图，用户可快速定位异常、优化消费逻辑，从而提升系统稳定性与运维效率。整体而言，该方案帮助企业在传统 RocketMQ 4.0 环境下实现现代化可观测运维。
直播预告 | 多智能体协同下的可观测产品体系化演进
伴随多智能体系统的规模化落地与技术迭代，其跨智能体交互的动态性与决策链路的黑箱特性，使AI协作的复杂度呈指数级攀升。传统可观测体系以指标、日志、链路等系统运行数据为核心，主要解答“系统发生了什么？”的问题。但当面对多个自主决策、动态交互的AI智能体时，我们更需要解答：“智能体为何这样决策？”、“协作是否高效合理？”以及“如何保证结果可靠与成本可控？”等难题。多智能体不仅改变了应用架构，更从根本上对可观测性的深度与广度提出了新的要求：如何打通从数据获取、分析到决策的完整价值链，形成高效闭环？当自动配置、智能见解等核心能力孤立运行时，如何实现它们的协同联动，以精准应对复杂运维场景？又该如何突破当前自动化诊断的瓶颈，稳步迈向预测性干预与系统自愈的高阶智能化阶段？Bonree精彩直播，码上预约为深入探讨这一命题，博睿数据特别推出【前瞻2026：可观测技术风向与趋势洞察】专题直播，直播分为上下两期。下期直播，我们聚焦于可观测性产品本身的演进路径：1月28日（周三）14:00，博睿数据产品中心高级产品经理马倩，将带来 《多智能体协同下的可观测产品体系化演进》主题分享。本次直播将从实际产品视角出发，聚焦可观测性产品的演进路径，从产品内核、协同逻辑到突破方向，展开全方位、深层次的拆解与分析。博睿宏远，将在01月28日 14:00 直播已预约多智能体协同下的可观测产品演进本次直播我们将深入探讨技术趋势，助力大家洞悉多智能体时代可观测性领域的全新挑战与技术走向。立即预约直播，解锁多智能体协同下可观测产品体系化演进，获取该领域关键认知与演进逻辑！
全栈监控与告警设计——从SLO到告警规则，避免告警雪崩的分级体系
写在前面，本人目前处于求职中，如有合适内推岗位，请加：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转化为可消耗的资源，为告警触发提供客观依据。例如，99.9%可用性目标意味着每月有43分钟错误预算。错误预算消耗速率（Burn Rate）成为告警的关键指标：快速燃烧：高错误率短时间消耗大量预算（需要立即处理）慢速燃烧：低错误率持续消耗预算（需要计划性修复）# 错误预算消耗计算 def calculate_burn_rate(slo_target, error_rate, time_window): """计算错误预算消耗速率""" error_budget = 1 - slo_target # 错误预算比例 actual_consumption = error_rate * time_window burn_rate = actual_consumption / (error_budget * time_window) return burn_rate # 示例：99.9%可用性目标，1%错误率持续30分钟 burn_rate = calculate_burn_rate(0.999, 0.01, 30) if burn_rate > 10: # 消耗速率超过10倍 trigger_critical_alert()3.2 多维度SLO指标映射不同服务需要不同的SLO定义方式，核心是建立技术指标与用户体验的直接关联。API服务SLO映射：-- 基于SLI（服务等级指标）计算SLO达成率 SELECT time_bucket('1 hour', timestamp) as hour, -- 可用性SLI SUM(CASE WHEN status_code < 500 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) as availability, -- 延迟SLI PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency) as latency_p95, -- 错误率SLI SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) as error_rate FROM api_requests WHERE timestamp >= NOW() - INTERVAL '30 days' GROUP BY hour批处理服务SLO特性：完整性：数据处理是否100%成功及时性：作业是否在时间窗口内完成正确性：输出结果是否符合质量要求3.3 告警规则的数学建模有效的告警规则需要基于统计学原理而非简单阈值。动态基线告警考虑历史模式和周期性：-- 基于时间序列分析的异常检测 WITH baseline AS ( SELECT AVG(latency) as historical_avg, STDDEV(latency) as historical_stddev FROM api_metrics WHERE time > NOW() - INTERVAL '4 weeks' AND hour_of_day = EXTRACT(HOUR FROM NOW()) ) SELECT current.latency, (current.latency - baseline.historical_avg) / baseline.historical_stddev as z_score FROM current_metrics current, baseline WHERE ABS((current.latency - baseline.historical_avg) / baseline.historical_stddev) > 3多指标复合告警提高准确性：条件1：错误率 > 2%（持续5分钟）条件2：P95延迟 > 基线200%条件3：流量下降 > 30%触发条件：条件1 AND (条件2 OR 条件3)4 告警分级体系：避免雪崩的防御工事4.1 分级原则：基于业务影响而非技术症状告警分级的目标是确保重要告警得到及时处理，而非处理所有技术异常。分级应基于业务影响程度而非技术严重性。四级分类体系在实践中证明有效：P0（紧急）：业务核心功能不可用，影响大量用户（立即呼叫）P1（高）：功能降级或部分用户受影响（2小时内处理）P2（中）：潜在问题或边缘功能异常（24小时内处理）P3（低）：轻微异常或需要观察（无需立即处理）4.2 智能抑制与降噪策略告警抑制是避免告警雪崩的关键技术。层级抑制确保只收到根本原因告警：# Alertmanager抑制规则示例 inhibit_rules: - source_match: # 源告警（更严重） severity: 'critical' target_match: # 目标告警（被抑制） severity: 'warning' equal: ['cluster', 'alertname'] # 相同集群和告警名称时间窗口聚合将相关告警合并发送：# Alertmanager路由配置 route: group_by: ['cluster', 'alertname'] group_wait: 10s # 初始等待时间 group_interval: 1m # 同一组告警发送间隔 repeat_interval: 4h # 相同告警重复发送间隔动态静默基于条件自动抑制已知问题：-- 智能静默规则示例 CREATE RULE auto_silence_maintenance WHEN alert_name = 'NodeDown' AND description LIKE '%for maintenance%' DO SILENCE FOR 2h;4.3 分级通知渠道与升级策略不同级别的告警需要不同的通知强度和升级路径。通知渠道矩阵：严重等级即时通知1小时内未确认4小时内未解决P0电话+短信+钉钉升级主管升级总监+运维总监P1钉钉+短信升级团队主管升级部门主管P2钉钉每日站会同步周报汇总P3工单系统每周评审月度优化人性化通知内容提升响应效率：{ "alert_id": "API_HIGH_ERROR_RATE_20250115", "title": "【P1】订单服务错误率超过阈值", "summary": "订单服务错误率在5分钟内从1%上升到5%，已消耗15%错误预算", "impact": "可能导致0.1%用户下单失败，预计影响金额5万元/小时", "actions": [ "1. 检查订单服务日志：https://logs.company.com/order-service", "2. 查看相关监控：https://grafana.company.com/d/order-overview", "3. 最近部署：订单服务v1.2.3（2小时前部署）" ], "runbook": "https://runbook.company.com/order-service-high-error-rate", "slo_impact": "错误预算消耗速率：3倍（正常阈值：1倍）" }5 全栈监控实战：从配置到优化的完整流程5.1 监控即代码：声明式配置管理将监控配置版本化，实现可重复、可审计的监控体系。Prometheus规则即代码：# api_service_alerts.yml groups: - name: api_service rules: - alert: APIHighErrorRate expr: | # 基于错误预算的智能告警 sum(rate(api_requests_total{status=~"5.."}[5m])) by (service) / sum(rate(api_requests_total[5m])) by (service) > 0.05 # 5%错误率阈值 for: 5m labels: severity: critical service: api-gateway annotations: summary: "{{ $labels.service }} 错误率超过5%" description: "服务 {{ $labels.service }} 当前错误率为 {{ $value }}，已持续5分钟" runbook: "https://runbook.company.com/api-high-error-rate"Dashboard即代码（JSON配置）确保监控视图一致性：{ "dashboard": { "title": "订单服务监控", "tags": ["microservice", "order"], "timezone": "browser", "panels": [ { "title": "API成功率", "type": "graph", "targets": [ { "expr": "sum(rate(orders_api_requests_total{status=~'2..'}[5m])) / sum(rate(orders_api_requests_total[5m]))", "legendFormat": "成功率" } ] } ] } }5.2 监控自愈与自动化响应自动化响应逐步降低人工干预需求。基于严重程度的自动化策略：def evaluate_autoremediation(alert): """评估是否适合自动修复""" if alert.severity == "critical": if alert.metric == "cpu_usage" and alert.value > 90: return scale_out(alert.service, factor=1.5) elif alert.metric == "memory_usage" and alert.value > 95: return restart_pod(alert.pod_name) return None渐进式应急响应：Level 1：自动扩容/重启（无状态服务）Level 2：流量切换/降级（有状态服务）Level 3：人工决策介入（数据敏感操作）5.3 监控效能度量与持续优化监控系统本身需要被监控和优化。关键效能指标：告警准确率：有效告警比例（目标>90%）平均检测时间（MTTD）：异常发生到告警的时间（目标<1分钟）平均响应时间（MTTR）：告警到修复的时间（目标<15分钟）告警疲劳指数：人均每日处理告警数（目标<5条）定期健康度评估：-- 监控系统健康度SQL查询 SELECT DATE(timestamp) as day, COUNT(*) as total_alerts, SUM(CASE WHEN acknowledged = true THEN 1 ELSE 0 END) as acknowledged_alerts, AVG(acknowledge_time - trigger_time) as avg_ack_time, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY acknowledge_time - trigger_time) as p95_ack_time FROM alerts WHERE timestamp >= NOW() - INTERVAL '30 days' GROUP BY day ORDER BY day;6 组织协同与文化建设6.1 监控责任共担模型监控不是运维团队的独角戏，而需要全组织协同。三级责任模型：平台团队：负责监控基础设施稳定性和通用指标业务团队：负责业务指标和SLO定义SRE团队：负责SLO达标和错误预算管理监控素养培养：新员工监控工具培训定期监控案例分享会监控配置代码审查6.2 监控质量内建流程将监控要求嵌入开发流程，而非事后补丁。开发阶段检查清单：[ ] 应用暴露必要的监控指标[ ] 定义清晰的SLO和目标[ ] 设计告警规则和响应流程[ ] 准备运维手册和排查指南部署流水线集成：# CI/CD中的监控校验 - name: Validate Monitoring steps: - name: Check Metrics Exposure run: | curl -s http://$APP_URL/metrics | grep -q "http_requests_total" - name: Validate SLO Definition run: | python scripts/validate_slo.py --manifest slo/manifest.yaml总结构建有效的全栈监控与告警体系是一个持续演进的过程，需要技术、流程和文化的协同发展。从SLO定义到告警规则，再到分级抑制策略，每一层都需要精心设计和不断优化。成功监控体系的核心特征：业务对齐：监控指标与业务目标紧密关联精准告警：基于SLO和错误预算的智能触发分级处理：重要信号优先处理，噪音自动抑制持续优化：定期评估效果并迭代改进避免的常见反模式：监控指标丰富但缺乏业务关联告警数量庞大但有效信号稀少响应流程冗长但解决效率低下工具堆砌但缺乏整体设计监控的终极目标不是收集更多数据，而是提供更好的决策支持。通过本文介绍的方法论和实践，团队可以构建既能够及时发现真实问题，又避免告警雪崩的高效监控体系。📚 下篇预告《压力测试方法论——目标设计、场景建模、指标评估与容量规划的完整闭环》—— 我们将深入探讨：🎯 目标制定：基于业务目标的压测场景设计与成功标准定义📊 场景建模：真实流量模拟、异常场景构造与容量边界探测📈 指标体系：性能基线、瓶颈识别与容量规划的数据基础🔄 优化闭环：从性能测试到系统调优的持续改进机制🏗️ 容量规划：基于压测结果的资源预估与扩容策略点击关注，掌握系统性能评估与容量规划的完整方法论！今日行动建议：评估当前监控体系的告警准确率，识别主要噪音来源为关键服务定义明确的SLO和错误预算消耗机制实施告警分级策略，建立基于业务影响的分级体系配置告警抑制规则，减少重复告警和告警雪崩建立监控效能度量机制，持续优化告警质量
阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
作者：杨易（青风）在云原生可观测性领域，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] 下载编译应用：./otel-linux-amd64 go build -o myapp配置运行：export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" export OTEL_SERVICE_NAME="my-app" ./myapp编译器会默默地将 HTTP 请求的监测逻辑“织入”到应用二进制文件中。配置好 OpenTelemetry 的导出端点（如 Jaeger 或控制台），运行生成的 server。访问 /greet 接口时， Tracing 数据已经自动生成并上报了，包含了请求路径、耗时、状态码等信息。从商业化到开源我们在深度实践 eBPF 技术的过程中，虽然认可其强大，但也发现它难以完美处理应用层上下文。更重要的是，我们不断听到用户反馈，大家对繁琐的手动埋点和高昂的维护成本感到困扰。为了解决这个痛点，我们开始探索 Go 编译时自动插桩方案，将其上线至阿里云可观测 ARMS 产品 [ 3] ，在这片最严苛的“试验田”里不断迭代，逐步演化成一套成熟的解决方案，不仅能实现零代码修改的链路追踪，还扩展支持了丰富的指标统计、Runtime 监控乃至持续剖析等高级功能，甚至还可以通过自定义扩展的功能完成对企业内部 sdk 的埋点 [ 4] 。调用链分析持续剖析这套方案在电商、短剧、AI 视频、汽车等众多领域客户处得到了成功验证。在看到它为用户带来巨大价值、并验证了其稳定性和可行性后，我们决定将其核心能力贡献给 OpenTelemetry 社区，希望它能成为一个普惠的技术。同时，我们与可观测领域的顶尖厂商 Datadog 协作，共同推进，最终促成了这个官方项目 [ 1] 的诞生。目前项目处于活跃开发阶段，欢迎大家试用、反馈并参与贡献，共同构建更美好的云原生可观测生态。相关链接：[1] OpenTelemetry Go 编译插桩项目https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation[2] Release 链接https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v0.1.0[3] 阿里云 ARMS Go Agent 商业版https://help.aliyun.com/zh/arms/application-monitoring/user-g...[4] 自定义扩展https://help.aliyun.com/zh/arms/application-monitoring/use-ca...
作者：望宸每个时代基础设施的变革，都始于对“混乱”的优雅重组。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 的构成和使用方式来看看它是如何把零散、杂乱的可观测数据，画成一张结构清晰、智能体能理解的图。UModel 的构成和使用方式企业习惯于将系统中的每个组件，例如应用、容器、中间件、网关、数据库，视为独立的实体进行监控和管理，并为它们配置仪表盘，设置告警，追踪性能表现。传统的监控和查询工具，无论是基于 SQL 还是 SPL，其核心都是处理二维的、表格化的数据。它们擅长回答关于个体的问题（这个 Pod 的 CPU 使用率是多少？），但在回答关于关系的问题时却显得力不从心。当面对“这个服务的故障会影响哪些下游业务？”或“要访问到核心数据库，需要经过哪些中间服务？”这类问题时，传统工具往往需要复杂的 JOIN 操作、多步查询，甚至需要工程师结合线下架构图进行人脑拼凑。这种方式不仅效率低下，而且在关系复杂、层级深的情况下几乎无法完成。我们拥有了所有“点”的数据，却失去了一张看清“线”的地图 [ 3] 。因此，UModel 将要解决以下四个关键问题：1. 重新定义系统里有什么通过 Entity 来统一定义所有可观测实体的实例，包括容器实例、服务实例等，例如服务实例 "order-service"、Pod 实例 "web-pod-001"。2. 对实例进行建模通过 EntitySet 建立实体集，并进行实体建模。将系统组件抽象为 EntitySet，一个 EntitySet 可对应多个 Entity：基础设施实体：主机、容器、网络设备、存储系统；应用层实体：微服务、API 接口、数据库实例、消息队列；业务实体：用户会话、业务流程、交易订单；运维实体：部署环境、代码仓库、运维人员。除了进行实体建模，还需要进行：数据集建模：将日志、指标、链路追踪、事件和性能剖析等多种可观测数据类型抽象为 TelemetryDataSet，由此衍生出 LogSet、TraceSet、EventSet、ProfileSet、MetricSet 等更具体的观测数据集。存储建模：Storage 是 UModel 中数据集底层存储的抽象，定义了数据的实际存储位置和访问方式。通过存储建模，UModel 能够统一对接多种存储后端，为用户提供一致的数据访问体验。3. 对这些实体&实体集进行建联通过 Link，连接不同的数据集：EntitySetLink 定义 EntitySet 实体间的关系（如服务 A 调用服务 B）；DataLink 定义 EntitySet 与 DataSet 之间的关联（如某 Pod 产生哪些日志）；StorageLink 定义 DataSet 与 Storage 之间的关联。在此基础之上，自动生成实体拓扑图和数据关系图。4. 图查询图查询可以认为是发挥 UModel 这一可观测基建的关键能力。因为系统的真实形态本就是一张图，那么对它的查询和分析，也应该使用最符合其本质的方式——图查询。为了实现这一点，我们在 UModel 体系的核心构建了 EntityStore。它采用了创新的双存储架构，同时维护了 entity 日志库（存储实体的详细属性）和 topo 日志库（存储实体间的拓扑关系）。这相当于我们为整个可观测系统建立了一个实时更新的、可查询的数字孪生图谱 [ 3] 。基于这个图谱，我们提供了从易到难、层层递进的三种图查询能力，以满足不同用户的需求：graph-match： 为最常见的路径查询场景设计，语法直观，让用户能像描述一句话一样（“A 经过 B 调用了 C”）来快速查找特定链路。graph-call： 封装了最高频的图算法（如邻居查找、直接关系查询），通过函数式接口提供，用户只需关心意图（“找 A 的 3 跳邻居”）而无需关心实现细节。Cypher： 引入业界标准的图查询语言，提供最完整、最强大的图查询能力，支持任意复杂的模式匹配、多级跳跃、聚合分析，是处理复杂图问题的终极武器。这一整套解决方案，旨在将强大的图分析能力，以一种低门槛、产品化的方式，让智能体实现自主发现、定位故障，并恢复生产成为可能。过去，运维靠人脑串联孤立的数据和几十个工具；未来，UModel 希望能作为可观测的基础设施，支撑智能体在统一上下文图谱中工作。当可观测数据被建模为可理解、可行动的上下文图谱，AIOps 才真正拥有了落地的土壤。相关阅读：[1] UModel 数据治理：运维世界模型构建实践[2] 从数据孤岛到智能洞察：构建面向未来的 Operation intelligence 体系[2] 打通可观测性的“任督二脉”：实体与关系的终极融合
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 采集脚本。点击安装按钮，并在弹出的确认框点击确认按钮。点击确认后，在弹出的部署对话框中输入 zabbix 的地址，用户名，密码，以及版本号。确认信息无误后，点击部署启动脚本，即可完成脚本的部署以及采集任务的创建。2、查看采集结果登录观测云，点击「指标」 - 「指标管理」，查找 zabbix 指标，看是否采集到。Streaming 方式（zabbix >= 6.4）该方式类似于 Prometheus 的 Remote Write，由 zabbix server 主动将数据打给 DataKit，有较高的时效性。HTTP ServerDataKit 方式1、配置 pythond 配置文件进入 DataKit 的配置文件目录 conf.d，进入 python.d 目录，复制 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=stream', 'STREAM_LISTENER_PORT=8000'] # 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 的地址用户名密码和版本。注意，COLLECT_TYPE 必须为 stream， 可根据需要调整 STREAM_LISTENER_PORT 的值。保存并退出。2、复制脚本进入 DataKit 目录，进入 pythond 目录，创建 zabbix 目录，点击下方链接下载脚本到 zabbix 目录下：https://static.guance.com/integrations/zabbix/zabbix-collecto...3、重启 DataKitdatakit service -R4、检查采集任务，出现 zabbix_collect 任务则说明采集任务开启成功datakit monitor5、创建 Zabbix 连接器登录 Zabbix，点击管理 -> 常规 -> 连接器，点击创建连接器，URL处输入 DataKit 的地址以及 zabbix stream 的监听端口（默认8000），信息类型选择数字和浮点数，点击添加。6、修改 zabbix_server.conf，修改 StartConnectors 为10，保存并重启 zabbix-server 服务7、验证指标采集结果Func 方式1、安装采集脚本登录 Func，点击「脚本市场」，选择预装脚本市场，点击管理按钮，进入预装脚本市场的脚本列表页。在过滤搜索框中输入zabbix Stream ，过滤出zabbix Stream采集脚本。点击安装即可。2、创建URL登录 Func，点击「管理」 - 「同步 API」（建议使用异步API）- 「新建」， 执行一栏选择刚导入脚本中的 Zabbix Receiver 方法，在参数指定中配置采集任务相关的配置，需要指定 zabbix_host，zabbix_user，zabbix_passwd，zabbix_version 为实际的值，base64 为 Zabbix 入参，此处填 INPUT_BY_CALLER，点击保存，并复制 url。3、创建 Zabbix 连接器登录 Zabbix， 点击管理 -> 常规 -> 连接器，点击创建连接器，URL 处输入上一步创建的 url，信息类型选择数字和浮点数，点击添加。4、修改 zabbix_server.conf，修改 StartConnectors 为10，保存并重启 zabbix-server 服务5、验证指标采集结果Kafka该方式原理同 HTTP 方式消费指标数据，区别在于该方法引入了 Kafka 组件，需部署一个 HTTP 服务用于接收 Zabbix 的 stream 输出并将消息发送到 Kafka 中，详见https://git.zabbix.com/projects/ZT/repos/kafka-connector/browse，再由消费者订阅 Kafka，进行数据消费。指标治理Zabbix 指标数据结构Zabbix 以主机为维度统计指标和告警。所以所有的指标必然包含主机信息。主机往往绑定一个或多个接口。Zabbix 的指标（item key） 的形式为 key[param1,param2,param3]。其中 params 分为静态值和变量两种。如 vfs.fs.size[{#FSNAME},pused]。其中 key 为 vfs.fs.size，{#FSNAME} 是动态参数，指实际文件系统名，pused 为静态参数，指使用量。上述采集方式中 zabbix api，Streaming，Zabbix Agent 2 三种采集方式均默认使用该规则进行指标映射。建议的指标治理规则由于 Zabbix 的数据结构跟观测云存在较大差异，为方便指标的使用与管理，结合实际企业用户的部署经验，对于 API 和 Streaming 的采集方式，我们建议 Zabbix 指标数据上传到观测云时按如下规则进行转换：measurement (指标集)：zabbix key 第一个 '.' 前的内容。fields (指标)：zabbix key + 所有静态参数。如 vfs.fs.size[{#FSNAME},pused]，就会变成 vfs.fs.size.pused，system.cpu.load[all,avg1]，就会变成system.cpu.load.all.avg1。tags (标签)：zabbix item key 中的所有动态参数小写。同时会添加 host，ip 以及 item 的 tags。如：vfs.fs.size[{#FSNAME},pused] 的 tag 为 fsname。Example：Zabbix item keymeasurementFieldtagsvfs.dev.queue_size[{#DEVNAME}]vfsvfs.dev.queue_sizedevnamevfs.dev.read.await[{#DEVNAME}]vfsvfs.dev.read.awaitdevnamevfs.dev.read.rate[{#DEVNAME}]vfsvfs.dev.read.ratedevnamevfs.file.contents[/sys/block/{#DEVNAME}/stat]vfsvfs.file.contents._sys_blck__statdevnamevfs.file.contents["/sys/class/net/{#IFNAME}/type"]vfsvfs.file.contents._sys_class_net__typeifnamevfs.fs.inode[{#FSNAME},pfree]vfsvfs.fs.inode.pfreefsnamevfs.fs.size[{#FSNAME},pused]vfsvfs.fs.size.pusedfsnamenet.if.in["{#IFNAME}",dropped]vfsnet.if.in.droppedifnamenet.if.in["{#IFNAME}"]vfsnet.if.inifname使用 Pipeline 的 reference table 实现自定义 Tag场景：对于已有 CMDB 的客户，希望将主机的一些字段富足到指标 Tag 中。如应用、负责人信息等。方式：使用 Pipeline 的 refertable 功能。具体步骤：1、使用 Func 创建一个脚本用于组装 reference table 数据，并发布。数据结构类似于：{ "table_name": "zabbix-refer-table", "column_name": ["itemid", "host", "ip", "itemkey"], "column_type": ["string", "string", "string", "string"], "row_data": [["1001", "host-1", "10.0.0.1", "vfs.fs.size"], ["1002", "host-2", "10.0.0.2", "vfs.fs.size.pused"], ["1003", "host-3", "10.0.0.3", "vfs.fs.size.pfree"]] }更多 reference table 用法，可参考：https://docs.guance.com/datakit/datakit-refer-table/2、创建同步 API登录 Func，点击「管理」 - 「同步 API」，点击 新建，在添加同步 API 对话框执行一栏中选择 zabbix-reference-table 获取脚本，点击确定保存脚本，并点击示例，获取请求 API。3、编辑 DataKit 的配置文件登录 DataKit 所在服务器（容器部署DataKit 参考官方文档），进入 DataKit 配置目录 /user/local/datakit/conf.d，编辑 datakit.conf 文件，修改 [pipeline] 选项下的 refer_table_url 的值为上一步复制的 Func 接口地址。DataKit 会将 refertable 数据预先加载到本地的 sqllite 中，可以根据 refer table 大小灵活选择是否使用内存模式的 sqllite。保存后重启 DataKit 生效。4、编辑 Pipeline登录观测云，点击「管理」 - 「Pipelines」- 「新建 Pipeline」，这里给到一个参考 Pipeline，可根据实际业务情况和 refertable 数据结构灵活调整。5、查看指标 Tag超大数据量采集优化策略对于 Export Directory 方式，可以增加独立的高速 SSD 磁盘，增加单独的 zabbix server 用于数据导出（由于需要访问 zabbix API 和数据库，DataKit 采集 ExportDirectory 会比较占用 zabbix 资源）。调低 ExportFileSize 大小。API 采集方式，可以通过分页查询，减少查询关联表，多线程查询等方式。HTTP stream 方式，可以引入队列进行异步消费或使用异步方法。支持采样收集等方式。指标治理应先将映射关系生成后存入缓存或内存中，方便快速匹配。为减少 redis 读写压力可以考虑分片缓存或缓存压缩等方法。各采集方式对比采集方式采集原理优势劣势Zabbix APIfunc/datakit使用python代码通过zabbix api获取指标数据。进行指标治理和映射后上传到观测云。可分布式采集，采集过程高可用便于灵活调整采集所需资源。便于指标的灵活治理和映射时效性不高，最大时延可达1minzabbix到func区间数据无法压缩，对该区间网路压力较大。通常需要在func维护采集代码，对采集代码质量要求较高，否则在进行大数据量采集时速度较慢导致时效变差或丢失数据，严重时会影响zabbix性能。Streaming与zabbix建立网络长连接（HTTP server/Kafka）消费zabbix产生的history和event数据时效性高可分布式采集，采集过程高可用便于灵活调整采集所需资源。便于指标的灵活治理和映射zabbix到func区间数据无法压缩，对该区间网路压力较大。Zabbix 转 Prometheus部署独立服务通过调用zabbix api将zabbix指标数据暴露成Prometheus metric接口供datakit采集集成简单，可以使用datakit现有能力。需要维护独立的转换服务。转换服务与zabbix间网络转发无压缩，对网络压力较大。无法灵活进行指标治理和映射。总结监控数据的集成是一个复杂的综合性工作，本文所展示方案所适用场景需相关运维工程师根据实际情况进行调整。
艾体宝方案 | 重塑智能汽车OTA：构建全球级、高可靠、可观测的软件分发与管理系统
摘要软件定义汽车（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关联，提供毫秒级精度的全链路追溯能力，满足最高级别的审计要求。关键场景与价值量化结语在软件定义汽车的竞赛中，OTA的效能直接决定了车企数字化运营的高度与速度。Redis企业版通过将实时数据同步、智能任务编排、多模型存储与边缘计算能力深度融合，为车企提供了一个不仅强大而且“聪慧”的OTA数据基座。这不仅仅是技术的升级，更是运营理念的革新——从被动的、高风险的手动操作，迈向主动的、数据驱动的、全球一体化的软件服务交付。选择Redis企业版，即是选择为未来十年海量车队的软件生命周期管理，构建一个可靠、高效且充满智能的“指挥中心”。
掌握核心方法论，打造高质量业务仪表板
前言在数字化运维与业务监控的实践中，仪表板（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 三个视图变量，用户可以进行自由筛选。我们首先添加一个简单的视图变量，需求是通过选择 host_ip 来过滤单台主机的数据。在仪表板中点击「添加视图变量」。host_ip 是 cpu 相关指标数据的一个标签，因此我们从指标类型- CPU指标集里面选择 host_ip 作为视图变量的来源，然后将「变量名」和「显示名」都与之保持一致，保存窗口即可。此时返回仪表板，就会看到刚才添加的 host_ip 视图变量，从下拉菜单中可以筛选主机 IP。如下图所示：你可能会发现筛选结果之后，对下方的图表没有任何作用，因为我们还需要在图表中的过滤条件配置变量，使仪表板的额视图变量与图表的过滤条件进行联动。再次进入图表编辑界面，添加一个过滤条件，字段选择为 host_ip，值选择「视图变量」，如下图所示。返回仪表板，这时仪表板的视图变量 host_ip 就可以与图表中的监控对象 host_ip 进行联动了。我们可以通过下拉菜单来筛选不同的主机，从而观察不同主机的监控指标。如果是有多个视图变量，且视图变量之间有依赖关系，例如我们针对 Pod 的监控是首先选择 namespace，再选 Pod，那我们又应该如何配置呢？这就要用到「级联」的写法，让我们来再来回顾一下刚才本章开头的那张图片。选择 Cluster 后，Namespace 的值随 Cluster 的取值而联动，Node 的值又随 Namespace 的取值而联动。我们研究一下这组视图变量的写法，不难发现规律是在 show_tag_value 函数的后面跟随了一个 {key=value} 的过滤条件，其固定写法为 {key='#{value}'} ，key 和 value 都取自上一级的变量名，表示该变量随上一级变量的值而联动。如下图所示，当用户在界面上选择了 cluster_name_k8s 的值后，该值就会传入 namespace 作为过滤条件，从而实现变量联动。小结通过上面的几个小技巧，相信你已经跃跃欲试将自己的仪表板更上一层楼了。在得到令自己满意的仪表板后，你可以选择将仪表板开放给团队、配置为定时报告、投放到大屏幕、关联到日志或链路查看器中，又或者在接收到告警时一键查看这张仪表板。我们非常期待你通过仪表板来向你的团队/客户呈现数据的价值。