ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

使用 AWS CLI `cloudwatch put-dashboard` 创建与更新 CloudWatch 仪表盘

使用 AWS CLI `cloudwatch put-dashboard` 创建与更新 CloudWatch 仪表盘 使用 AWS CLIcloudwatch put-dashboard创建与更新 CloudWatch 仪表盘【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读本文以 AWS CLI 官方示例文档 put-dashboard.rst 为核心结合仓库内 CloudWatch 服务模型service-2.json与配套示例get-dashboard.rst、delete-dashboards.rst系统讲解aws cloudwatch put-dashboard命令的完整用法。读完本文你将掌握如何用一条命令以 JSON 方式声明式创建仪表盘、理解dashboard-body中每个 widget 字段的含义、解析返回的DashboardValidationMessages校验结果并通过get-dashboard、delete-dashboards、tag-resource等命令完成仪表盘全生命周期管理。命令概览一条命令创建整张仪表盘在 AWS CLI 中创建 CloudWatch 仪表盘对应的命令是aws cloudwatch put-dashboard \ --dashboard-name 仪表盘名称 \ --dashboard-body 仪表盘 JSON 结构该命令面向的是 CloudWatch 服务的PutDashboardAPI 操作。从仓库的服务模型 service-2.json 的接口文档可以确认它的核心语义有则更新无则创建PutDashboard会“创建不存在的仪表盘或更新已存在的仪表盘如果更新整个内容将被本命令指定的内容完全替换”全局性所有仪表盘在账户级别是全局的不区分区域All dashboards in your account are global, not region-specific幂等替换更新时不是增量合并而是整份 JSON 覆盖——这也意味着误操作会直接覆盖已有仪表盘建议先get-dashboard备份再修改。官方示例创建名为 Dashboard-A 的仪表盘仓库中的 put-dashboard.rst 给出了最小可运行的完整示例创建一个名为Dashboard-A的仪表盘aws cloudwatch put-dashboard \ --dashboard-name Dashboard-A \ --dashboard-body {widgets:[{height:6,width:6,y:0,x:0,type:metric,properties:{view:timeSeries,stacked:false,metrics:[[Namespace,CPUUtilization,Environment,Prod,Type,App]],region:us-east-1}}]}对应的命令输出{ DashboardValidationMessages: [] }当返回的DashboardValidationMessages为空数组时说明仪表盘已成功创建或更新。下面逐层拆解这条命令。参数一--dashboard-name仪表盘名称含义与约束定义在服务模型的PutDashboardInput中service-2.json必填DashboardName与DashboardBody均为required字段长度最大 255 个字符合法字符仅允许A-Z、a-z、0-9、-和_行为若该名称的仪表盘已存在本次调用将替换其全部内容否则创建新仪表盘。参数二--dashboard-body仪表盘核心结构以 JSON 字符串形式传入其中widgets数组定义了每个组件及其在画布上的位置。官方示例中的单个 widget 字段含义如下字段值含义typemetric组件类型本例为指标图metric widget还可取text文本、alarm告警、logs日志等类型x/y0/0组件左上角在画布上的网格坐标x 为列、y 为行width/height6/6组件的宽高以网格单元计整套画布共 24 列宽properties.viewtimeSeries渲染视图timeSeries为时序图另有bar柱状图、pie饼图、number数值等properties.stackedfalse是否堆叠显示多条时间序列properties.metrics[[Namespace,CPUUtilization,Environment,Prod,Type,App]]要绘制的指标定义数组见下文properties.regionus-east-1指标数据所在的区域其中metrics数组的写法是 CloudWatch 仪表盘 JSON 的独特语法每一条序列用一组数组表示第一个元素是命名空间Namespace第二个是指标名之后的元素按[维度名,维度值]成对出现。本例中即命名空间Namespace此处为占位写法实际使用中应替换为如AWS/EC2等服务命名空间指标名CPUUtilization维度对[Environment,Prod]、[Type,App]即展示Namespace命名空间下、维度组合为EnvironmentProd且TypeApp的CPUUtilization指标时序。关于dashboard-body的完整语法与各 widget 类型定义AWS 服务模型文档建议参考 Dashboard Body Structure and Syntax见 service-2.json 中的指引。最稳妥的实践是先用控制台或现有仪表盘的get-dashboard导出 JSON 作为模板再修改后回灌。理解返回结果DashboardValidationMessages 的三种语义put-dashboard的返回值只有一个字段DashboardValidationMessages其类型在服务模型中被定义为DashboardValidationMessage的列表service-2.json每条消息包含两个成员DataPath与消息相关的数据路径即仪表盘 JSON 中出问题的字段定位Message描述错误或警告的具体文本。根据PutDashboardOutput的接口文档service-2.json该字段存在三种语义不能只把空数组当成唯一正确结果空数组输入正确仪表盘成功创建或修改官方示例即此场景仅包含警告消息输入基本有效仪表盘已创建或修改但某些元素可能无法正常渲染例如引用了不存在的指标维度、视图类型不受支持等包含错误消息输入无效操作失败需要根据Message修正后再重试。因此在脚本化创建仪表盘时应检查该字段是否非空、并区分警告与错误级别避免“命令返回成功但仪表盘是坏的”这类隐蔽问题。命令行为细节与常见实操要点重复执行即整体覆盖因为PutDashboard是“整份替换”语义重复对同一个--dashboard-name执行命令会丢弃旧 dashboard-body 中的全部内容。典型场景是 CI/CD 中以put-dashboard幂等部署仪表盘配置只要新 JSON 合法执行多次结果一致无需先删除。全局不分区注意 region 字段与请求区域的差异仪表盘本身是账户全局资源请求时所在区域不影响资源归属但 dashboard-body 中每个 metric widget 的properties.region决定了指标数据从哪里读取。跨区域监控时应在同一个仪表盘的不同 widget 中显式指定各自区域的region字段。更新前先备份结合 get-dashboard 使用仓库配套示例 get-dashboard.rst 展示了反向操作——查询已有仪表盘的完整定义aws cloudwatch get-dashboard \ --dashboard-name Dashboard-A其输出会返回DashboardArn、DashboardName以及完整的DashboardBody即 put 时使用的 JSON 结构。官方推荐的工作流正是先用get-dashboard取出DashboardBody作为模板修改后再用put-dashboard写回实现“复制仪表盘”或“安全改版”。例如可先执行aws cloudwatch get-dashboard --dashboard-name Dashboard-A --query DashboardBody --output json dashboard-backup.json留存备份再放心执行put-dashboard覆盖。附加参数 --tags仅创建时生效PutDashboardInput还支持可选参数Tags最多 50 个键值对用于组织、分类仪表盘并可结合 IAM 按标签做权限范围控制。需要注意服务模型中的两个限制Tags参数仅在创建新仪表盘时生效若在更新已存在的仪表盘时传入Tags标签更新会被忽略对已有仪表盘增删标签应改用TagResource/UntagResource仓库中对应示例 tag-resource.rst、untag-resource.rst。对应 CLI 用法示例创建并打标签aws cloudwatch put-dashboard \ --dashboard-name Dashboard-A \ --dashboard-body {widgets:[...]} \ --tags KeyEnvironment,ValueProd KeyTeam,ValueOps从源码视角看参数传递与命令生成从 CLI 的实现机制看put-dashboard属于 AWS CLI 根据服务模型自动生成的命令不需要手写专用代码。仓库中 customizations/cloudwatch.py 对 cloudwatch 命令表所做的唯一自定义是为get-otel-enrichment、start-otel-enrichment、stop-otel-enrichment三个命令注册隐藏别名与仪表盘命令无关——这恰恰说明put-dashboard的参数解析、必填校验、JSON 序列化完全由PutDashboardInput模型service-2.json驱动CLI 据此自动生成--dashboard-name、--dashboard-body、--tags三个参数并对前两者做必填校验。因此dashboard-body的字段命名、坐标/尺寸/视图取值等规范全部以服务端接受的 JSON schema 为准CLI 本身只负责“原样传递”字符串。理解这一点有助于排查问题若返回错误消息多半是dashboard-bodyJSON 结构本身不合法而非 CLI 参数写错。仪表盘生命周期完整操作链路配合仓库中其他官方示例put-dashboard可以串起仪表盘完整生命周期创建/更新aws cloudwatch put-dashboard本文主题示例见 put-dashboard.rst查看/导出aws cloudwatch get-dashboard --dashboard-name Dashboard-A示例见 get-dashboard.rst用于备份与复制列出aws cloudwatch list-dashboards可配合--dashboard-name-prefix按前缀过滤示例见 list-dashboards.rst打标签创建时用--tags存量仪表盘用tag-resource/untag-resource删除aws cloudwatch delete-dashboards --dashboard-names Dashboard-A示例见 delete-dashboards.rst。小结put-dashboard以“整份 JSON 覆盖”的方式创建或更新仪表盘核心是掌握--dashboard-body的 widgets 结构type决定组件类型x/y/width/height决定布局properties决定数据来源与呈现方式返回的DashboardValidationMessages需区分空成功、警告可能渲染异常与错误失败三种情况仪表盘为账户级全局资源但 widget 内的region决定指标数据来源--tags仅在新建时生效存量标签管理请用tag-resource/untag-resource安全实践先用get-dashboard备份现有DashboardBody再执行覆盖式更新。相关参考文件put-dashboard.rst、get-dashboard.rst、service-2.json、cloudwatch.py。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表