教程文档DevOps【免费下载链接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.项目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero点击查看免费下载本篇文章以 30 Days AWS Zero to Hero 系列第 16 天Day 16的学习材料为核心系统讲解 AWS CloudWatch 的核心概念、五大优势、典型问题场景与实用案例并结合本仓库 day-16 目录下提供的两个可运行 Demo默认指标采集与自定义指标上报给出完整的实操步骤。读完本文你将掌握 CloudWatch 的指标Metrics、告警Alarms、日志洞察Logs Insights与仪表盘Dashboards的工作原理并能独立跑通模拟 CPU 峰值观察 EC2 默认指标和用 Flask 应用上报自定义业务指标两条完整链路。一、什么是 AWS CloudWatchAWS CloudWatch 是 Amazon Web Services 提供的一款功能强大的监控与可观测性Observability服务。它的核心职责是持续收集、追踪并可视化 AWS 资源与应用运行时的各类数据帮助工程师洞察系统性能、健康状态与运维情况。具体而言CloudWatch 主要承担三类工作收集与追踪指标Metrics采集 EC2 实例、RDS 数据库、Lambda 函数、DynamoDB 表等资源的运行指标收集与监控日志文件Logs汇聚各服务的日志流支持检索与分析设置告警Alarms基于预设阈值自动触发告警通知或联动其他 AWS 服务。在本仓库的课程体系中Day 16 属于监控与运维模块。此前 Day 3EC2、Day 4VPC、Day 9S3等章节搭建的各类资源都可以通过 CloudWatch 统一纳入监控视图而 Day 18 的 CloudWatch Events / EventBridge 则是在此基础上进一步演进的事件驱动能力可见 CloudWatch 是整个零基础到实战路线中承上启下的关键服务。二、AWS CloudWatch 的五大优势原文档总结了 CloudWatch 之所以成为 AWS 上默认监控方案的核心优势下面逐条展开并结合仓库实践说明其价值。1. 全面监控Comprehensive MonitoringCloudWatch 能够同时监控 EC2 实例、RDS 数据库、Lambda 函数等多种 AWS 资源提供整个 AWS 基础设施的统一视图。这意味着你不再需要为每类资源分别搭建监控系统而是可以在同一个控制台内纵览全局。结合本仓库实践Day 16 的 default_metrics_demo 目录就是围绕EC2 实例默认指标展开的演示你可以在 CloudWatch 控制台的 Metrics 页面中直接查看实例的 CPU 利用率、网络吞吐、磁盘读写等系统级指标无需任何额外配置——这正是全面监控的直接体现。2. 实时指标Real-Time MetricsCloudWatch 提供接近实时的指标采集能力让你能在问题或异常出现的当下立即感知并响应而不是等故障扩散后才后知后觉。在默认指标之外CloudWatch 还允许你上报自定义指标Custom Metrics其时效性同样可以做到秒级。仓库中的 cloudwatch_metrics.py 便演示了应用层业务指标页面访问量、接口响应时间的实时上报方式使监控粒度从基础设施层延伸到业务层。3. 自动化操作Automated Actions借助CloudWatch Alarms告警你可以基于条件触发自动化动作。最典型的场景是当 CPU 利用率或请求数超过阈值时自动触发 Auto Scaling 组的扩容Scale Out或缩容Scale In实现指标驱动的基础设施弹性。这也是本系列课程大纲中 Day 16 项目环节的核心目标——为关键指标设置 CloudWatch 告警、定义合理的阈值条件、并配置通知动作。告警的状态变化除了可以联动 Auto Scaling、SNS 通知还可以触发 Lambda 函数Day 17 的内容执行自定义修复逻辑。4. 日志洞察Log InsightsCloudWatch Logs Insights 允许你对来自多个 AWS 服务的日志数据进行查询与分析支持用类 SQL 的查询语法进行过滤、聚合与统计帮助快速定位故障根因并识别趋势。典型排查链路应用出现 5xx 错误 → 在 Logs Insights 中对应用日志执行查询 → 按错误码聚合统计 → 结合时间维度与指标曲线交叉比对 → 锁定问题窗口。相比手工翻日志这种检索方式在日志量巨大时效率提升显著。5. 仪表盘与可视化Dashboards and VisualizationCloudWatch 支持创建自定义仪表盘Custom Dashboards把应用指标与基础设施指标集中呈现在同一页面通过折线图、柱状图等可视化形式直观反映系统整体健康度。运维团队可以把生产环境的关键指标CPU、内存、延迟、错误率放到一张看板上形成团队的作战指挥屏。三、CloudWatch 帮助解决的核心问题CloudWatch 在实际运维中主要回答四类问题对应原文档总结的四大挑战问题领域CloudWatch 的解法典型场景资源利用Resource Utilization持续追踪资源利用率与性能指标发现 EC2 实例长期闲置浪费成本推动缩容或关闭主动监控Proactive Monitoring在问题影响业务前提前发现并处置CPU 突增触发告警Ops 在用户感知前介入故障排查Troubleshooting分析日志与指标快速定位根因结合错误日志与延迟曲线定位慢查询可扩展性Scalability依据需求自动扩缩容高峰期自动扩容低谷期自动缩容兼顾性能与成本这四个方向正是 DevOps 工程师日常工作的核心既要保证系统稳定监控与排查又要保证资源不浪费利用率与弹性。CloudWatch 将这两条主线统一到一套服务中这也是它成为 AWS 可观测性入口的根本原因。四、CloudWatch 的五大实际使用场景原文档给出了五个高频落地场景下面逐一结合仓库代码给出更具体的操作指引。1. 基于阈值的自动扩缩容Auto ScalingCloudWatch 通过Alarm监控 CPU 利用率、请求数等指标当指标超过设定的阈值并持续一段时间如连续 2 个数据点、5 分钟后告警进入In alarm状态触发 Auto Scaling 策略执行扩容或缩容。实践要点告警必须绑定一个可观测的指标Metric与命名空间Namespace阈值、持续周期Period、评估周期Evaluation Periods需要结合业务画像调优避免抖动扩容告警动作Actions可以同时配置多个例如扩容 发送 SNS 通知。2. 资源健康监控Resource Monitoring对 EC2 实例、RDS 数据库、DynamoDB 表等资源持续监控性能与健康。以仓库中的 cpu_spike.py 为例它模拟了一段 30 秒、80% 的 CPU 峰值正是用来在 CloudWatch 控制台观察EC2 默认指标如CPUUtilization变化的配套工具import time def simulate_cpu_spike(duration30, cpu_percent80): print(fSimulating CPU spike at {cpu_percent}%...) start_time time.time() # 计算实现目标 CPU 利用率所需的迭代次数 target_percent cpu_percent / 100 total_iterations int(target_percent * 5_000_000) # 按需调整数量 # 执行简单算术运算来抬升 CPU 利用率 for _ in range(total_iterations): result 0 for i in range(1, 1001): result i # 等待剩余时间使整体耗时对齐 duration elapsed_time time.time() - start_time remaining_time max(0, duration - elapsed_time) time.sleep(remaining_time) print(CPU spike simulation completed.) if __name__ __main__: # 模拟 30 秒、80% 的 CPU 峰值 simulate_cpu_spike(duration30, cpu_percent80)从代码实现可以看出它的设计思路通过大量整数累加运算内层 1~1000 循环主动消耗 CPU再用total_iterations target_percent * 5_000_000按目标利用率比例控制运算量最后用time.sleep(remaining_time)把整体时长补齐到设定的duration。这种目标百分比 × 基准迭代数的模型使脚本可以通过调整参数模拟不同强度、不同时长的负载非常适合在实验环境中演示 CloudWatch 指标告警的全过程。3. 应用洞察Application Insights跟踪应用层自定义指标识别性能瓶颈。仓库中的 cloudwatch_metrics.py 是一个完整的可运行示例一个模拟在线商店的 Flask 应用在每次请求中主动向 CloudWatch 上报两条业务指标from flask import Flask import time import random import boto3 app Flask(__name__) # 初始化 AWS CloudWatch 客户端 cloudwatch boto3.client(cloudwatch, region_nameus-east-1) # 模拟在线商店的商品数据 products { 1: {name: Product 1, price: 10.99}, 2: {name: Product 2, price: 19.99}, 3: {name: Product 3, price: 5.49} } app.route(/) def index(): start_time time.time() # 模拟处理耗时 time.sleep(random.uniform(0.1, 0.5)) # 上报页面访问量指标 log_metric(PageViews, 1) # 上报响应时间指标毫秒 response_time (time.time() - start_time) * 1000 log_metric(ResponseTime, response_time) return Welcome to our Online Store! app.route(/product/product_id) def product(product_id): start_time time.time() # 模拟处理耗时商品页更重耗时更长 time.sleep(random.uniform(0.2, 0.8)) log_metric(PageViews, 1) response_time (time.time() - start_time) * 1000 log_metric(ResponseTime, response_time) if product_id in products: return fProduct: {products[product_id][name]}, Price: ${products[product_id][price]} else: return Product not found. def log_metric(metric_name, value): # 向 CloudWatch 发送自定义指标 cloudwatch.put_metric_data( NamespaceOnlineStore, MetricData[{ MetricName: metric_name, Value: value, Unit: Count }] ) if __name__ __main__: app.run(host0.0.0.0, port5000)这段代码的核心在于log_metric()函数它封装了对boto3CloudWatch 客户端put_metric_dataAPI 的调用其中几个关键参数值得留意参数本示例取值说明NamespaceOnlineStore指标所属命名空间用于逻辑隔离类似于指标的分类桶不传时默认写入AWS/前缀空间MetricNamePageViews/ResponseTime指标名称在同一命名空间内唯一标识一类指标Value1或毫秒数本次数据点的值PageViews每次记 1计数ResponseTime记录接口实际耗时UnitCount数据单位CloudWatch 据此做正确的单位换算与展示从代码结构看该 Demo 还演示了自定义指标的两个典型设计手法一是事件计数PageViews每次 1可统计请求量、QPS 趋势二是性能采样ResponseTime每次上报毫秒耗时可观察 P95、均值等延迟分布。有了这两类指标再配合 CloudWatch 告警就能实现响应时间超过 500ms 即告警这类贴近业务的监控规则这正是应用洞察能力从理论落到实践的过程。4. 实时日志分析Log Analysis使用 CloudWatch Logs Insights 对日志数据执行实时查询识别模式、排查故障。典型操作流程在 CloudWatch 控制台进入Logs → Logs Insights选择一个或多个日志组Log Group编写查询语句例如筛选 5xx 状态码并按接口聚合统计保存查询为仪表盘小部件长期跟踪错误趋势。需要说明的是应用日志要能被 Logs Insights 检索前提是先将日志写入 CloudWatch Logs如通过 CloudWatch Agent、Lambda 内置日志收集或 ECS/EKS 的日志驱动这与 Day 16 之后Day 17 Lambda、Day 21 ECS的课程内容会形成联动。5. 账单与成本监控Billing and Cost MonitoringCloudWatch 可以监控 AWS 账单与用量模式辅助成本优化。要点先在账户的 Billing 设置中启用接收 CloudWatch 账单告警随后可基于AWS/Billing命名空间下的EstimatedCharges指标创建告警结合 Day 29成本优化最佳实践课程内容形成成本监控 → 优化 → 再监控的闭环。五、实战演练从零跑通 CloudWatch 两条 DemoDay 16 仓库提供了两个目录分别对应 CloudWatch 的两类指标来源默认指标系统自动采集与自定义指标应用主动上报。下面给出完整的运行与验证步骤。环境准备拥有 AWS 账户并配置好具备CloudWatch:PutMetricData权限的凭证推荐使用 IAM 用户或临时凭证本地安装 Python 3.x 与 pip安装依赖仅自定义指标 Demo 需要pip install -r day-16/custom_metrics_demo/requirements.txtrequirements.txt 内容只有两行flask与boto3前者用于启动 Web 应用后者用于调用 AWS API。演练一观察 EC2 默认指标配合 CPU 峰值脚本启动一台 EC2 实例可用 Day 3 课程学到的步骤创建将 cpu_spike.py 上传到实例并执行python3 cpu_spike.py脚本运行期间默认 30 秒打开 CloudWatch 控制台 →Metrics → All metrics → EC2 → Per-Instance Metrics选择CPUUtilization指标即可看到 CPU 利用率曲线明显抬升至约 80%脚本结束后曲线回落完成一次默认指标观测验证。演练二上报并查看自定义指标Flask boto3启动自定义指标 Demo 应用python3 day-16/custom_metrics_demo/cloudwatch_metrics.py应用监听0.0.0.0:5000源码中app.run(host0.0.0.0, port5000)指定访问以下地址制造流量curl http://localhost:5000/ curl http://localhost:5000/product/1 curl http://localhost:5000/product/999打开 CloudWatch 控制台 →Metrics → All metrics → Custom Namespaces → OnlineStore即可看到PageViews与ResponseTime两个指标及其数据点曲线反复刷新页面后切到Graphed metrics视图观察指标实时变化——PageViews随访问次数递增ResponseTime则在 100~800 毫秒区间波动对应源码中random.uniform(0.1, 0.5)与random.uniform(0.2, 0.8)的模拟耗时。演练三创建告警可选延伸在上述指标具备数据点后可以为OnlineStore/ResponseTime创建一个 CloudWatch Alarm指标OnlineStore命名空间下的ResponseTime条件平均值大于 500 毫秒周期1 分钟、连续 1~2 个评估周期动作触发时向 SNS 主题发送通知或联动 Lambda / Auto Scaling。一旦应用因流量压力导致响应时间超阈值告警即进入In alarm状态并执行配置的动作——这正是原文档所述自动化操作 主动监控能力的落地验证。六、小结CloudWatch 在 DevOps 体系中的定位回到本系列课程的主线Day 16 的 CloudWatch 是构建可观测、可告警、可自动响应运维体系的第一步Day 16 解决看得见通过默认指标 自定义指标 日志洞察让系统状态可量化Day 18 解决自动响应CloudWatch Events / EventBridge 将监控事件转化为自动化工作流Day 25 解决可审计CloudTrail 与 Config 补齐审计合规视角。三者共同构成了 AWS DevOps 实践中的监控 → 事件 → 审计闭环。建议在学习完本文后动手完成两个 Demo 的端到端运行观察默认指标曲线、查看自定义指标命名空间再尝试为自定义指标创建告警并绑定 SNS 通知即可完整复现本系列 Day 16 的项目目标——为关键指标设置告警、定义阈值并配置通知动作。赞分享教程文档DevOps【免费下载链接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.项目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero点击查看免费下载相关推荐如何从源码构建并运行 IntelliJ IDEAintellij-community 完整教程如何从源码构建并运行 IntelliJ IDEAintellij community 完整教程 intellij community 是 JetBrains开发工具IDE代码编辑器突破日志困境aws-devops-zero-to-hero项目的日志分析实战指南突破日志困境aws devops zero to hero项目的日志分析实战指南 你是否还在为AWS日志分析效率低下而困扰当系统故障发生时是否仍在多个服务教程文档DevOpsi-have-adhd在Windows、macOS、Linux的常驻Hook全解三平台差异一览i have adhd在Windows、macOS、Linux的常驻Hook全解三平台差异一览 i have adhd 是让编程 Agent 输出ADHDAI 技能人工智能AI 评测上一篇Carbon 语言设计全景从值与类型系统到泛型、命名组织与 C 互操作下一篇5分钟搞定SQL模板管理DBeaver代码片段分类与效率提升指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AWS CloudWatch 实战指南：基于 30 Days AWS Zero to Hero 系列 Day 16 的监控与指标采集实践
教程文档DevOps【免费下载链接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.项目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero点击查看免费下载本篇文章以 30 Days AWS Zero to Hero 系列第 16 天Day 16的学习材料为核心系统讲解 AWS CloudWatch 的核心概念、五大优势、典型问题场景与实用案例并结合本仓库 day-16 目录下提供的两个可运行 Demo默认指标采集与自定义指标上报给出完整的实操步骤。读完本文你将掌握 CloudWatch 的指标Metrics、告警Alarms、日志洞察Logs Insights与仪表盘Dashboards的工作原理并能独立跑通模拟 CPU 峰值观察 EC2 默认指标和用 Flask 应用上报自定义业务指标两条完整链路。一、什么是 AWS CloudWatchAWS CloudWatch 是 Amazon Web Services 提供的一款功能强大的监控与可观测性Observability服务。它的核心职责是持续收集、追踪并可视化 AWS 资源与应用运行时的各类数据帮助工程师洞察系统性能、健康状态与运维情况。具体而言CloudWatch 主要承担三类工作收集与追踪指标Metrics采集 EC2 实例、RDS 数据库、Lambda 函数、DynamoDB 表等资源的运行指标收集与监控日志文件Logs汇聚各服务的日志流支持检索与分析设置告警Alarms基于预设阈值自动触发告警通知或联动其他 AWS 服务。在本仓库的课程体系中Day 16 属于监控与运维模块。此前 Day 3EC2、Day 4VPC、Day 9S3等章节搭建的各类资源都可以通过 CloudWatch 统一纳入监控视图而 Day 18 的 CloudWatch Events / EventBridge 则是在此基础上进一步演进的事件驱动能力可见 CloudWatch 是整个零基础到实战路线中承上启下的关键服务。二、AWS CloudWatch 的五大优势原文档总结了 CloudWatch 之所以成为 AWS 上默认监控方案的核心优势下面逐条展开并结合仓库实践说明其价值。1. 全面监控Comprehensive MonitoringCloudWatch 能够同时监控 EC2 实例、RDS 数据库、Lambda 函数等多种 AWS 资源提供整个 AWS 基础设施的统一视图。这意味着你不再需要为每类资源分别搭建监控系统而是可以在同一个控制台内纵览全局。结合本仓库实践Day 16 的 default_metrics_demo 目录就是围绕EC2 实例默认指标展开的演示你可以在 CloudWatch 控制台的 Metrics 页面中直接查看实例的 CPU 利用率、网络吞吐、磁盘读写等系统级指标无需任何额外配置——这正是全面监控的直接体现。2. 实时指标Real-Time MetricsCloudWatch 提供接近实时的指标采集能力让你能在问题或异常出现的当下立即感知并响应而不是等故障扩散后才后知后觉。在默认指标之外CloudWatch 还允许你上报自定义指标Custom Metrics其时效性同样可以做到秒级。仓库中的 cloudwatch_metrics.py 便演示了应用层业务指标页面访问量、接口响应时间的实时上报方式使监控粒度从基础设施层延伸到业务层。3. 自动化操作Automated Actions借助CloudWatch Alarms告警你可以基于条件触发自动化动作。最典型的场景是当 CPU 利用率或请求数超过阈值时自动触发 Auto Scaling 组的扩容Scale Out或缩容Scale In实现指标驱动的基础设施弹性。这也是本系列课程大纲中 Day 16 项目环节的核心目标——为关键指标设置 CloudWatch 告警、定义合理的阈值条件、并配置通知动作。告警的状态变化除了可以联动 Auto Scaling、SNS 通知还可以触发 Lambda 函数Day 17 的内容执行自定义修复逻辑。4. 日志洞察Log InsightsCloudWatch Logs Insights 允许你对来自多个 AWS 服务的日志数据进行查询与分析支持用类 SQL 的查询语法进行过滤、聚合与统计帮助快速定位故障根因并识别趋势。典型排查链路应用出现 5xx 错误 → 在 Logs Insights 中对应用日志执行查询 → 按错误码聚合统计 → 结合时间维度与指标曲线交叉比对 → 锁定问题窗口。相比手工翻日志这种检索方式在日志量巨大时效率提升显著。5. 仪表盘与可视化Dashboards and VisualizationCloudWatch 支持创建自定义仪表盘Custom Dashboards把应用指标与基础设施指标集中呈现在同一页面通过折线图、柱状图等可视化形式直观反映系统整体健康度。运维团队可以把生产环境的关键指标CPU、内存、延迟、错误率放到一张看板上形成团队的作战指挥屏。三、CloudWatch 帮助解决的核心问题CloudWatch 在实际运维中主要回答四类问题对应原文档总结的四大挑战问题领域CloudWatch 的解法典型场景资源利用Resource Utilization持续追踪资源利用率与性能指标发现 EC2 实例长期闲置浪费成本推动缩容或关闭主动监控Proactive Monitoring在问题影响业务前提前发现并处置CPU 突增触发告警Ops 在用户感知前介入故障排查Troubleshooting分析日志与指标快速定位根因结合错误日志与延迟曲线定位慢查询可扩展性Scalability依据需求自动扩缩容高峰期自动扩容低谷期自动缩容兼顾性能与成本这四个方向正是 DevOps 工程师日常工作的核心既要保证系统稳定监控与排查又要保证资源不浪费利用率与弹性。CloudWatch 将这两条主线统一到一套服务中这也是它成为 AWS 可观测性入口的根本原因。四、CloudWatch 的五大实际使用场景原文档给出了五个高频落地场景下面逐一结合仓库代码给出更具体的操作指引。1. 基于阈值的自动扩缩容Auto ScalingCloudWatch 通过Alarm监控 CPU 利用率、请求数等指标当指标超过设定的阈值并持续一段时间如连续 2 个数据点、5 分钟后告警进入In alarm状态触发 Auto Scaling 策略执行扩容或缩容。实践要点告警必须绑定一个可观测的指标Metric与命名空间Namespace阈值、持续周期Period、评估周期Evaluation Periods需要结合业务画像调优避免抖动扩容告警动作Actions可以同时配置多个例如扩容 发送 SNS 通知。2. 资源健康监控Resource Monitoring对 EC2 实例、RDS 数据库、DynamoDB 表等资源持续监控性能与健康。以仓库中的 cpu_spike.py 为例它模拟了一段 30 秒、80% 的 CPU 峰值正是用来在 CloudWatch 控制台观察EC2 默认指标如CPUUtilization变化的配套工具import time def simulate_cpu_spike(duration30, cpu_percent80): print(fSimulating CPU spike at {cpu_percent}%...) start_time time.time() # 计算实现目标 CPU 利用率所需的迭代次数 target_percent cpu_percent / 100 total_iterations int(target_percent * 5_000_000) # 按需调整数量 # 执行简单算术运算来抬升 CPU 利用率 for _ in range(total_iterations): result 0 for i in range(1, 1001): result i # 等待剩余时间使整体耗时对齐 duration elapsed_time time.time() - start_time remaining_time max(0, duration - elapsed_time) time.sleep(remaining_time) print(CPU spike simulation completed.) if __name__ __main__: # 模拟 30 秒、80% 的 CPU 峰值 simulate_cpu_spike(duration30, cpu_percent80)从代码实现可以看出它的设计思路通过大量整数累加运算内层 1~1000 循环主动消耗 CPU再用total_iterations target_percent * 5_000_000按目标利用率比例控制运算量最后用time.sleep(remaining_time)把整体时长补齐到设定的duration。这种目标百分比 × 基准迭代数的模型使脚本可以通过调整参数模拟不同强度、不同时长的负载非常适合在实验环境中演示 CloudWatch 指标告警的全过程。3. 应用洞察Application Insights跟踪应用层自定义指标识别性能瓶颈。仓库中的 cloudwatch_metrics.py 是一个完整的可运行示例一个模拟在线商店的 Flask 应用在每次请求中主动向 CloudWatch 上报两条业务指标from flask import Flask import time import random import boto3 app Flask(__name__) # 初始化 AWS CloudWatch 客户端 cloudwatch boto3.client(cloudwatch, region_nameus-east-1) # 模拟在线商店的商品数据 products { 1: {name: Product 1, price: 10.99}, 2: {name: Product 2, price: 19.99}, 3: {name: Product 3, price: 5.49} } app.route(/) def index(): start_time time.time() # 模拟处理耗时 time.sleep(random.uniform(0.1, 0.5)) # 上报页面访问量指标 log_metric(PageViews, 1) # 上报响应时间指标毫秒 response_time (time.time() - start_time) * 1000 log_metric(ResponseTime, response_time) return Welcome to our Online Store! app.route(/product/product_id) def product(product_id): start_time time.time() # 模拟处理耗时商品页更重耗时更长 time.sleep(random.uniform(0.2, 0.8)) log_metric(PageViews, 1) response_time (time.time() - start_time) * 1000 log_metric(ResponseTime, response_time) if product_id in products: return fProduct: {products[product_id][name]}, Price: ${products[product_id][price]} else: return Product not found. def log_metric(metric_name, value): # 向 CloudWatch 发送自定义指标 cloudwatch.put_metric_data( NamespaceOnlineStore, MetricData[{ MetricName: metric_name, Value: value, Unit: Count }] ) if __name__ __main__: app.run(host0.0.0.0, port5000)这段代码的核心在于log_metric()函数它封装了对boto3CloudWatch 客户端put_metric_dataAPI 的调用其中几个关键参数值得留意参数本示例取值说明NamespaceOnlineStore指标所属命名空间用于逻辑隔离类似于指标的分类桶不传时默认写入AWS/前缀空间MetricNamePageViews/ResponseTime指标名称在同一命名空间内唯一标识一类指标Value1或毫秒数本次数据点的值PageViews每次记 1计数ResponseTime记录接口实际耗时UnitCount数据单位CloudWatch 据此做正确的单位换算与展示从代码结构看该 Demo 还演示了自定义指标的两个典型设计手法一是事件计数PageViews每次 1可统计请求量、QPS 趋势二是性能采样ResponseTime每次上报毫秒耗时可观察 P95、均值等延迟分布。有了这两类指标再配合 CloudWatch 告警就能实现响应时间超过 500ms 即告警这类贴近业务的监控规则这正是应用洞察能力从理论落到实践的过程。4. 实时日志分析Log Analysis使用 CloudWatch Logs Insights 对日志数据执行实时查询识别模式、排查故障。典型操作流程在 CloudWatch 控制台进入Logs → Logs Insights选择一个或多个日志组Log Group编写查询语句例如筛选 5xx 状态码并按接口聚合统计保存查询为仪表盘小部件长期跟踪错误趋势。需要说明的是应用日志要能被 Logs Insights 检索前提是先将日志写入 CloudWatch Logs如通过 CloudWatch Agent、Lambda 内置日志收集或 ECS/EKS 的日志驱动这与 Day 16 之后Day 17 Lambda、Day 21 ECS的课程内容会形成联动。5. 账单与成本监控Billing and Cost MonitoringCloudWatch 可以监控 AWS 账单与用量模式辅助成本优化。要点先在账户的 Billing 设置中启用接收 CloudWatch 账单告警随后可基于AWS/Billing命名空间下的EstimatedCharges指标创建告警结合 Day 29成本优化最佳实践课程内容形成成本监控 → 优化 → 再监控的闭环。五、实战演练从零跑通 CloudWatch 两条 DemoDay 16 仓库提供了两个目录分别对应 CloudWatch 的两类指标来源默认指标系统自动采集与自定义指标应用主动上报。下面给出完整的运行与验证步骤。环境准备拥有 AWS 账户并配置好具备CloudWatch:PutMetricData权限的凭证推荐使用 IAM 用户或临时凭证本地安装 Python 3.x 与 pip安装依赖仅自定义指标 Demo 需要pip install -r day-16/custom_metrics_demo/requirements.txtrequirements.txt 内容只有两行flask与boto3前者用于启动 Web 应用后者用于调用 AWS API。演练一观察 EC2 默认指标配合 CPU 峰值脚本启动一台 EC2 实例可用 Day 3 课程学到的步骤创建将 cpu_spike.py 上传到实例并执行python3 cpu_spike.py脚本运行期间默认 30 秒打开 CloudWatch 控制台 →Metrics → All metrics → EC2 → Per-Instance Metrics选择CPUUtilization指标即可看到 CPU 利用率曲线明显抬升至约 80%脚本结束后曲线回落完成一次默认指标观测验证。演练二上报并查看自定义指标Flask boto3启动自定义指标 Demo 应用python3 day-16/custom_metrics_demo/cloudwatch_metrics.py应用监听0.0.0.0:5000源码中app.run(host0.0.0.0, port5000)指定访问以下地址制造流量curl http://localhost:5000/ curl http://localhost:5000/product/1 curl http://localhost:5000/product/999打开 CloudWatch 控制台 →Metrics → All metrics → Custom Namespaces → OnlineStore即可看到PageViews与ResponseTime两个指标及其数据点曲线反复刷新页面后切到Graphed metrics视图观察指标实时变化——PageViews随访问次数递增ResponseTime则在 100~800 毫秒区间波动对应源码中random.uniform(0.1, 0.5)与random.uniform(0.2, 0.8)的模拟耗时。演练三创建告警可选延伸在上述指标具备数据点后可以为OnlineStore/ResponseTime创建一个 CloudWatch Alarm指标OnlineStore命名空间下的ResponseTime条件平均值大于 500 毫秒周期1 分钟、连续 1~2 个评估周期动作触发时向 SNS 主题发送通知或联动 Lambda / Auto Scaling。一旦应用因流量压力导致响应时间超阈值告警即进入In alarm状态并执行配置的动作——这正是原文档所述自动化操作 主动监控能力的落地验证。六、小结CloudWatch 在 DevOps 体系中的定位回到本系列课程的主线Day 16 的 CloudWatch 是构建可观测、可告警、可自动响应运维体系的第一步Day 16 解决看得见通过默认指标 自定义指标 日志洞察让系统状态可量化Day 18 解决自动响应CloudWatch Events / EventBridge 将监控事件转化为自动化工作流Day 25 解决可审计CloudTrail 与 Config 补齐审计合规视角。三者共同构成了 AWS DevOps 实践中的监控 → 事件 → 审计闭环。建议在学习完本文后动手完成两个 Demo 的端到端运行观察默认指标曲线、查看自定义指标命名空间再尝试为自定义指标创建告警并绑定 SNS 通知即可完整复现本系列 Day 16 的项目目标——为关键指标设置告警、定义阈值并配置通知动作。赞分享教程文档DevOps【免费下载链接】aws-devops-zero-to-heroAWS zero to hero repo for devops engineers to learn AWS in 30 Days. This repo includes projects, presentations, interview questions and real time examples.项目地址https://gitcode.com/GitHub_Trending/aw/aws-devops-zero-to-hero点击查看免费下载相关推荐如何从源码构建并运行 IntelliJ IDEAintellij-community 完整教程如何从源码构建并运行 IntelliJ IDEAintellij community 完整教程 intellij community 是 JetBrains开发工具IDE代码编辑器突破日志困境aws-devops-zero-to-hero项目的日志分析实战指南突破日志困境aws devops zero to hero项目的日志分析实战指南 你是否还在为AWS日志分析效率低下而困扰当系统故障发生时是否仍在多个服务教程文档DevOpsi-have-adhd在Windows、macOS、Linux的常驻Hook全解三平台差异一览i have adhd在Windows、macOS、Linux的常驻Hook全解三平台差异一览 i have adhd 是让编程 Agent 输出ADHDAI 技能人工智能AI 评测上一篇Carbon 语言设计全景从值与类型系统到泛型、命名组织与 C 互操作下一篇5分钟搞定SQL模板管理DBeaver代码片段分类与效率提升指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考