ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

AWS CLI 实战:使用 application-signals list-services 查询 CloudWatch Application Signals 已发现的服务

AWS CLI 实战:使用 application-signals list-services 查询 CloudWatch Application Signals 已发现的服务 AWS CLI 实战使用 application-signals list-services 查询 CloudWatch Application Signals 已发现的服务【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本文围绕 AWS CLI 仓库中的示例文档 awscli/examples/application-signals/list-services.rst 展开讲解aws application-signals list-services命令的完整用法、参数取值范围与输出结构并结合仓库内打包的 API 模型awscli/botocore/data/application-signals/2024-04-15/service-2.json深入解析每个字段的含义与分页机制。读完本文你将能够独立编写该查询命令、正确解读返回的服务摘要ServiceSummaries并理解时间参数、分页 token 和指标引用MetricReferences的底层约定。命令作用与 API 背景Application Signals 是 Amazon CloudWatch 的应用信号功能它通过应用插桩instrumentation自动发现你账号中的服务并汇总其关键指标与依赖关系。list-services对应的 API 操作是ListServices其官方定义可概括为Returns a list of services that have been discovered by Application Signals. A service represents a minimum logical and transactional unit that completes a business function. Services are discovered through Application Signals instrumentation.从仓库中的 API 模型可以看到见 service-2.json 中ListServices的定义约第 373–388 行HTTP 方法为GET请求路径为/services成功响应码 200该操作被标记为readonly: true即只读操作不会改变任何账号状态输入形状为ListServicesInput输出形状为ListServicesOutput可能抛出的错误为ValidationException参数校验失败和ThrottlingException请求被限流。这意味着你在脚本中批量调用该命令时只需关注参数合法性与限流重试无需担心误操作产生副作用。官方示例完整命令与输出示例文档给出的最基础调用只需两个必选时间参数aws application-signals list-services \ --start-time 1734918791 \ --end-time 1734965591示例文档记录的对应输出如下保留原文档的完整结构{ ServiceSummaries: [{ KeyAttributes: { Environment: lambda:default, Name: hello-world-python, Type: Service }, AttributeMaps: [{ Lambda.Function.Name: hello-world-python, PlatformType: AWS::Lambda }], MetricReferences: [{ Namespace: ApplicationSignals, MetricType: LATENCY, Dimensions: [{ Name: Environment, Value: lambda:default }, { Name: Service, Value: hello-world-python }], MetricName: Latency }, { Namespace: ApplicationSignals, MetricType: FAULT, Dimensions: [{ Name: Environment, Value: lambda:default }, { Name: Service, Value: hello-world-python }], MetricName: Fault }, { Namespace: ApplicationSignals, MetricType: ERROR, Dimensions: [{ Name: Environment, Value: lambda:default }, { Name: Service, Value: hello-world-python }], MetricName: Error }] }], StartTime: 2024-11-27T10:00:0000:00, EndTime: 2024-11-27T14:00:0100:00 }这个示例展示了一个运行在 Lambda 上的 Python 函数hello-world-python被 Application Signals 发现后的摘要形态KeyAttributes标识服务身份AttributeMaps补充了平台属性MetricReferences给出了可直接用于 CloudWatch 查询的三个核心指标延迟、故障、错误。输入参数详解基于 API 模型示例命令只用了两个必选参数但 API 模型ListServicesInput形状service-2.json 约第 3151–3195 行定义了更多可选项。完整参数表如下CLI 参数对应 API 成员类型/范围必选说明--start-timeStartTime时间戳epoch 秒是查询时间窗起点。原始 HTTP Query API 中以秒为单位的 epoch 时间表示例如1698778057请求的开始时间会被四舍五入到最近的一小时--end-timeEndTime时间戳epoch 秒是查询时间窗终点同样会被处理到最近的小时粒度--max-resultsMaxResults整数最小 1、最大 100否单次操作返回的最大服务数量。省略时使用默认值 50--next-tokenNextToken字符串否传入上一次操作返回的 token以获取下一批服务--include-linked-accountsIncludeLinkedAccounts布尔否在多账号监控场景monitoring account下指定true可把源账号source accounts中的服务也纳入返回结果--aws-account-idAwsAccountId账号 ID 字符串否指定 Amazon Web Services Account ID用于跨账号查询场景两个值得注意的实现细节均来自模型中的参数文档描述时间会被取整StartTime/EndTime的文档明确写道 Your requested start time will be rounded to the nearest hour。所以用该命令查询时时间窗的精度是小时级的而不是秒级。MaxResults上限为 100ListServicesMaxResults形状定义为max: 100, min: 1传入大于 100 的值会触发ValidationException。如果账号中发现的服务数超过单页上限必须配合分页参数获取完整列表。输出结构逐项解读ListServicesOutput形状要求三个必选字段StartTime、EndTime、ServiceSummaries可选字段为NextToken。返回的时间字段输出中的StartTime与EndTime不是你请求值的原样回显而是 Application Signals 实际用于本次查询的时间This displays the time that Application Signals used for the request. It might not match your request exactly, because it was rounded to the nearest hour.因此在编写自动化脚本时应以返回的时间字段为准来判断数据覆盖范围而不是以命令行传入的值为准。ServiceSummary服务摘要ServiceSummaries是ServiceSummary结构数组每个结构必选KeyAttributes与MetricReferences可选AttributeMaps、ServiceGroups。各字段含义如下KeyAttributes字符串到字符串的映射用于标识被发现的实体。可包含Type对象类型如示例中的ServiceResourceType当Type为Resource或AWS::Resource时使用指定资源类型Name当Type为Service、RemoteService或AWS::Service时使用指定对象名称示例中为hello-world-pythonIdentifier当Type为资源类型时用于标识该资源Environment对象所属的运行环境或归属位置示例中为lambda:default。AttributeMaps一个或多个字符串映射用于进一步识别服务按文档分为三类平台属性PlatformType示例中为AWS::Lambda、EKS.Cluster、K8s.Cluster/K8s.Namespace/K8s.Workload/K8s.Node/K8s.Pod、EC2.AutoScalingGroup、EC2.InstanceId、Host应用属性AWS.Application、AWS.Application.ARN对应 Service Catalog AppRegistry 中的应用遥测属性Telemetry.SDKOpenTelemetry SDK 指纹、Telemetry.Agent采集 agent 指纹、Telemetry.Source遥测来源。MetricReferences该服务关联的 CloudWatch 指标数组每项即一个MetricReference结构。ServiceGroups按配置的分组属性grouping attributes对该服务分组后的结果数组。MetricReference指标引用MetricReference结构必选Namespace、MetricType、MetricName可选Dimensions与AccountIdNamespace指标命名空间示例中为ApplicationSignalsMetricType指标类型用于在 CloudWatch 控制台展示合适的统计量示例中出现LATENCY、FAULT、ERRORMetricName指标名Latency、Fault、ErrorDimensions维度数组示例中每条引用都带有Environment与Service两个维度。拿到这些引用后你可以直接组合出aws cloudwatch get-metric-data/metric-stat查询把 Application Signals 的服务摘要与 CloudWatch 原始指标数据打通。获取完整服务信息ServiceSummaries只是摘要。模型中对ServiceSummaries的文档明确建议To get complete information about a service, use GetService.即使用aws application-signals get-service传入目标服务可获取完整详情本仓库同样收录了该操作的示例 awscli/examples/application-signals/get-service.rst。分页与工程化使用ListServices在仓库的分页配置中注册为 token 分页见 awscli/botocore/data/application-signals/2024-04-15/paginators-1.jsonListServices: { input_token: NextToken, output_token: NextToken, limit_key: MaxResults, result_key: ServiceSummaries }这带来两种实践方式自动分页调用 AWS CLI 时可通过分页器机制自动迭代所有结果页以NextToken为页间游标、MaxResults为页大小适合在脚本中枚举全部已发现服务手动分页检查响应中是否包含NextToken若存在则将其作为下一次调用的--next-token参数传入直到响应不再返回 token。一个典型的全量枚举流程是先以--max-results 100拉取首页循环传入--next-token最后把每页的ServiceSummaries合并。若需覆盖多账号监控场景再加上--include-linked-accounts true与--aws-account-id参数。前置条件与相关命令需要说明的是list-services只能列出已经被 Application Signals 发现的服务。发现流程依赖服务插桩而账号级初始化由start-discovery完成——它会创建AWSServiceRoleForCloudWatchApplicationSignals服务关联角色拥有xray:GetServiceGraph、logs:StartQuery、cloudwatch:GetMetricData等权限并建立 CloudTrail 事件通道之后仍需对 Java/Python 应用完成插桩才会产生可被发现的服务。对应示例见 awscli/examples/application-signals/start-discovery.rst。list-services属于一套服务发现查询命令中的一环同目录 awscli/examples/application-signals/ 下还收录了配套示例可按需串联使用get-service.rst查询单个服务的完整信息list-service-dependencies.rst列出服务的下游依赖list-service-dependents.rst列出调用该服务的上游list-service-operations.rst列出服务的操作list-service-level-objectives.rst列出服务级别目标SLO。示例文档如何进入 CLI 帮助从源码结构看这类.rst示例文件并非孤立存放AWS CLI 通过定制插件 awscli/customizations/addexamples.py 在doc-examples.*.*事件触发时按examples/service/op.rst的命名规则查找示例文件并将其内容以 Examples 小节注入到对应操作的帮助文档中该插件会先输出一段提示说明运行示例需要已安装并配置好 AWS CLI且示例采用类 Unix 的引号规则。因此你在终端执行aws application-signals list-services help时看到的使用示例正是来源于 awscli/examples/application-signals/list-services.rst 这份文档本身。小结aws application-signals list-services是只读查询操作GET /services必选参数为--start-time与--end-timeepoch 秒会被取整到最近的小时单页结果上限 100、默认 50完整列表需通过--next-token分页获取多账号场景使用--include-linked-accounts与--aws-account-id输出的ServiceSummaries提供每个已发现服务的身份属性KeyAttributes、平台/应用/遥测属性AttributeMaps和可直接用于 CloudWatch 查询的指标引用MetricReferences需要完整服务详情时进一步调用aws application-signals get-service。更多背景可参考Amazon CloudWatch User Guide中关于 Application Signals 的章节以及本仓库中awscli/botocore/data/application-signals/2024-04-15/下的完整 API 模型文件。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表