发现网站错误并确认恢复

介绍

错误发布可能使仍在运行的服务器无法提供网站。设置告警，发布提供好的错误简介，观察实际失败，再恢复正确简介并确认页面和告警恢复。

请先完成请求日志实验。本节独立提供网站、私有图片、角色、日志与指标接入；告警、故障和修复由你完成。 每节使用独立的新环境，无需保留上一节的资源、文件或凭据。工具、连接和无关素材均已准备好。

认证考点

实验概览

配置网站错误告警

本步骤，你将为实际请求错误配置一个告警。

先打开作品站，确认正常。每个请求产生日志事件；预置接入代码发布 Errors 指标：失败请求为 1，成功请求为 0。

指标（metric）是随时间记录的数值，namespace 将指标分组，dimension 标识对应应用。本节指标为 LabEx/Portfolio 下的 Errors，维度为 Application=portfolio。告警（alarm）将近期数据与阈值比较，本身不会修复网站。

进入目录并加载标识：

cd /home/labex/project

source website.env
echo "$INSTANCE_ID"

查看准备好的配置：

cat website-alarm.json

MetricName: Errors 选择请求错误；Statistic: Sum 对周期内错误数求和；Period: 10 表示十秒周期；EvaluationPeriods: 1 表示一个周期足够；阈值 0 与 GreaterThanThreshold 表示存在错误即超限；TreatMissingData: missing 不把无请求数据当作健康流量。

十秒告警需要高分辨率自定义指标，接入代码以一秒分辨率发布。本节不配置通知目标，只学习观察，不涉及邮件投递。

使用配置文件创建告警：

aws cloudwatch put-metric-alarm --cli-input-json file://website-alarm.json

读取状态：

aws cloudwatch describe-alarms --alarm-names portfolio-errors

开始可能为 INSUFFICIENT_DATA，表示尚无足够的已评估数据。AWS View 显示同一告警。后续用真实请求提供失败和成功样本，不手动设置告警状态。

本节 Errors 指标只统计 /website 的页面请求；图片和其他文件请求在日志中分别记录。

观察一次错误发布

本步骤，你将发布有意准备的无效简介，将实际错误请求与告警关联。

查看故障素材：

cat profile-broken.json

profile-broken.json 不是有效 JSON，应用无法解析。使用学过的 SCP 方式发布到同一路径：

scp -F ssh_config profile-broken.json ubuntu@"$PUBLIC_IP":/home/ubuntu/portfolio/profile.json

刷新作品站，应显示 Website unavailable；AWS View 中实例仍为 running。服务器运行不保证应用成功处理请求。

查询失败日志：

aws logs filter-log-events --log-group-name "$LOG_GROUP" --filter-pattern '"status=503"'

找到 path=/website status=503。HTTP 503 表示应用未能成功处理请求。本节刚发布了无效简介，日志证明实际失败，再结合最近修改定位原因。

等待一个十秒评估周期完成，必要时再次刷新失败页面，保持错误数据为近期样本。读取告警：

aws cloudwatch describe-alarms --alarm-names portfolio-errors

确认 StateValue: ALARM，AWS View 也应显示该状态。如果仍为 INSUFFICIENT_DATA，再产生真实请求并等待评估后查询；历史日志不等于当前指标样本。

恢复网站并确认正常

本步骤，你将恢复有效简介，同时确认页面与告警恢复。

查看已知有效的文件：

cat profile-working.json

它包含格式正确的三个字段，发布到同一路径：

scp -F ssh_config profile-working.json ubuntu@"$PUBLIC_IP":/home/ubuntu/portfolio/profile.json

刷新网站，应重新显示 Alex Morgan 和 S3 作品图片，证明应用层的修复成功。

查找成功页面日志：

aws logs filter-log-events --log-group-name "$LOG_GROUP" --filter-pattern '"status=200"'

确认失败之后出现近期 path=/website status=200。原有 503 事件仍在历史中，恢复不会抹去它。

给正常请求一个新的评估周期，必要时继续刷新健康页面，再查询：

aws cloudwatch describe-alarms --alarm-names portfolio-errors

确认 StateValue: OK。它表示当前已评估请求未超过阈值。没有请求时，missing 设置可能使状态回到 INSUFFICIENT_DATA，与已证明的健康流量不同；确认恢复期间保持成功请求为近期样本。

你完成了发布导致失败、日志确认响应、指标触发告警、修复文件恢复成功请求的完整操作过程。

移除实验工作负载和告警

本步骤，你将在确认恢复后清理实例、告警与本节日志组。

终止服务器并等待完成：

aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"

aws ec2 wait instance-terminated --instance-ids "$INSTANCE_ID"

仅删除自己创建的告警：

aws cloudwatch delete-alarms --alarm-names portfolio-errors

删除本节请求日志组：

aws logs delete-log-group --log-group-name "$LOG_GROUP"

AWS View 应显示 terminated，不再保留实验告警。保留预置 S3、角色、参考日志和网络。删除告警不会删除指标；工作负载移除后，本节不再产生新的请求样本。

你已完成八个引导实验。接下来通过 AWS Resource Management for Beginners 系统学习资源标识、精确查询和标签组织。

总结

你根据真实请求错误配置告警，发布已知错误简介，观察 HTTP 失败、日志和 ALARM。恢复有效简介后，成功请求使告警回到 OK。你区分缺少数据与健康流量，并清理本节工作负载和监控资源。

官方参考：CloudWatch 告警、高分辨率自定义指标。