2026/8/26 7:00:19
FEATURED · 精选文章 
1. 项目概述当“可观测”遇见“Skill”运维工作流的新范式最近在腾讯云的官方动态里一个名为“可观测Skill”的新功能悄然上线在运维圈子里激起了一些讨论。作为一个常年和服务器、日志、监控告警打交道的老运维我第一眼看到这个组合词就来了兴趣。“可观测性”Observability我们太熟悉了它早已超越了传统的监控强调从日志Logs、指标Metrics、链路Traces这些外部输出去理解系统的内部状态。而“Skill”这个词在技术语境下尤其是在一些自动化平台或对话式AI里通常指的是一种可被调用、能完成特定任务的“技能”或“小插件”。当这两个词被腾讯云组合在一起它想解决的痛点就非常明确了将复杂的、需要专业知识的可观测数据分析和响应动作封装成一个个简单、可复用、甚至可编排的“技能”让运维人员能够以更高效、更自动化的方式处理日常乃至突发的运维场景从而真正“解放双手”。简单来说这就像给你的运维工具箱里添加了一套智能的“瑞士军刀模块”。以前我们看到CPU使用率飙升的告警需要手动登录服务器执行一串命令如top,vmstat, 分析进程判断是哪个应用、哪个函数导致的然后再决定是扩容、重启还是优化代码。这个过程耗时耗力且高度依赖个人经验。现在腾讯云可观测Skill试图将“分析CPU飙升根因”这个完整的诊断流程打包成一个预置的或自定义的Skill。当告警触发时这个Skill能自动执行预设的分析脚本调用相关API获取数据进行逻辑判断并最终输出一份结构化的分析报告甚至可以直接触发一个扩容动作。它的核心价值在于将运维经验产品化、将响应流程自动化目标是让运维人员从重复、繁琐的“消防员”式工作中抽身更专注于架构优化和业务创新。2. 核心需求解析运维人的“痛”与“盼”要理解可观测Skill的价值我们必须先回到运维工程师的日常。我们的工作状态常常是“救火”与“巡检”交替伴随着大量重复性操作和高度紧张的突发状况处理。以下几个典型场景相信每一位运维同仁都深有体会2.1 告警风暴与噪音过滤深夜手机突然被告警短信轰炸。打开监控面板可能因为一个核心服务抖动引发了上下游数十个关联服务的指标异常产生几百条告警。运维人员的第一项工作不是解决问题而是“筛选告警”。哪些是核心告警哪些是连带影响哪些是历史遗留的无效告警这个筛选过程本身就需要经验和时间在紧急情况下更是压力倍增。我们期盼的是监控系统能智能地聚合、关联告警只把最根本、最需要立即处理的问题推送到我们面前。2.2 根因定位的“迷宫游戏”收到一条“API接口平均响应时间超过阈值”的告警。问题可能出在哪里是应用服务器性能瓶颈是数据库查询慢是缓存失效还是下游依赖服务超时传统的排查需要像侦探一样依次查看应用监控、数据库监控、链路追踪、日志等多个系统的数据在多个控制台间反复切换拼接线索。这个过程就像走迷宫路径长、效率低。我们期盼有一个“一键诊断”工具能自动关联相关数据快速给出问题可能发生的模块甚至直接定位到有问题的代码行或慢SQL。2.3 重复性操作与“脚本海洋”很多应急操作是重复性的服务无响应时先重启、磁盘空间满了清理日志、某个队列堆积了重启消费者……有经验的团队会积累一大堆Shell脚本、Python脚本。这些脚本散落在各个运维人员的电脑里调用方式不一参数记录不全形成“脚本海洋”。当新人接手或需要跨团队协作时脚本的复用和管理成了新问题。我们期盼能将这类标准操作流程SOP规范化、工具化并且能够安全、便捷地被授权人员执行。2.4 跨系统协作的“信息孤岛”现代系统架构复杂可观测数据也分散各处基础设施监控在云监控应用性能监控在另一个产品日志又在日志服务链路追踪可能独立部署。当问题发生时我们需要在多个系统间手动传递信息比如把告警的实例ID复制到日志平台去查询对应时间点的错误日志。这种割裂感严重影响了排障效率。我们期盼可观测数据能天然打通在一个统一的上下文中提供分析能力。腾讯云可观测Skill正是针对以上这些“痛点”提出的解决方案。它不是一个全新的监控产品而是在现有可观测数据云监控、应用性能监控、日志服务等之上构建的一个自动化响应与智能分析层。它的野心是成为连接“发现问题”与“解决问题”之间的智能桥梁。3. 技术架构与核心组件拆解虽然腾讯云官方可能尚未公布可观测Skill的详尽架构图但根据其功能定位和业界类似实践如AWS的CloudWatch Evidently Lambda, GCP的Cloud Monitoring Cloud Functions我们可以推断出其核心的技术架构和组件。理解这些有助于我们更好地使用和扩展它。3.1 事件驱动架构一切的起点可观测Skill的运转核心是事件驱动。这个“事件”通常来源于腾讯云内部各个可观测数据源产生的告警事件。例如云监控Cloud Monitor产生指标阈值告警如CPU使用率90%。应用性能监控APM产生应用性能告警如接口错误率骤升、调用链慢请求。日志服务CLS产生日志模式告警如短时间内出现大量ERROR日志。 这些事件会被统一投递到一个事件总线Event Bridge中。事件总线是整个架构的中枢神经负责事件的接收、过滤、路由和转换。3.2 Skill定义与触发器设定响应规则用户需要在控制台定义或选择一个Skill。每个Skill都绑定了一个或多个触发器Trigger。触发器本质上是一个规则引擎它监听事件总线上的特定事件。你可以这样配置一个触发器事件源云监控事件类型告警状态变化从“正常”变为“异常”过滤条件告警策略名称 “生产环境-CPU使用率告警” AND 告警级别 “严重” 当满足这些条件的事件到达时触发器就会被激活从而触发其后端关联的技能逻辑。3.3 技能逻辑执行环境FaaS的无服务器之力被触发的Skill需要在一个执行环境中运行其逻辑。这几乎可以肯定是由腾讯云云函数SCF这类函数即服务FaaS产品来承载。云函数提供了无需管理服务器、按需运行、自动伸缩的能力完美契合Skill“即触即用”的场景。 一个Skill的逻辑一段代码就部署为一个云函数。这段代码可以做很多事情获取上下文函数被触发时会接收到完整的事件信息如告警内容、涉及的实例ID、时间戳等。调用可观测API函数内部可以通过SDK调用腾讯云其他服务的API去获取更详细的数据。例如根据实例ID去云监控拉取最近5分钟的详细CPU、内存指标去日志服务查询该实例在同一时间段的日志去APM查询相关的调用链。执行分析逻辑基于获取的数据运行内置的分析算法。比如判断CPU飙升是否伴随线程数暴涨从而推测是计算密集型问题或者分析错误日志的模式判断是数据库连接池耗尽还是第三方API超时。生成结论与行动最后函数会输出一个结构化的结果。这个结果可以是一条富文本的诊断报告发送到钉钉/企业微信也可以是一个直接的“行动建议”比如“建议执行扩容操作”甚至它可以直接调用另一个API去执行动作例如调用CVM的API进行服务器重启或调用AS的API触发弹性伸缩。3.4 连接器与安全管控为了让Skill能安全地执行操作架构中必然包含连接器Connector和权限管理IAM组件。连接器预置了与腾讯云各种服务CVM、CLB、TDSQL、COS等交互的标准化接口简化了Skill开发中调用API的复杂度。权限管理这是安全的重中之重。每个Skill在执行时都会以一个特定的角色Role运行。这个角色通过腾讯云访问管理CAM被精确授予最小必要的权限。例如一个只负责分析日志的Skill其角色可能只有日志服务的“只读”权限而一个负责扩容的Skill其角色则需要被授予弹性伸缩的“写”权限。这种设计确保了自动化操作的安全边界。3.5 技能市场与共享可观测Skill平台很可能规划了一个技能市场。腾讯云官方和第三方开发者可以将通用的、经过验证的Skill如“MySQL慢查询分析”、“Redis内存碎片诊断”发布到市场上供其他用户一键订阅部署。这能极大加速运维能力的沉淀和共享。4. 从零到一构建你的第一个可观测Skill理论讲得再多不如亲手实践。下面我将以一个最经典的场景为例带你一步步创建一个可观测Skill。我们的目标是创建一个自动分析“CPU使用率告警”根因并发送详细诊断报告到企业微信的Skill。4.1 场景定义与准备工作假设我们已在腾讯云监控中为一批生产服务器设置了告警策略当CPU使用率持续3分钟超过80%时触发严重告警。现在我们希望告警触发时能自动分析是系统进程如kswapd0导致还是某个Java应用进程导致并给出初步建议。准备工作确保你拥有目标云服务器CVM所在账号的运维权限。在企业微信群里创建一个“运维报警机器人”获取其Webhook地址。我们将用它来接收消息。在腾讯云控制台确保已开通云监控、云函数SCF、访问管理CAM服务。4.2 创建Skill逻辑云函数这是最核心的一步。我们使用Python语言编写云函数。import json import os import subprocess from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.monitor.v20180724 import monitor_client, models as monitor_models from tencentcloud.cvm.v20170312 import cvm_client, models as cvm_models import requests import re def main_handler(event, context): 主处理函数由云监控告警事件触发。 event结构示例 { Records: [{ Ckafka: {...}, Event: { EventName: AlarmPolicyTrigger, EventVersion: 1.0, Region: ap-guangzhou, Resource: {Entity: ins-xxxxxx}, Content: { PolicyId: policy-xxxx, AlarmStatus: ALARM, AlarmObject: ins-xxxxxx, MetricName: CPUUsage, Value: 95.0, ... // 其他告警详情 } } }] } print(Received event: json.dumps(event)) # 1. 解析事件获取告警实例ID try: alarm_event event[Records][0][Event] instance_id alarm_event[Resource][Entity] # 例如: ins-xxxxxx metric_value alarm_event[Content][Value] region alarm_event[Region] except KeyError as e: print(fFailed to parse event: {e}) return {error: Invalid event format} # 2. 初始化腾讯云客户端使用SCF默认角色或配置临时密钥 # 注意需为SCF执行角色绑定QcloudMonitorReadOnlyAccess、QcloudCVMReadOnlyAccess策略 cred credential.Credential( os.environ.get(TENCENTCLOUD_SECRETID), os.environ.get(TENCENTCLOUD_SECRETKEY), os.environ.get(TENCENTCLOUD_SESSIONTOKEN) ) http_profile HttpProfile(endpointmonitor.tencentcloudapi.com) client_profile ClientProfile(httpProfilehttp_profile) monitor monitor_client.MonitorClient(cred, region, client_profile) # 3. 调用云监控API获取该实例近10分钟的详细监控数据如进程级CPU # 这里简化处理实际应调用GetMonitorData接口筛选proc_cpu等指标 req monitor_models.GetMonitorDataRequest() req.Namespace QCE/CVM req.MetricName CPUUsage req.Period 60 req.StartTime 2023-10-01T00:00:0008:00 # 应替换为动态时间如10分钟前 req.EndTime 2023-10-01T00:10:0008:00 # 应替换为当前时间 req.Instances [{Dimensions: [{Name: InstanceId, Value: instance_id}]}] # 注意此处为示例实际API调用需要处理分页、错误等 # resp monitor.GetMonitorData(req) # process_data resp.DataPoints # 分析进程数据 # 4. 模拟根因分析逻辑 # 在实际生产环境这里可以 # a. 通过云监控API获取proc_cpu指标找出消耗CPU最高的进程。 # b. 或通过SSH需考虑安全组、密钥连接到实例执行 top -bn1 命令不推荐在FaaS中直接SSH。 # c. 更佳实践在实例上部署监控Agent将进程数据上报到CLSSkill从CLS查询。 # 本例我们模拟一个分析结果 analysis_result { instance_id: instance_id, cpu_peak: f{metric_value}%, top_processes: [ {pid: 12345, name: java, cpu_percent: 65.2, command: /usr/bin/java -jar app.jar}, {pid: 67890, name: kswapd0, cpu_percent: 18.5, command: [kswapd0]}, ], likely_root_cause: Java应用进程 app.jar 消耗了超过65%的CPU资源疑似存在计算密集型任务或死循环。, suggested_actions: [ 1. 立即登录实例使用 top -Hp 12345 查看该Java进程的线程状态。, 2. 检查应用日志定位同时段是否有异常任务执行。, 3. 考虑临时重启该Java应用服务。, 4. 长期优化检查应用代码性能或考虑增加实例规格。 ] } # 5. 格式化消息并发送到企业微信 wecom_webhook os.environ.get(WECOM_WEBHOOK_URL) # 在云函数环境变量中配置 if wecom_webhook: markdown_content f** CPU告警根因分析报告** **告警实例**{analysis_result[instance_id]} **CPU峰值**{analysis_result[cpu_peak]} **主要消耗进程** 1. **PID {analysis_result[top_processes][0][pid]}** - {analysis_result[top_processes][0][name]} - CPU占用{analysis_result[top_processes][0][cpu_percent]}% - 命令{analysis_result[top_processes][0][command]} 2. **PID {analysis_result[top_processes][1][pid]}** - {analysis_result[top_processes][1][name]} - CPU占用{analysis_result[top_processes][1][cpu_percent]}% - 命令{analysis_result[top_processes][1][command]} **初步根因判断**{analysis_result[likely_root_cause]} **建议操作** {chr(10).join(analysis_result[suggested_actions])} msg { msgtype: markdown, markdown: {content: markdown_content} } resp requests.post(wecom_webhook, jsonmsg) print(fSent to WeCom, status: {resp.status_code}) else: print(WECOM_WEBHOOK_URL not configured.) return {statusCode: 200, body: json.dumps(analysis_result)}注意以上代码为演示逻辑实际生产使用需要处理更多细节如API调用的错误重试、时间的动态计算、更安全的密钥管理推荐使用SCF的关联角色而非环境变量存储SecretKey、以及更复杂的进程分析算法。4.3 配置触发器与部署创建云函数在腾讯云SCF控制台使用上述代码创建新的函数运行时选择Python 3.7。在“高级配置”中添加环境变量WECOM_WEBHOOK_URL为你机器人的地址。为函数的执行角色配置QcloudMonitorReadOnlyAccess和QcloudCVMReadOnlyAccess策略。配置触发器在函数详情页进入“触发管理”。创建新触发器类型选择“云监控Cloud Monitor告警触发”。选择你之前创建好的“CPU使用率告警”策略。配置事件规则通常选择“告警触发”作为触发条件。测试你可以手动在云监控中恢复告警策略然后再触发一次告警观察SCF的调用日志和企业微信群是否收到了格式化的诊断消息。通过以上步骤一个最简单的可观测Skill就创建完成了。当CPU告警触发时它会自动运行并尝试给出比原始告警更有价值的上下文信息。5. 高级应用场景与技能编排掌握了基础Skill的创建我们可以探索更复杂、更强大的应用模式。可观测Skill的真正威力在于其可组合性和可编排性能够串联多个步骤形成智能化的运维工作流。5.1 场景一全链路故障自愈目标当核心交易接口错误率升高时自动分析链路若确定是某个下游缓存节点故障则自动将其从负载均衡中摘除并通知运维人员。技能链设计Skill A分析由APM的“接口错误率”告警触发。调用APM和链路追踪API分析错误请求的链路特征。如果发现错误集中发生在对某个Redis集群的调用上则触发下一个Skill并传递Redis集群节点IP作为参数。Skill B执行接收节点IP。调用CLB负载均衡或云API网关的API将该故障节点从后端服务器列表中移除或设置为排水模式。Skill C通知调用企业微信/钉钉API发送一条包含故障摘要、影响范围、已执行操作摘除节点的详细通知。这个流程将原本需要人工查看APM、登录LB控制台操作、再发通知的多个步骤压缩到了分钟级甚至秒级内自动完成。5.2 场景二成本优化与资源回收目标每周一凌晨自动扫描所有云服务器找出过去7天内CPU平均使用率持续低于10%且无重要进程的实例生成报告并建议是否可关机或降配。技能链设计Skill A发现由一个定时触发器Cron Trigger每周一0点触发。调用CVM API列出所有实例并发起批量查询任务通过云监控API获取它们过去一周的CPU、内存使用率指标。Skill B判断对每个实例运行判断逻辑如果CPU10%且内存30%再通过标签系统或CMDB接口判断其是否为“测试环境”或“可回收”状态。Skill C报告将符合条件低使用率可回收标签的实例列表、预估月度节省金额生成一个Markdown报告。Skill D审批与执行将报告发送到一个内部审批系统如腾讯云HiFlow连接企业微信审批流。如果审批通过回调一个执行Skill自动对这些实例执行关机或变更配置操作。5.3 场景三安全事件智能响应目标当日志服务CLS检测到大量“SSH暴力破解”日志时自动分析来源IP并将其IP地址临时加入安全组黑名单。技能链设计Skill A检测由CLS的“告警策略”触发告警条件是“同一源IP在1分钟内SSH认证失败日志超过20条”。事件中会包含攻击源IP。Skill B封禁接收源IP。调用VPC安全组API创建一条新的入站规则拒绝该IP对所有端口的访问规则描述注明“由安全Skill自动添加”。Skill C溯源与通知调用IP地理位置查询API第三方或腾讯云市场获取该IP的归属地信息。将攻击事件详情、封禁操作、IP归属地一并发送给安全团队。实操心得在设计复杂技能链时状态管理和错误处理是关键。一个Skill执行失败不能导致整个链条静默失效。建议在每个Skill的输出中包含明确的执行状态success,failed,pending和结果数据。可以使用腾讯云工作流Cloud Flow或简单的状态数据库如Redis来管理流程状态并设置一个兜底的“总控Skill”来监控整个链条的健康状况在失败时发送告警。6. 开发与运维最佳实践将可观测Skill投入生产环境不能只停留在功能实现。遵循以下最佳实践能确保你的Skill稳定、安全、易维护。6.1 技能设计原则单一职责与幂等性单一职责一个Skill只做好一件事。例如“分析根因”和“执行重启”应该拆分成两个Skill。这提高了复用性也便于测试和排错。幂等性你的Skill代码应该支持被多次触发可能由于事件重复投递而产生相同的结果。例如封禁IP的Skill在收到同一个IP时应该先检查安全组规则是否已存在避免创建重复规则。6.2 代码与配置管理版本控制Skill的代码云函数必须纳入Git等版本控制系统。每次变更都应有记录便于回滚和协作。环境分离为开发、测试、生产环境创建不同的腾讯云子账号或命名空间分别部署Skill。避免测试代码影响线上业务。配置外置将所有可变的参数如API网关地址、阈值、通知接收人放在云函数的环境变量或专门的配置中心如腾讯云SSM参数存储中不要硬编码在代码里。6.3 安全与权限管控最小权限原则这是铁律。为每个Skill的执行角色SCF角色授予其完成任务所必需的最小权限。分析型Skill只给读权限执行型Skill精确到具体的API动作如cvm:RestartInstances。网络隔离如果Skill需要访问内网资源如自建数据库请将云函数部署在VPC内并配置好安全组和路由。敏感信息保护用于调用第三方服务的Token、密码等务必使用腾讯云密钥管理系统KMS或参数存储进行加密存储切勿写在代码或明文环境变量中。6.4 可观测性建设对Skill本身完善日志在Skill代码中关键逻辑点打印结构化日志JSON格式方便在SCF控制台或CLS中查询。日志应包含请求ID、执行阶段、关键决策结果等信息。设置监控为你的云函数设置监控告警关注其调用次数、错误率、运行时长和内存使用量。一个频繁失败的Skill本身就会成为运维负担。链路追踪对于复杂的技能链考虑在函数间传递一个唯一的trace_id并将关键操作记录到腾讯云链路追踪服务中便于可视化整个自动化流程的执行路径和耗时。6.5 测试与演练单元测试为Skill的核心分析逻辑编写单元测试确保业务逻辑正确。集成测试在测试环境模拟真实的事件如构造一条告警消息来触发整个Skill或技能链验证端到端的流程。混沌演练定期进行故障演练故意制造一些线上问题如在低峰期观察你的可观测Skill是否能按预期触发并正确响应。这是检验自动化可靠性的最好方法。7. 常见问题与排查技巧实录在实际使用和开发可观测Skill的过程中你肯定会遇到各种问题。下面是我总结的一些典型“坑”和解决思路。7.1 Skill未被触发检查触发器配置首先确认云监控告警策略是否确实处于“告警”状态。在SCF控制台查看函数的触发器和调用日志确认事件是否被正确路由。检查事件格式云监控告警触发的事件格式可能因产品线不同而有细微差别。务必在Skill代码开头打印完整的event对象并与腾讯云官方文档的事件样例进行比对。常见的错误是event[Records][0][Event][Content]的路径访问错误。检查权限确保SCF函数的执行角色拥有从云监控接收事件的权限通常由触发器自动配置以及调用其他云产品API的权限。7.2 Skill执行超时或内存不足优化函数逻辑Skill的设计初衷是快速响应逻辑应轻量。避免在函数内进行大量循环计算或处理巨型数据。将耗时操作如分析大量历史日志改为异步任务或先由其他服务预处理。调整资源配置在SCF函数配置中适当增加超时时间如从3秒调整为30秒和内存大小如从128MB调整为512MB。内存大小会直接影响CPU分配对计算密集型分析有提升。使用异步调用如果Skill执行时间可能较长在创建触发器时选择“异步调用”模式避免因HTTP超时而导致前端失败。7.3 调用云API失败网络问题确保函数部署的地域和要调用的API服务地域一致或者函数配置了公网访问能力。VPC内函数调用公网API可能需要配置NAT网关。鉴权失败这是最常见的问题。仔细检查SCF执行角色的CAM策略。可以使用腾讯云的 策略生成器 或 策略语法验证 工具来确保策略正确。错误信息通常是AuthFailure或PermissionDenied。API版本或参数错误腾讯云SDK和API可能会更新。确保你安装的Python SDKtencentcloud-sdk-python版本是最新的并且传入的请求参数符合API文档要求。开启SDK的调试日志有助于定位问题。7.4 技能链中信息传递丢失规范数据格式在技能链中前一个Skill的输出会成为后一个Skill的输入。约定一个清晰、稳定的JSON格式作为Skill间的“合约”。建议包含request_id、stage、data、error等字段。使用状态存储对于多步骤、长时间运行的流程不要依赖函数间的直接参数传递。应该将中间状态和结果存储到持久化存储中如腾讯云数据库TDSQLMySQL、RedisCKV或对象存储COS。每个Skill只负责读写自己相关的部分。7.5 告警风暴导致Skill被频繁调用在触发器层过滤这是最重要的防线。充分利用事件总线或触发器规则的条件过滤功能只针对最关键、最需要自动化的告警进行触发。例如只对“严重”级别的告警或者对持续了N分钟的告警触发Skill。在Skill逻辑中限流在Skill代码开头可以加入简单的限流逻辑。例如利用Redis记录每个告警对象如实例ID最后一次被处理的时间如果短时间内再次触发则跳过本次执行仅记录日志。设置并发限制在SCF函数配置中可以设置该函数的“保留并发”或“最大并发”数防止因突发的大量告警导致函数实例无限扩容产生不可控的费用和下游服务压力。7.6 调试与日志查看技巧本地测试强烈建议在本地搭建测试环境。你可以模拟一个告警事件的JSON文件使用SCF的本地调试工具如scf local invoke来运行函数快速验证逻辑。善用日志服务CLS将SCF函数的日志投递到CLS。利用CLS强大的检索和可视化能力你可以轻松地通过request_id追踪一次完整的Skill执行过程或者通过关键词过滤错误日志。使用临时调试代码在开发阶段可以在函数中临时加入向一个“调试接收端”如一个临时的Webhook或日志文件发送详细中间结果的代码便于分析逻辑流程。上线前务必移除。可观测Skill的引入标志着运维自动化从“脚本化”走向“服务化”、“智能化”。它不再是一个个孤立的脚本而是一个有触发、有逻辑、有执行、可观测、可管理的有机整体。对于运维团队而言早期投入一些精力去规划和建设这些Skill就像打造一套自动化流水线初期有成本但长远来看它将把团队从无尽的、低价值的重复告警处理中解放出来让我们能有更多时间去思考架构的韧性、系统的性能和业务的连续性这些更有挑战的课题。
腾讯云可观测Skill：事件驱动与FaaS构建的智能运维自动化实践
1. 项目概述当“可观测”遇见“Skill”运维工作流的新范式最近在腾讯云的官方动态里一个名为“可观测Skill”的新功能悄然上线在运维圈子里激起了一些讨论。作为一个常年和服务器、日志、监控告警打交道的老运维我第一眼看到这个组合词就来了兴趣。“可观测性”Observability我们太熟悉了它早已超越了传统的监控强调从日志Logs、指标Metrics、链路Traces这些外部输出去理解系统的内部状态。而“Skill”这个词在技术语境下尤其是在一些自动化平台或对话式AI里通常指的是一种可被调用、能完成特定任务的“技能”或“小插件”。当这两个词被腾讯云组合在一起它想解决的痛点就非常明确了将复杂的、需要专业知识的可观测数据分析和响应动作封装成一个个简单、可复用、甚至可编排的“技能”让运维人员能够以更高效、更自动化的方式处理日常乃至突发的运维场景从而真正“解放双手”。简单来说这就像给你的运维工具箱里添加了一套智能的“瑞士军刀模块”。以前我们看到CPU使用率飙升的告警需要手动登录服务器执行一串命令如top,vmstat, 分析进程判断是哪个应用、哪个函数导致的然后再决定是扩容、重启还是优化代码。这个过程耗时耗力且高度依赖个人经验。现在腾讯云可观测Skill试图将“分析CPU飙升根因”这个完整的诊断流程打包成一个预置的或自定义的Skill。当告警触发时这个Skill能自动执行预设的分析脚本调用相关API获取数据进行逻辑判断并最终输出一份结构化的分析报告甚至可以直接触发一个扩容动作。它的核心价值在于将运维经验产品化、将响应流程自动化目标是让运维人员从重复、繁琐的“消防员”式工作中抽身更专注于架构优化和业务创新。2. 核心需求解析运维人的“痛”与“盼”要理解可观测Skill的价值我们必须先回到运维工程师的日常。我们的工作状态常常是“救火”与“巡检”交替伴随着大量重复性操作和高度紧张的突发状况处理。以下几个典型场景相信每一位运维同仁都深有体会2.1 告警风暴与噪音过滤深夜手机突然被告警短信轰炸。打开监控面板可能因为一个核心服务抖动引发了上下游数十个关联服务的指标异常产生几百条告警。运维人员的第一项工作不是解决问题而是“筛选告警”。哪些是核心告警哪些是连带影响哪些是历史遗留的无效告警这个筛选过程本身就需要经验和时间在紧急情况下更是压力倍增。我们期盼的是监控系统能智能地聚合、关联告警只把最根本、最需要立即处理的问题推送到我们面前。2.2 根因定位的“迷宫游戏”收到一条“API接口平均响应时间超过阈值”的告警。问题可能出在哪里是应用服务器性能瓶颈是数据库查询慢是缓存失效还是下游依赖服务超时传统的排查需要像侦探一样依次查看应用监控、数据库监控、链路追踪、日志等多个系统的数据在多个控制台间反复切换拼接线索。这个过程就像走迷宫路径长、效率低。我们期盼有一个“一键诊断”工具能自动关联相关数据快速给出问题可能发生的模块甚至直接定位到有问题的代码行或慢SQL。2.3 重复性操作与“脚本海洋”很多应急操作是重复性的服务无响应时先重启、磁盘空间满了清理日志、某个队列堆积了重启消费者……有经验的团队会积累一大堆Shell脚本、Python脚本。这些脚本散落在各个运维人员的电脑里调用方式不一参数记录不全形成“脚本海洋”。当新人接手或需要跨团队协作时脚本的复用和管理成了新问题。我们期盼能将这类标准操作流程SOP规范化、工具化并且能够安全、便捷地被授权人员执行。2.4 跨系统协作的“信息孤岛”现代系统架构复杂可观测数据也分散各处基础设施监控在云监控应用性能监控在另一个产品日志又在日志服务链路追踪可能独立部署。当问题发生时我们需要在多个系统间手动传递信息比如把告警的实例ID复制到日志平台去查询对应时间点的错误日志。这种割裂感严重影响了排障效率。我们期盼可观测数据能天然打通在一个统一的上下文中提供分析能力。腾讯云可观测Skill正是针对以上这些“痛点”提出的解决方案。它不是一个全新的监控产品而是在现有可观测数据云监控、应用性能监控、日志服务等之上构建的一个自动化响应与智能分析层。它的野心是成为连接“发现问题”与“解决问题”之间的智能桥梁。3. 技术架构与核心组件拆解虽然腾讯云官方可能尚未公布可观测Skill的详尽架构图但根据其功能定位和业界类似实践如AWS的CloudWatch Evidently Lambda, GCP的Cloud Monitoring Cloud Functions我们可以推断出其核心的技术架构和组件。理解这些有助于我们更好地使用和扩展它。3.1 事件驱动架构一切的起点可观测Skill的运转核心是事件驱动。这个“事件”通常来源于腾讯云内部各个可观测数据源产生的告警事件。例如云监控Cloud Monitor产生指标阈值告警如CPU使用率90%。应用性能监控APM产生应用性能告警如接口错误率骤升、调用链慢请求。日志服务CLS产生日志模式告警如短时间内出现大量ERROR日志。 这些事件会被统一投递到一个事件总线Event Bridge中。事件总线是整个架构的中枢神经负责事件的接收、过滤、路由和转换。3.2 Skill定义与触发器设定响应规则用户需要在控制台定义或选择一个Skill。每个Skill都绑定了一个或多个触发器Trigger。触发器本质上是一个规则引擎它监听事件总线上的特定事件。你可以这样配置一个触发器事件源云监控事件类型告警状态变化从“正常”变为“异常”过滤条件告警策略名称 “生产环境-CPU使用率告警” AND 告警级别 “严重” 当满足这些条件的事件到达时触发器就会被激活从而触发其后端关联的技能逻辑。3.3 技能逻辑执行环境FaaS的无服务器之力被触发的Skill需要在一个执行环境中运行其逻辑。这几乎可以肯定是由腾讯云云函数SCF这类函数即服务FaaS产品来承载。云函数提供了无需管理服务器、按需运行、自动伸缩的能力完美契合Skill“即触即用”的场景。 一个Skill的逻辑一段代码就部署为一个云函数。这段代码可以做很多事情获取上下文函数被触发时会接收到完整的事件信息如告警内容、涉及的实例ID、时间戳等。调用可观测API函数内部可以通过SDK调用腾讯云其他服务的API去获取更详细的数据。例如根据实例ID去云监控拉取最近5分钟的详细CPU、内存指标去日志服务查询该实例在同一时间段的日志去APM查询相关的调用链。执行分析逻辑基于获取的数据运行内置的分析算法。比如判断CPU飙升是否伴随线程数暴涨从而推测是计算密集型问题或者分析错误日志的模式判断是数据库连接池耗尽还是第三方API超时。生成结论与行动最后函数会输出一个结构化的结果。这个结果可以是一条富文本的诊断报告发送到钉钉/企业微信也可以是一个直接的“行动建议”比如“建议执行扩容操作”甚至它可以直接调用另一个API去执行动作例如调用CVM的API进行服务器重启或调用AS的API触发弹性伸缩。3.4 连接器与安全管控为了让Skill能安全地执行操作架构中必然包含连接器Connector和权限管理IAM组件。连接器预置了与腾讯云各种服务CVM、CLB、TDSQL、COS等交互的标准化接口简化了Skill开发中调用API的复杂度。权限管理这是安全的重中之重。每个Skill在执行时都会以一个特定的角色Role运行。这个角色通过腾讯云访问管理CAM被精确授予最小必要的权限。例如一个只负责分析日志的Skill其角色可能只有日志服务的“只读”权限而一个负责扩容的Skill其角色则需要被授予弹性伸缩的“写”权限。这种设计确保了自动化操作的安全边界。3.5 技能市场与共享可观测Skill平台很可能规划了一个技能市场。腾讯云官方和第三方开发者可以将通用的、经过验证的Skill如“MySQL慢查询分析”、“Redis内存碎片诊断”发布到市场上供其他用户一键订阅部署。这能极大加速运维能力的沉淀和共享。4. 从零到一构建你的第一个可观测Skill理论讲得再多不如亲手实践。下面我将以一个最经典的场景为例带你一步步创建一个可观测Skill。我们的目标是创建一个自动分析“CPU使用率告警”根因并发送详细诊断报告到企业微信的Skill。4.1 场景定义与准备工作假设我们已在腾讯云监控中为一批生产服务器设置了告警策略当CPU使用率持续3分钟超过80%时触发严重告警。现在我们希望告警触发时能自动分析是系统进程如kswapd0导致还是某个Java应用进程导致并给出初步建议。准备工作确保你拥有目标云服务器CVM所在账号的运维权限。在企业微信群里创建一个“运维报警机器人”获取其Webhook地址。我们将用它来接收消息。在腾讯云控制台确保已开通云监控、云函数SCF、访问管理CAM服务。4.2 创建Skill逻辑云函数这是最核心的一步。我们使用Python语言编写云函数。import json import os import subprocess from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.monitor.v20180724 import monitor_client, models as monitor_models from tencentcloud.cvm.v20170312 import cvm_client, models as cvm_models import requests import re def main_handler(event, context): 主处理函数由云监控告警事件触发。 event结构示例 { Records: [{ Ckafka: {...}, Event: { EventName: AlarmPolicyTrigger, EventVersion: 1.0, Region: ap-guangzhou, Resource: {Entity: ins-xxxxxx}, Content: { PolicyId: policy-xxxx, AlarmStatus: ALARM, AlarmObject: ins-xxxxxx, MetricName: CPUUsage, Value: 95.0, ... // 其他告警详情 } } }] } print(Received event: json.dumps(event)) # 1. 解析事件获取告警实例ID try: alarm_event event[Records][0][Event] instance_id alarm_event[Resource][Entity] # 例如: ins-xxxxxx metric_value alarm_event[Content][Value] region alarm_event[Region] except KeyError as e: print(fFailed to parse event: {e}) return {error: Invalid event format} # 2. 初始化腾讯云客户端使用SCF默认角色或配置临时密钥 # 注意需为SCF执行角色绑定QcloudMonitorReadOnlyAccess、QcloudCVMReadOnlyAccess策略 cred credential.Credential( os.environ.get(TENCENTCLOUD_SECRETID), os.environ.get(TENCENTCLOUD_SECRETKEY), os.environ.get(TENCENTCLOUD_SESSIONTOKEN) ) http_profile HttpProfile(endpointmonitor.tencentcloudapi.com) client_profile ClientProfile(httpProfilehttp_profile) monitor monitor_client.MonitorClient(cred, region, client_profile) # 3. 调用云监控API获取该实例近10分钟的详细监控数据如进程级CPU # 这里简化处理实际应调用GetMonitorData接口筛选proc_cpu等指标 req monitor_models.GetMonitorDataRequest() req.Namespace QCE/CVM req.MetricName CPUUsage req.Period 60 req.StartTime 2023-10-01T00:00:0008:00 # 应替换为动态时间如10分钟前 req.EndTime 2023-10-01T00:10:0008:00 # 应替换为当前时间 req.Instances [{Dimensions: [{Name: InstanceId, Value: instance_id}]}] # 注意此处为示例实际API调用需要处理分页、错误等 # resp monitor.GetMonitorData(req) # process_data resp.DataPoints # 分析进程数据 # 4. 模拟根因分析逻辑 # 在实际生产环境这里可以 # a. 通过云监控API获取proc_cpu指标找出消耗CPU最高的进程。 # b. 或通过SSH需考虑安全组、密钥连接到实例执行 top -bn1 命令不推荐在FaaS中直接SSH。 # c. 更佳实践在实例上部署监控Agent将进程数据上报到CLSSkill从CLS查询。 # 本例我们模拟一个分析结果 analysis_result { instance_id: instance_id, cpu_peak: f{metric_value}%, top_processes: [ {pid: 12345, name: java, cpu_percent: 65.2, command: /usr/bin/java -jar app.jar}, {pid: 67890, name: kswapd0, cpu_percent: 18.5, command: [kswapd0]}, ], likely_root_cause: Java应用进程 app.jar 消耗了超过65%的CPU资源疑似存在计算密集型任务或死循环。, suggested_actions: [ 1. 立即登录实例使用 top -Hp 12345 查看该Java进程的线程状态。, 2. 检查应用日志定位同时段是否有异常任务执行。, 3. 考虑临时重启该Java应用服务。, 4. 长期优化检查应用代码性能或考虑增加实例规格。 ] } # 5. 格式化消息并发送到企业微信 wecom_webhook os.environ.get(WECOM_WEBHOOK_URL) # 在云函数环境变量中配置 if wecom_webhook: markdown_content f** CPU告警根因分析报告** **告警实例**{analysis_result[instance_id]} **CPU峰值**{analysis_result[cpu_peak]} **主要消耗进程** 1. **PID {analysis_result[top_processes][0][pid]}** - {analysis_result[top_processes][0][name]} - CPU占用{analysis_result[top_processes][0][cpu_percent]}% - 命令{analysis_result[top_processes][0][command]} 2. **PID {analysis_result[top_processes][1][pid]}** - {analysis_result[top_processes][1][name]} - CPU占用{analysis_result[top_processes][1][cpu_percent]}% - 命令{analysis_result[top_processes][1][command]} **初步根因判断**{analysis_result[likely_root_cause]} **建议操作** {chr(10).join(analysis_result[suggested_actions])} msg { msgtype: markdown, markdown: {content: markdown_content} } resp requests.post(wecom_webhook, jsonmsg) print(fSent to WeCom, status: {resp.status_code}) else: print(WECOM_WEBHOOK_URL not configured.) return {statusCode: 200, body: json.dumps(analysis_result)}注意以上代码为演示逻辑实际生产使用需要处理更多细节如API调用的错误重试、时间的动态计算、更安全的密钥管理推荐使用SCF的关联角色而非环境变量存储SecretKey、以及更复杂的进程分析算法。4.3 配置触发器与部署创建云函数在腾讯云SCF控制台使用上述代码创建新的函数运行时选择Python 3.7。在“高级配置”中添加环境变量WECOM_WEBHOOK_URL为你机器人的地址。为函数的执行角色配置QcloudMonitorReadOnlyAccess和QcloudCVMReadOnlyAccess策略。配置触发器在函数详情页进入“触发管理”。创建新触发器类型选择“云监控Cloud Monitor告警触发”。选择你之前创建好的“CPU使用率告警”策略。配置事件规则通常选择“告警触发”作为触发条件。测试你可以手动在云监控中恢复告警策略然后再触发一次告警观察SCF的调用日志和企业微信群是否收到了格式化的诊断消息。通过以上步骤一个最简单的可观测Skill就创建完成了。当CPU告警触发时它会自动运行并尝试给出比原始告警更有价值的上下文信息。5. 高级应用场景与技能编排掌握了基础Skill的创建我们可以探索更复杂、更强大的应用模式。可观测Skill的真正威力在于其可组合性和可编排性能够串联多个步骤形成智能化的运维工作流。5.1 场景一全链路故障自愈目标当核心交易接口错误率升高时自动分析链路若确定是某个下游缓存节点故障则自动将其从负载均衡中摘除并通知运维人员。技能链设计Skill A分析由APM的“接口错误率”告警触发。调用APM和链路追踪API分析错误请求的链路特征。如果发现错误集中发生在对某个Redis集群的调用上则触发下一个Skill并传递Redis集群节点IP作为参数。Skill B执行接收节点IP。调用CLB负载均衡或云API网关的API将该故障节点从后端服务器列表中移除或设置为排水模式。Skill C通知调用企业微信/钉钉API发送一条包含故障摘要、影响范围、已执行操作摘除节点的详细通知。这个流程将原本需要人工查看APM、登录LB控制台操作、再发通知的多个步骤压缩到了分钟级甚至秒级内自动完成。5.2 场景二成本优化与资源回收目标每周一凌晨自动扫描所有云服务器找出过去7天内CPU平均使用率持续低于10%且无重要进程的实例生成报告并建议是否可关机或降配。技能链设计Skill A发现由一个定时触发器Cron Trigger每周一0点触发。调用CVM API列出所有实例并发起批量查询任务通过云监控API获取它们过去一周的CPU、内存使用率指标。Skill B判断对每个实例运行判断逻辑如果CPU10%且内存30%再通过标签系统或CMDB接口判断其是否为“测试环境”或“可回收”状态。Skill C报告将符合条件低使用率可回收标签的实例列表、预估月度节省金额生成一个Markdown报告。Skill D审批与执行将报告发送到一个内部审批系统如腾讯云HiFlow连接企业微信审批流。如果审批通过回调一个执行Skill自动对这些实例执行关机或变更配置操作。5.3 场景三安全事件智能响应目标当日志服务CLS检测到大量“SSH暴力破解”日志时自动分析来源IP并将其IP地址临时加入安全组黑名单。技能链设计Skill A检测由CLS的“告警策略”触发告警条件是“同一源IP在1分钟内SSH认证失败日志超过20条”。事件中会包含攻击源IP。Skill B封禁接收源IP。调用VPC安全组API创建一条新的入站规则拒绝该IP对所有端口的访问规则描述注明“由安全Skill自动添加”。Skill C溯源与通知调用IP地理位置查询API第三方或腾讯云市场获取该IP的归属地信息。将攻击事件详情、封禁操作、IP归属地一并发送给安全团队。实操心得在设计复杂技能链时状态管理和错误处理是关键。一个Skill执行失败不能导致整个链条静默失效。建议在每个Skill的输出中包含明确的执行状态success,failed,pending和结果数据。可以使用腾讯云工作流Cloud Flow或简单的状态数据库如Redis来管理流程状态并设置一个兜底的“总控Skill”来监控整个链条的健康状况在失败时发送告警。6. 开发与运维最佳实践将可观测Skill投入生产环境不能只停留在功能实现。遵循以下最佳实践能确保你的Skill稳定、安全、易维护。6.1 技能设计原则单一职责与幂等性单一职责一个Skill只做好一件事。例如“分析根因”和“执行重启”应该拆分成两个Skill。这提高了复用性也便于测试和排错。幂等性你的Skill代码应该支持被多次触发可能由于事件重复投递而产生相同的结果。例如封禁IP的Skill在收到同一个IP时应该先检查安全组规则是否已存在避免创建重复规则。6.2 代码与配置管理版本控制Skill的代码云函数必须纳入Git等版本控制系统。每次变更都应有记录便于回滚和协作。环境分离为开发、测试、生产环境创建不同的腾讯云子账号或命名空间分别部署Skill。避免测试代码影响线上业务。配置外置将所有可变的参数如API网关地址、阈值、通知接收人放在云函数的环境变量或专门的配置中心如腾讯云SSM参数存储中不要硬编码在代码里。6.3 安全与权限管控最小权限原则这是铁律。为每个Skill的执行角色SCF角色授予其完成任务所必需的最小权限。分析型Skill只给读权限执行型Skill精确到具体的API动作如cvm:RestartInstances。网络隔离如果Skill需要访问内网资源如自建数据库请将云函数部署在VPC内并配置好安全组和路由。敏感信息保护用于调用第三方服务的Token、密码等务必使用腾讯云密钥管理系统KMS或参数存储进行加密存储切勿写在代码或明文环境变量中。6.4 可观测性建设对Skill本身完善日志在Skill代码中关键逻辑点打印结构化日志JSON格式方便在SCF控制台或CLS中查询。日志应包含请求ID、执行阶段、关键决策结果等信息。设置监控为你的云函数设置监控告警关注其调用次数、错误率、运行时长和内存使用量。一个频繁失败的Skill本身就会成为运维负担。链路追踪对于复杂的技能链考虑在函数间传递一个唯一的trace_id并将关键操作记录到腾讯云链路追踪服务中便于可视化整个自动化流程的执行路径和耗时。6.5 测试与演练单元测试为Skill的核心分析逻辑编写单元测试确保业务逻辑正确。集成测试在测试环境模拟真实的事件如构造一条告警消息来触发整个Skill或技能链验证端到端的流程。混沌演练定期进行故障演练故意制造一些线上问题如在低峰期观察你的可观测Skill是否能按预期触发并正确响应。这是检验自动化可靠性的最好方法。7. 常见问题与排查技巧实录在实际使用和开发可观测Skill的过程中你肯定会遇到各种问题。下面是我总结的一些典型“坑”和解决思路。7.1 Skill未被触发检查触发器配置首先确认云监控告警策略是否确实处于“告警”状态。在SCF控制台查看函数的触发器和调用日志确认事件是否被正确路由。检查事件格式云监控告警触发的事件格式可能因产品线不同而有细微差别。务必在Skill代码开头打印完整的event对象并与腾讯云官方文档的事件样例进行比对。常见的错误是event[Records][0][Event][Content]的路径访问错误。检查权限确保SCF函数的执行角色拥有从云监控接收事件的权限通常由触发器自动配置以及调用其他云产品API的权限。7.2 Skill执行超时或内存不足优化函数逻辑Skill的设计初衷是快速响应逻辑应轻量。避免在函数内进行大量循环计算或处理巨型数据。将耗时操作如分析大量历史日志改为异步任务或先由其他服务预处理。调整资源配置在SCF函数配置中适当增加超时时间如从3秒调整为30秒和内存大小如从128MB调整为512MB。内存大小会直接影响CPU分配对计算密集型分析有提升。使用异步调用如果Skill执行时间可能较长在创建触发器时选择“异步调用”模式避免因HTTP超时而导致前端失败。7.3 调用云API失败网络问题确保函数部署的地域和要调用的API服务地域一致或者函数配置了公网访问能力。VPC内函数调用公网API可能需要配置NAT网关。鉴权失败这是最常见的问题。仔细检查SCF执行角色的CAM策略。可以使用腾讯云的 策略生成器 或 策略语法验证 工具来确保策略正确。错误信息通常是AuthFailure或PermissionDenied。API版本或参数错误腾讯云SDK和API可能会更新。确保你安装的Python SDKtencentcloud-sdk-python版本是最新的并且传入的请求参数符合API文档要求。开启SDK的调试日志有助于定位问题。7.4 技能链中信息传递丢失规范数据格式在技能链中前一个Skill的输出会成为后一个Skill的输入。约定一个清晰、稳定的JSON格式作为Skill间的“合约”。建议包含request_id、stage、data、error等字段。使用状态存储对于多步骤、长时间运行的流程不要依赖函数间的直接参数传递。应该将中间状态和结果存储到持久化存储中如腾讯云数据库TDSQLMySQL、RedisCKV或对象存储COS。每个Skill只负责读写自己相关的部分。7.5 告警风暴导致Skill被频繁调用在触发器层过滤这是最重要的防线。充分利用事件总线或触发器规则的条件过滤功能只针对最关键、最需要自动化的告警进行触发。例如只对“严重”级别的告警或者对持续了N分钟的告警触发Skill。在Skill逻辑中限流在Skill代码开头可以加入简单的限流逻辑。例如利用Redis记录每个告警对象如实例ID最后一次被处理的时间如果短时间内再次触发则跳过本次执行仅记录日志。设置并发限制在SCF函数配置中可以设置该函数的“保留并发”或“最大并发”数防止因突发的大量告警导致函数实例无限扩容产生不可控的费用和下游服务压力。7.6 调试与日志查看技巧本地测试强烈建议在本地搭建测试环境。你可以模拟一个告警事件的JSON文件使用SCF的本地调试工具如scf local invoke来运行函数快速验证逻辑。善用日志服务CLS将SCF函数的日志投递到CLS。利用CLS强大的检索和可视化能力你可以轻松地通过request_id追踪一次完整的Skill执行过程或者通过关键词过滤错误日志。使用临时调试代码在开发阶段可以在函数中临时加入向一个“调试接收端”如一个临时的Webhook或日志文件发送详细中间结果的代码便于分析逻辑流程。上线前务必移除。可观测Skill的引入标志着运维自动化从“脚本化”走向“服务化”、“智能化”。它不再是一个个孤立的脚本而是一个有触发、有逻辑、有执行、可观测、可管理的有机整体。对于运维团队而言早期投入一些精力去规划和建设这些Skill就像打造一套自动化流水线初期有成本但长远来看它将把团队从无尽的、低价值的重复告警处理中解放出来让我们能有更多时间去思考架构的韧性、系统的性能和业务的连续性这些更有挑战的课题。 
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
