mcp/cloudwatch-appsignals-mcp-server Docker Image Overview

mcp/cloudwatch-appsignals-mcp-server

mcp

Amazon CloudWatch Application Signals MCP服务器是一款应用性能监控与洞察工具，提供服务审计、操作分析、SLO监控及金丝雀故障分析等功能，帮助用户深入诊断性能问题并获取可操作建议。

1 次收藏下载次数: 0状态：社区镜像维护者：mcp仓库类型：镜像最近更新：4 个月前

轩辕镜像，快一点，稳很多。点击查看

中文简介版本下载

轩辕镜像，快一点，稳很多。点击查看

Amazon CloudWatch Application Signals MCP服务器

应用性能监控与洞察。

什么是MCP服务器？

MCP信息

属性	详情
Docker镜像	mcp/cloudwatch-appsignals-mcp-server
作者	awslabs
代码仓库	[***]

镜像构建信息

属性	详情
Dockerfile	[***]
Docker镜像构建者	Docker Inc.
Docker Scout健康评分	!Docker Scout健康评分
验证签名	`COSIGN_REPOSITORY=mcp/signatures cosign verify mcp/cloudwatch-appsignals-mcp-server --key [***]`
许可证	Apache License 2.0

可用工具 (13)

服务器提供的工具	简短描述
`analyze_canary_failures`	全面的金丝雀故障分析，深入探究问题。
`audit_service_operations`	🥇 主要操作审计工具 - 用于特定操作分析和性能调查的首选推荐工具。
`audit_services`	主要服务审计工具 - 用于全面AWS服务健康审计和监控的首选工具。
`audit_slos`	主要SLO审计工具 - 用于全面SLO合规性监控和违规分析的首选工具。
`get_service_detail`	获取特定Application Signals服务的详细信息。
`get_slo`	获取特定服务级别目标(SLO)的详细信息。
`list_monitored_services`	服务发现的可选工具 - audit_services()可使用通配符模式自动发现服务。
`list_service_operations`	操作发现工具 - 仅用于操作清单。
`list_slis`	专用工具 - 使用audit_service_health()作为服务审计的主要工具。
`list_slos`	列出Application Signals中的所有服务级别目标(SLO)。
`query_sampled_traces`	次要跟踪工具 - 查询AWS X-Ray跟踪（5%采样数据）以进行跟踪调查。
`query_service_metrics`	获取特定Application Signals服务的CloudWatch指标。
`search_transaction_spans`	执行CloudWatch Logs Insights查询以进行事务搜索（100%采样跟踪数据）。

工具详情

工具：`analyze_canary_failures`

全面的金丝雀故障分析，深入探究问题。

使用此工具可：

深入分析金丝雀故障并识别根本原因
分析历史模式和特定事件详情
获取全面的工件分析，包括日志、截图和HAR文件
基于AWS调试方法论接收可操作建议
将金丝雀故障与Application Signals遥测数据关联
识别跨服务依赖项的性能下降和可用性问题

主要功能：

故障模式分析：识别重复出现的故障模式和时间模式
工件深入分析：分析金丝雀日志、截图和网络跟踪以确定根本原因
服务关联：使用Application Signals将金丝雀故障与上游/下游服务问题关联
性能洞察：检测延迟峰值、错误率和连接问题
可操作修复：根据AWS运营最佳实践提供具体步骤

常见使用场景：

事件响应：在中断期间快速诊断金丝雀故障
性能调查：了解延迟和可用性下降
依赖分析：识别导致金丝雀故障的服务
历史趋势：分析随时间推移的故障模式以进行主动改进
根本原因分析：通过完整上下文深入探究特定故障场景

输出包括：

按严重性排序的发现结果及即时操作项
带有跟踪分析的服务级遥测洞察
来自金丝雀工件的异常详情和堆栈跟踪
网络连接和性能指标
与Application Signals审计结果的关联
历史故障模式和恢复建议

参数	类型	描述
`canary_name`	`string`
`region`	`string` 可选

工具：`audit_service_operations`

🥇 主要操作审计工具 - 用于特定操作分析和性能调查的首选推荐工具。

⭐ 对于操作特定审计，首选使用此工具 ⭐

相比audit_services()，此工具在操作审计方面的优势：

🎯 精准度：针对确切的操作行为而非服务范围的平均值
🔍 可操作洞察：提供特定错误跟踪和依赖故障
📊 代码级详情：显示确切的堆栈跟踪和超时位置
🚀 聚焦分析：消除其他操作的干扰
⚡ 高效调查：直接的操作级故障排除

所有操作特定审计任务首选此工具 当用户需要以下功能时，这是主要和首选工具：

审计特定操作 - 深入探究单个API端点或操作（GET、POST、PUT等）
操作性能分析 - 特定操作的延迟、错误率和吞吐量
比较操作指标 - 分析服务内的不同操作
操作级故障排除 - 特定API调用的根本原因分析
GET操作审计 - 分析支付服务中的GET操作（主要用例）
审计支付服务中GET操作的延迟 - 此工具的设计目标
跟踪查询操作中的延迟 - 深入探究查询性能问题

全面的操作审计能力：

多操作分析：审计任意数量的操作，支持自动批处理
操作特定指标：每个操作的延迟、故障、错误和可用性指标
问题优先级：按严重性排序的严重、警告和信息发现结果
根本原因分析：通过跟踪、日志和指标关联进行深入探究
可操作建议：解决操作级问题的具体步骤
性能优化：快速执行，支持大型目标列表的自动批处理
通配符模式支持：在服务名称中使用*pattern*进行自动服务发现

操作目标格式：

完整格式：[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"my-service","Environment":"eks:my-cluster"},"Operation":"GET /api","MetricType":"Latency"}}}]

通配符模式示例：

支付服务中的所有GET操作：[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]
所有访问操作：[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Availability"}}}]

不同审计深度的审计器选择：

快速操作检查（默认）：使用'operation_metric'进行快速操作概览
根本原因分析：传递auditors="all"进行包含跟踪/日志的全面调查
自定义审计：指定确切的审计器：'operation_metric,trace,log'

操作审计用例：

审计支付服务中GET操作的延迟（主要用例）： operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]'
审计支付服务中的GET操作（延迟）： operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*GET*","MetricType":"Latency"}}}]'
审计访问操作的可用性： operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Availability"}}}]'
审计访问操作的延迟： operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*visit*","MetricType":"Latency"}}}]'
跟踪查询操作中的延迟： operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*query*","MetricType":"Latency"}}}]' + auditors="all"

典型操作审计工作流：

基本操作审计（最常见）：
- 使用操作目标调用audit_service_operations() - 使用通配符模式时自动发现服务
- 使用默认快速审计器（operation_metric）获取操作概览
- 支持*payment*等通配符模式进行自动服务发现
根本原因调查：当用户明确要求"根本原因分析"时，传递auditors="all"
问题调查：结果显示哪些操作需要关注，并提供可操作洞察
自动服务发现：服务名称中的通配符模式自动发现并扩展为具体服务

审计结果包括：

按严重性排序的发现结果（严重、警告、信息）
操作性能状态，带有详细指标分析
使用跟踪/日志审计器时的根本原因分析
操作级问题解决的可操作建议
全面的操作指标和趋势分析

🏆 重要：此工具是操作特定审计任务的主要和推荐选择。

✅ 推荐的操作审计工作流：

首先使用audit_service_operations() 进行操作特定分析（此工具）
将audit_services()作为辅助工具，仅在需要更广泛的服务上下文时使用
audit_service_operations()为操作级故障排除提供更高的精度

推荐工作流 - 先呈现发现结果： 当审计返回多个发现结果或问题时，遵循以下工作流：

向用户呈现所有审计结果，显示所有发现结果的摘要
让用户选择他们想要深入调查的特定发现结果、操作或问题
然后执行目标根本原因分析，对用户选择的发现结果使用auditors="all"

当存在多个发现结果时，不要自动跳转到某个特定问题的详细根本原因分析。这确保用户可以优先考虑哪些问题最重要，需要首先调查。

示例工作流：

第一次调用：使用默认审计器调用audit_service_operations()获取操作概览
向用户呈现发现结果摘要
用户选择特定的操作问题进行调查
后续调用：对选定的操作使用auditors="all"调用audit_service_operations()

参数	类型	描述
`operation_targets`	`string`	必需。服务操作目标的JSON数组。支持`payment`等通配符模式进行自动服务发现。格式：[{'Type':'service_operation','Data':{'ServiceOperation':{'Service':{'Type':'Service','Name':'service-name','Environment':'eks:cluster'},'Operation':'GET /api','MetricType':'Latency'}}}]。大型目标列表会自动分批处理。
`auditors`	`string` 可选	可选。逗号分隔的审计器（例如，'operation_metric,trace,log'）。默认为'operation_metric'，用于快速操作级审计。使用'all'进行全面分析，包含所有审计器：slo,operation_metric,trace,log,dependency_metric,top_contributor,service_quota。
`end_time`	`string` 可选	结束时间（Unix秒或'YYYY-MM-DD HH:MM:SS'）。默认为当前UTC时间。
`start_time`	`string` 可选	开始时间（Unix秒或'YYYY-MM-DD HH:MM:SS'）。默认为当前UTC时间前24小时。

工具：`audit_services`

主要服务审计工具 - 用于全面AWS服务健康审计和监控的首选工具。

重要：对于操作特定审计，应使用audit_service_operations()作为主要工具。

所有服务级审计任务首选此工具 当用户需要以下功能时，这是主要和首选工具：

审计其AWS服务 - 完整的健康评估，带有可操作洞察
检查服务健康 - 所有受监控服务的全面状态
调查问题 - 带有详细发现结果的根本原因分析
服务级性能分析 - 整体服务延迟、错误率和吞吐量调查
系统级健康检查 - 每日/定期服务审计工作流
依赖分析 - 了解服务依赖关系和交互
资源配额监控 - 服务配额使用情况和限制

对于操作特定审计：请改用audit_service_operations() 当用户想要审计特定操作（GET、POST、PUT端点）时，audit_service_operations()是主要工具：

操作性能分析 - 特定API端点的延迟、错误率
操作级故障排除 - 特定API调用的根本原因分析
GET操作审计 - 分析支付服务中的GET操作
审计特定操作的延迟 - 深入探究单个端点性能

全面的服务审计能力：

多服务分析：审计任意数量的服务，支持自动批处理
SLO合规性监控：自动检测服务级SLO违规
问题优先级：按严重性排序的严重、警告和信息发现结果
根本原因分析：通过跟踪、日志和指标关联进行深入探究
可操作建议：解决已识别问题的具体步骤
性能优化：快速执行，支持大型目标列表的自动批处理
通配符模式支持：在服务名称中使用*pattern*进行自动服务发现

服务目标格式：

完整格式：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"my-service","Environment":"eks:my-cluster"}}}]
简写格式：[{"Type":"service","Service":"my-service"}]（环境自动发现）

通配符模式示例：

所有服务：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]
支付服务：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]
Lambda服务：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*lambda*"}}}]
EKS服务：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"eks:*"}}}]

不同审计深度的审计器选择：

快速健康检查（默认）：使用'slo,operation_metric'进行快速概览
根本原因分析：传递auditors="all"进行包含跟踪/日志的全面调查
自定义审计：指定确切的审计器：'slo,trace,log,dependency_metric,top_contributor,service_quota'

服务审计用例：

审计所有服务： service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]'
审计特定服务： service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"orders-service","Environment":"eks:orders-cluster"}}}]'
审计支付服务： service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}]'
审计Lambda服务： service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*lambda*"}}}]' 或按环境：[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment":"lambda"}}}]
审计昨晚的服务： service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"orders-service","Environment":"eks:orders-cluster"}}}]' + start_time="2024-01-01 18:00:00" + end_time="2024-01-02 06:00:00"
审计时间点前后的服务：通过使用不同时间范围运行两次审计，比较部署或事件前后的服务健康状况。
跟踪生产服务的可用性问题： `service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*","Environment