21、应用监控与自动伸缩：CloudWatch与OpsWorks实战指南

应用监控与自动伸缩：CloudWatch与OpsWorks实战指南

1. 创建CloudWatch警报

在为警报创建了SNS主题后，就可以开始创建第一个CloudWatch警报了。这里以CloudFront的指标为例来创建警报，因为所有通过Web对应用程序的请求都会经过CloudFront分发。

操作步骤如下：
1. 使用服务菜单返回CloudWatch仪表板。
2. 查看左侧导航栏，在“Metrics”标题下，点击“CloudFront”，主视图将显示CloudFront分发的指标。

部分指标非常有用，例如：
| 指标 | 含义 |
| ---- | ---- |
| 4xxErrorRate | 跟踪响应状态码为400 - 499的HTTP请求百分比，通常与404（资源未找到）错误相关。少量404响应可能是用户输入错误URL或客户端请求格式不正确导致的，但如果4xx错误占比过大，就值得调查。一般认为，4xx错误率达到25%可视为一个事件。 |
| 5xxErrorRate | 代表内部服务器错误。用户不应能引发500错误，所以对500错误码的容忍阈值应远低于400错误。若为该指标创建警报，错误率大于0%时就可触发。 |
| TotalErrorRate | 接收非200 HTTP响应的请求百分比，是前两个指标的综合百分比。 |
| Requests | 统计对CloudFront分发的原始请求数量，理论上可用于识别分布式拒绝服务攻击或跟踪流量激增，但不是检测非恶意流量激增的最佳方式，因为不同请求对系统的影响不同，且很多到达CloudFront的请求（如图像请求）可能不会影响应用程序性能。 |

接下来创建一个简单的警报，当4XX错误率大于25%时触发：
1. 选择分发的“4xxErrorRate”行，下方将显示图形视图，点击右下角的“Create Alarm”按钮开始创建警报。

2. 定义警报

进入警报创建的第二步，已选择好警报指标。此视图有三个标题：“Alarm Threshold”、“Alarm Preview”和“Actions”。
- Alarm Threshold ：
- 在“Name”字段输入“Photoalbums CloudFront HTTP400 > 25%”，该名称将显示在电子邮件通知中，应具有描述性。
- 在“Description”字段输入更详细的描述，如“对Photoalbums CloudFront分发的请求平均百分比已超过25%”。
- “Whenever”字段已设置为所选指标，在“is:”行将比较运算符设置为“>”，并在相邻字段输入“25”。
- Alarm Preview ：显示当前警报状态，若现在启用警报，从图中可看出，当红线被跨越时警报将触发。目前可能因无请求而处于“INSUFFICIENT_DATA”状态。在该列底部设置“Period”为“5 Minutes”，即指标与警报阈值进行评估的频率；“Statistic”选择“Average”。
- Actions ：表示警报触发时CloudWatch的自动响应。可选择添加“Notification”或“AutoScaling Action”，由于使用OpsWorks管理实例，这里选择添加通知。点击“+Notification”，设置“Whenever this alarm:”为“State is ALARM”，“Send notification to:”为“PhotoalbumsAlarms”。

还可创建警报处于“OK”状态时的通知，再次点击“+Notification”，设置“Whenever this alarm:”为“State is OK”，然后点击“Create Alarm”。创建成功后，页面顶部会显示成功消息，左侧导航栏的“Alarms”标题会显示当前警报状态，新创建的警报初始状态为“INSUFFICIENT_DATA”，稍后会变为“OK”。

如果想触发警报，可向不存在的路径（如http://www.[yourdomain].com/helloworld）发送一些请求，几分钟后会收到警报处于“ALARM”状态的电子邮件。当收到警报信息后，首先应检查CloudFront，导航到CloudFront仪表板，点击“Popular Objects”查看对CloudFront分发的热门URL请求报告。例如，发现最热门的对象是缺失的“/robots.txt”文件，搜索引擎在查找该文件时收到404响应，可通过在Express应用中添加指向“robots.txt”文件的静态路径来解决此问题。

mermaid流程图如下：

graph TD;
    A[返回CloudWatch仪表板] --> B[点击CloudFront];
    B --> C[选择4xxErrorRate指标];
    C --> D[点击Create Alarm];
    D --> E[设置Alarm Threshold];
    E --> F[设置Alarm Preview];
    F --> G[设置Actions];
    G --> H[创建OK状态通知];
    H --> I[点击Create Alarm];
    I --> J[检查警报状态];
    J --> K[触发警报测试];
    K --> L[检查CloudFront问题];

3. 使用OpsWorks与CloudWatch

添加到OpsWorks应用层的实例有三种类型：24/7、基于负载和基于时间的实例。目前有一个24/7实例在运行，接下来添加一些基于负载的实例，以让应用程序更高效地处理增加的需求。

操作步骤如下：
1. 前往OpsWorks，选择应用程序堆栈。
2. 打开导航下拉菜单，在“Instances”标题下点击“Load-based instances”，进入基于负载实例的空白视图。
3. 点击“Add a load-based instance”，默认主机名即可，为节省成本，将实例大小更改为“t1.micro”，并选择不同的可用区（如“us-east-1b”）。
4. 点击“Advanced”查看其他设置，由于从“Load-based Instances”视图创建实例，负载均衡缩放类型已预先选择，无需更改这些值。点击“Add Instance”继续。

4. OpsWorks自动伸缩规则

返回实例视图时，会看到黄色警告框提示“Load-based auto scaling is disabled—edit”。这是因为虽然创建了基于负载的实例，但尚未启用负载均衡缩放，也未定义实例上线的规则。点击“Edit”按钮进行设置：
1. 将“Load-based auto scaling enabled”开关切换为“Yes”。
2. 定义自动伸缩规则，这些值对于应用程序而言基本上是任意的，应根据测试和操作历史确定自己的缩放阈值。这里给出一个简单的规则集示例：
- 缩放规则差异 ：
- 使用OpsWorks自动伸缩时，与CloudWatch缩放有一些不同。在OpsWorks中设置自动伸缩规则时，分别为向上和向下缩放定义规则，每次缩放操作设置要添加/删除的实例数量。缩放操作基于每个间隔对最多三个指标（平均CPU使用率、平均内存使用率或平均负载）的评估，不一定要在缩放规则中使用所有三个指标，若使用所有三个指标，任何一个指标超过定义的阈值时都会触发缩放操作。
- 在CloudWatch警报中，为指标设置周期和连续周期数来触发警报；而在OpsWorks中，设置一个单一的缩放时间框架，即“阈值超出时间”，当一个或多个阈值超出该时间时，应用缩放规则。触发缩放操作后，会有一个“忽略指标间隔”，让新实例有时间减轻堆栈中现有实例的工作负载。
- 自动伸缩场景示例 ：
- 场景1 ：
1. 一个24/7实例在线。
2. 平均CPU利用率达到51%并保持五分钟。
3. 向上规则的阈值超出时间满足。
4. 启动一个基于负载的实例。
5. 忽略指标五分钟。
6. 再次检查指标，平均CPU利用率降至23%。
7. 十分钟过去。
8. 平均CPU利用率仍低于30%。
9. 向下规则的阈值超出时间满足。
10. 停止基于负载的实例。基于负载的实例运行时间为15分钟。
- 场景2 ：
1. 一个24/7实例在线。
2. 平均CPU利用率达到75%并保持五分钟。
3. 向上规则的阈值超出时间满足。
4. 启动一个基于负载的实例。
5. 忽略指标五分钟。
6. 恢复指标检查，平均CPU利用率为63%并保持五分钟。
7. 没有额外的基于负载的实例可用。
8. 平均CPU利用率保持在63%又过了五分钟。
9. 仍没有额外的基于负载的实例可用。基于负载的实例运行时间不确定。

可以看到，现有资源可能无法满足应用程序的需求，可通过添加额外的24/7实例或基于负载的实例来解决。若认为是临时需求激增，添加额外的基于负载的实例更具成本效益。点击“Save”创建缩放规则，规则将不可编辑，然后点击表格下方的“+ Instance”按钮，选择“t1.micro”实例大小和不同的可用区（如“us-east-1c”），点击“Add Instance”创建第二个基于负载的实例。

mermaid流程图如下：

graph TD;
    A[前往OpsWorks选择堆栈] --> B[点击Load-based instances];
    B --> C[点击Add a load-based instance];
    C --> D[设置实例参数];
    D --> E[点击Advanced];
    E --> F[点击Add Instance];
    F --> G[收到警告点击Edit];
    G --> H[启用负载均衡缩放];
    H --> I[定义自动伸缩规则];
    I --> J[保存规则];
    J --> K[添加第二个基于负载实例];

应用监控与自动伸缩：CloudWatch与OpsWorks实战指南

5. 自动伸缩规则的深入分析与优化

在前面的内容中，我们已经了解了如何创建基于负载的实例以及设置OpsWorks自动伸缩规则。接下来，我们深入分析这些规则，并探讨如何进行优化。

5.1 规则参数的影响

自动伸缩规则中的参数设置对应用程序的性能和成本有着重要影响。例如，阈值超出时间和忽略指标间隔的设置需要平衡响应速度和资源利用率。

• 阈值超出时间 ：设置过短可能导致频繁的伸缩操作，增加系统开销；设置过长则可能无法及时响应流量变化，影响用户体验。在前面的场景示例中，我们将阈值超出时间设置为5分钟，这是一个相对合理的初始值，但具体还需根据应用程序的特性进行调整。
• 忽略指标间隔 ：该间隔为新实例提供了减轻现有实例工作负载的时间。如果设置过短，新实例可能还未完全发挥作用就再次进行伸缩操作；设置过长则可能导致资源在一段时间内处于闲置状态。

5.2 多指标的综合运用

在OpsWorks自动伸缩规则中，可以使用平均CPU使用率、平均内存使用率或平均负载这三个指标。合理运用这些指标可以更准确地反映应用程序的负载情况。

例如，一个应用程序可能在CPU使用率较低时，由于内存占用过高而出现性能问题。此时，仅根据CPU使用率进行伸缩可能无法解决问题。因此，在设置规则时，可以同时考虑多个指标，当任何一个指标超过阈值时触发伸缩操作。

指标	作用	适用场景
平均CPU使用率	反映CPU的负载情况	对于CPU密集型应用，如数据处理、科学计算等
平均内存使用率	体现内存的占用情况	对于内存敏感型应用，如数据库、缓存服务等
平均负载	综合考虑系统的整体负载	适用于各种类型的应用，作为一个整体的参考指标

6. 基于时间的实例伸缩

除了基于负载的实例伸缩，OpsWorks还支持基于时间的实例伸缩。这种方式适用于具有可预测流量模式的应用程序，例如电商网站在促销活动期间、新闻网站在特定时间段的流量高峰等。

6.1 设置基于时间的伸缩规则

操作步骤如下：
1. 前往OpsWorks，选择应用程序堆栈。
2. 打开导航下拉菜单，在“Instances”标题下找到基于时间的实例设置选项（具体名称可能因界面更新而有所不同）。
3. 定义伸缩规则，包括实例启动和停止的时间。可以按天、周或月设置不同的时间模式。例如，设置在每天晚上10点到早上6点减少实例数量，以节省成本。

6.2 时间伸缩与负载伸缩的结合

在实际应用中，可以将基于时间的伸缩和基于负载的伸缩结合使用，以达到更好的资源管理效果。例如，在可预测的流量高峰期间，先根据时间规则增加一定数量的实例，然后再根据负载情况进行微调。

mermaid流程图如下：

graph TD;
    A[前往OpsWorks选择堆栈] --> B[找到时间伸缩设置];
    B --> C[定义伸缩时间规则];
    C --> D[结合负载伸缩规则];
    D --> E[实现资源优化管理];

7. 监控与调整的持续过程

应用程序的流量和负载情况是不断变化的，因此监控和调整自动伸缩规则是一个持续的过程。

7.1 监控指标

通过CloudWatch和OpsWorks提供的监控工具，定期查看应用程序的各项指标，如CPU使用率、内存使用率、请求数量等。可以设置自定义的监控图表，以便更直观地观察指标的变化趋势。

7.2 规则调整

根据监控结果，及时调整自动伸缩规则。例如，如果发现某个时间段的流量总是超过预期，可以适当增加该时间段的实例数量或调整阈值参数。同时，记录每次调整的结果，以便总结经验，不断优化规则。

总结

通过CloudWatch和OpsWorks的结合使用，我们可以实现对应用程序的有效监控和自动伸缩。创建CloudWatch警报可以及时发现应用程序中的问题，OpsWorks的自动伸缩规则则可以根据负载情况自动调整资源，提高应用程序的性能和可用性，同时降低成本。

在实际应用中，需要根据应用程序的特性和流量模式，合理设置警报和伸缩规则，并不断进行监控和调整。通过多指标的综合运用、阈值参数的优化以及时间伸缩和负载伸缩的结合，可以实现资源的高效利用和应用程序的稳定运行。

希望本文的内容能帮助你更好地掌握应用监控与自动伸缩的技术，让你的应用程序在不同的负载情况下都能保持良好的性能。

最后，再次强调，自动伸缩规则的设置没有一成不变的标准，需要根据实际情况进行不断的尝试和优化。祝你在应用监控和自动伸缩的实践中取得成功！