关于 azure-observability-workflows
面向 Claude 的技能，用于规划和实施 Microsoft Azure 应用的可观测性。它涵盖遥测、分布式追踪、集中监控、仪表板和可执行告警，适用于生产系统。
主要功能
- 01Azure 可观测性规划
- 02集中管理日志与指标
- 03配置分布式追踪
- 04监控仪表板与告警
- 05验证生产遥测
适用场景
- 01监控生产环境中的 Azure 应用
- 02追踪微服务间的请求
- 03诊断故障与性能瓶颈
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/azure-observability-workflows确认已加载。
详细介绍
Azure 可观测性工作流
概述
此技能可帮助 Claude 为运行在 Microsoft Azure 上的应用设计并实现可观测性系统。
工作流侧重于：
- 分布式追踪
- 集中式日志记录
- 指标收集
- 云监控
- 遥测管道
- 事件诊断
- 告警系统
- 生产环境可视性
目标是让云系统具备以下特性：
- 可观测
- 可调试
- 可度量
- 可靠
- 可用于生产环境
可观测性系统不应等到故障发生后才做出响应，而应主动发现：
- 瓶颈
- 错误
- 性能下降
- 异常的系统行为
- 基础设施不稳定
此工作流优先保障分布式系统的运维可视性和调试质量。
设置
开始之前：
-
创建 Azure 帐户： https://azure.microsoft.com
-
安装 Azure CLI：
az login
- 启用 Azure 监控服务。
推荐使用的 Azure 服务：
- Azure Monitor
- Application Insights
- Log Analytics
- Azure Dashboard
- Azure Alerts
推荐工具：
- VS Code
- Azure Portal
- Grafana
- OpenTelemetry
- Docker
- Kubernetes（可选）
可选：
- Prometheus
- Jaeger
- Azure Managed Grafana
- 分布式追踪系统
所需输入
- 应用架构
- 云基础设施
- 部署环境
- 服务依赖项
- 监控目标
可选：
- 现有遥测系统
- 日志管道
- Kubernetes 集群
- 事件历史记录
适用场景
在以下情况使用此技能：
- 部署生产应用
- 调试分布式系统
- 监控云基础设施
- 跟踪应用性能
- 诊断事件
- 实施 SRE 工作流
- 扩展微服务
- 提高运维可靠性
不适用场景
以下情况不要使用此技能：
- 一次性原型
- 微型且仅在本地运行的应用
- 无生产环境要求的系统
- 无需运维监控的工作流
使用示例
为分布式 Azure 微服务平台构建可观测性基础设施。
Claude 应当：
- 配置遥测管道
- 启用分布式追踪
- 集中管理日志
- 创建监控仪表板
- 配置告警
- 跟踪基础设施运行状况
- 主动诊断故障
最终结果应当：
- 加快调试速度
- 快速发现生产环境问题
- 提高运维可视性
- 支持可扩展的云监控
- 提高可靠性和正常运行时间
可观测性的核心原则
1. 仅靠日志还不够
现代可观测性需要：
- 日志
- 指标
- 追踪
- 遥测
- 分布式上下文
Claude 应结合：
- 应用日志
- 基础设施指标
- 请求追踪
- 依赖项监控
优秀的可观测性系统能够提供：
- 可视性
- 诊断能力
- 运维洞察
2. 分布式系统需要分布式追踪
微服务会带来：
- 请求链路
- 异步通信
- 隐藏的瓶颈
- 跨服务故障
Claude 应实施：
- 追踪关联
- 请求 ID
- 分布式 Span
- 依赖项跟踪
分布式追踪有助于：
- 加快调试速度
- 发现瓶颈
- 分析根本原因
3. 集中监控
可观测性数据应集中管理。
推荐系统：
- Azure Monitor
- Application Insights
- Log Analytics
- Grafana 仪表板
集中管理有助于：
- 调试
- 事件响应
- 运维可视性
避免：
- 零散的日志系统
- 孤立的指标
- 互不关联的仪表板
4. 监控重要指标
并非所有指标都同样有价值。
Claude 应优先关注：
- 延迟
- 错误率
- 吞吐量
- 资源利用率
- 请求失败
- 依赖项运行状况
避免：
- 噪声过多的仪表板
- 虚荣指标
- 缺乏明确用途的过量遥测
优秀的监控有助于：
- 提高可靠性
- 制定扩展决策
- 检测事件
5. 告警应具有可操作性
糟糕的告警系统会导致：
- 告警疲劳
- 通知被忽略
- 运维混乱
Claude 应配置告警，以便捕获：
- 真实事件
- 有意义的阈值
- 可采取行动的故障
- 影响生产环境的问题
良好的告警可以改善：
- 运维响应
- 正常运行时间
- 调试速度
工作流
1. 分析系统架构
首先识别：
- 服务
- API
- 数据库
- 队列
- 基础设施依赖项
确定：
- 关键工作流
- 故障点
- 性能瓶颈
- 可观测性缺口
了解：
- 请求流
- 服务边界
- 扩展行为
2. 配置遥测数据收集
启用：
- 应用日志
- 基础设施指标
- 分布式追踪
- 依赖项监控
使用：
- Application Insights
- Azure Monitor
- OpenTelemetry
验证：
- 遥测数据的一致性
- 追踪传播
- 关联 ID
3. 集中管理日志和指标
将以下数据路由到集中式系统：
- 日志
- 追踪
- 指标
- 诊断信息
推荐使用：
- Log Analytics
- Azure Monitor
- Grafana
确保：
- 日志可搜索
- 遥测数据采用结构化格式
- 格式保持一致
4. 实施分布式追踪
追踪：
- 请求
- 服务依赖项
- API 调用
- 异步工作流
使用：
- 追踪 ID
- Span 关系
- 请求关联
分布式追踪可改善：
- 调试
- 延迟分析
- 依赖项可见性
5. 创建仪表板
构建用于查看以下内容的仪表板：
- 基础设施运行状况
- 应用性能
- 错误追踪
- 队列处理
- API 延迟
- 服务依赖项
仪表板应保持：
- 易读
- 可操作
- 对运维有用
避免：
- 杂乱的仪表板
- 过多图表
- 无关指标
6. 配置告警
针对以下情况创建告警：
- 服务停机
- 延迟激增
- 故障率过高
- 队列积压
- 资源耗尽
告警应：
- 减少噪声
- 保持可操作
- 触发适当的升级流程
7. 验证生产环境的可观测性
部署前验证：
- 日志可搜索
- 追踪正确传播
- 指标持续更新
- 告警正确触发
- 仪表板易于查看
确保：
- 可以快速诊断事件
- 遥测数据保持可靠
- 系统在负载下仍可观测
输出预期
最终输出应包括：
- 集中式可观测性系统
- 分布式追踪管道
- 可操作的监控仪表板
- 生产遥测系统
- 可扩展的诊断基础设施
- 云原生运维可见性
工作流本身应保持：
- 可扩展
- 可观测
- 面向生产环境
- 便于调试
- 运维可靠
执行策略（适用于 AI Agent）
Agent 应：
- 将可观测性视为基础设施
- 积极集中管理遥测数据
- 持续一致地实施分布式追踪
- 优先实现可操作的监控
- 主动减少告警噪声
- 优化运维可见性和调试质量
工作流应优化：
- 可靠性
- 调试速度
- 运维清晰度
- 事件响应质量
- 云可扩展性
最佳实践
- 始终使用结构化日志
- 尽早实施分布式追踪
- 集中管理指标和日志
- 密切监控延迟和错误率
- 确保仪表板具有可操作性
- 避免告警疲劳
- 在生产负载下验证可观测性
备注
- 分布式追踪可显著改善微服务调试
- 可观测性质量会显著影响运维可靠性
- 可操作的仪表板优于充斥噪声的遥测系统
- 良好的告警可显著减轻运维人员的倦怠
- 可观测性系统应随着基础设施的增长持续演进
评论
支持 Markdown