超级会员免费看
构建AWS应用与基础设施的监控和告警体系
在当今的数字化时代，对应用程序和基础设施进行有效的监控和告警至关重要。AWS提供了一系列强大的服务，如CloudWatch、ElasticSearch和SNS等，帮助我们实现这一目标。本文将详细介绍如何利用这些服务为我们的应用和基础设施添加监控和告警功能。
1. 订阅确认与高级通知服务集成
首次订阅时，你会收到一条SMS短信来确认订阅。如果仅使用SNS发送重要问题的SMS通知，这是一个最小可行的解决方案。若你希望使用功能更丰富的服务，如PagerDuty、Opsgenie或Victorops等，只需在最后一个命令中更改订阅类型。将原本使用的SMS改为HTTPS协议，并提供服务提供商的webhook URL即可。
2. 应用中高错误率告警的创建
我们以一个简单的helloworld应用为例，所有用户流量都通过一个ELB实例。由于使用HTTP进行通信，我们可以轻松识别异常情况。在负载均衡器实例的监控选项卡（http://amzn.to/2rsEaLY）中，有一些关键指标值得关注，如延迟增加或HTTP 5XX错误增多，通常意味着需要对服务进行更深入的检查。
我们将在模板中加入对这两个指标的监控。具体操作步骤如下：
1. 重新打开troposphere脚本
helloworld-ecs-alb-cf-template.py
。
2. 添加新的导入：
from troposphere.cloudwatch import (
Alarm,
MetricDimension,
)
-
在文件底部已创建的
CPUTooLow和CPUTooHigh告警之后，添加新的告警资源：
t.add_resource(Alarm(
"ELBHTTP5xxs",
AlarmDescription="Alarm if HTTP 5xxs too high",
Namespace="AWS/ELB",
MetricName="HTTPCode_Backend_5XX",
Dimensions=[
MetricDimension(
Name="LoadBalancerName",
Value=Ref("LoadBalancer")
),
],
Statistic="Average",
Period="60",
EvaluationPeriods="3",
Threshold="30",
ComparisonOperator="GreaterThanOrEqualToThreshold",
AlarmActions=["arn:aws:sns:us-east-1:511912822958:alert-sms"],
OKActions=["arn:aws:sns:us-east-1:511912822958:alert-sms"],
InsufficientDataActions=[],
))
- 接着创建针对延迟的告警：
t.add_resource(Alarm(
"ELBHLatency",
AlarmDescription="Alarm if Latency too high",
Namespace="AWS/ELB",
MetricName="Latency",
Dimensions=[
MetricDimension(
Name="LoadBalancerName",
Value=Ref("LoadBalancer")
),
],
Statistic="Average",
Period="60",
EvaluationPeriods="5",
Threshold="0.5",
ComparisonOperator="GreaterThanOrEqualToThreshold",
AlarmActions=["arn:aws:sns:us-east-1:511912822958:alert-sms"],
OKActions=["arn:aws:sns:us-east-1:511912822958:alert-sms"],
InsufficientDataActions=[],
))
完成告警创建后，你可以提交更改，生成新的CloudFormation模板并部署：
$ git add helloworld-ecs-alb-cf-template.py
$ git commit -m "Creating SNS alarms"
$ git push
$ python helloworld-ecs-alb-cf-template.py > helloworld-ecs-alb-cf.template
$ aws cloudformation update-stack \
--stack-name staging-alb \
--template-body file://helloworld-ecs-alb-cf.template
$ aws cloudformation update-stack \
--stack-name production-alb \
--template-body file://helloworld-ecs-alb-cf.template
3. 无责事后分析
当故障发生时，创建事后分析文档是构建学习机制的最佳方法之一。这些文档应描述事件、时间线、根本原因以及解决方法。DevOps运动的“创始人”之一John Allspaw提出了无责事后分析的概念，强调学习而非指责。
4. 使用CloudWatch事件和Lambda创建自定义指标告警
虽然尽量将监控信息与被监控资源放在一起是良好的实践，但对于一些动态资源，如EC2实例，在troposphere代码中添加告警可能会很复杂。我们可以利用CloudWatch事件和Lambda来解决这个问题。
具体步骤如下：
1. 使用Serverless框架创建新的无服务器应用：
serverless create --template aws-python \
--name disk-free-monitoring \
--path disk-free-monitoring
$ cd disk-free-monitoring
-
编辑
serverless.yml文件：- 添加IAM权限：
provider:
name: aws
runtime: python2.7
iamRoleStatements:
- Effect: "Allow"
Action:
- "cloudwatch:PutMetricAlarm"
- "cloudwatch:DeleteAlarms"
Resource: "*"
- 修改函数名称：
functions:
alarm:
handler: handler.alarm
- 定义触发事件：
events:
- cloudwatchEvent:
event:
source:
- "aws.ec2"
detail-type:
- "EC2 Instance State-change Notification"
detail:
state:
- running
- stopping
- shutting-down
- stopped
- terminated
-
编辑
handler.py文件：
import boto3
client = boto3.client('cloudwatch')
def alarm(event, context):
instance = event['detail']['instance-id']
state = event['detail']['state']
if state == "running":
warning = put_alarm(instance, 60, 'alert-email')
critical = put_alarm(instance, 80, 'alert-sms')
return warning, critical
else:
return delete_alarms(instance)
def put_alarm(instance, threshold, sns):
sns_prefix = 'arn:aws:sns:us-east-1:511912822958:'
response = client.put_metric_alarm(
AlarmName='DiskSpaceUtilization-{}-{}'.format(instance, sns),
MetricName='DiskSpaceUtilization',
Namespace='System/Linux',
Dimensions=[
{
"Name": "InstanceId",
"Value": instance
},
{
"Name": "Filesystem",
"Value": "/dev/xvda1"
},
{
"Name": "MountPath",
"Value": "/"
}
],
Statistic='Average',
Period=300,
Unit='Percent',
EvaluationPeriods=2,
Threshold=threshold,
ComparisonOperator='GreaterThanOrEqualToThreshold',
TreatMissingData='missing',
AlarmActions=[
sns_prefix + sns,
],
OKActions=[
sns_prefix + sns,
]
)
return response
def delete_alarms(instance):
names = [
'DiskSpaceUtilization-{}-alert-email'.format(instance),
'DiskSpaceUtilization-{}-alert-sms'.format(instance)
]
return client.delete_alarms(AlarmNames=names)
-
创建额外文件：
-
requirements.txt：
-
boto3==1.4.4
- `package.json`：
{
"name": "disk-free-monitoring",
"version": "1.0.0",
"description": "create cloudwatch alarms for disk space",
"repository": "tbd",
"license": "ISC",
"dependencies": {
"serverless-python-requirements": "^2.3.3"
}
}
-
运行
npm install并部署应用：
$ serverless deploy
5. AWS健康监控与告警
AWS虽然大部分时间稳定，但偶尔也会出现服务降级的情况。你可以通过主仪表盘（https://status.aws.amazon.com）检查服务的整体健康状况，该仪表盘还提供RSS feed，可与大多数通信服务集成。此外，你还可以在AWS控制台中点击铃铛图标访问个性化健康仪表盘（https://phd.aws.amazon.com），该仪表盘会显示影响该区域所有客户的信息以及特定于你账户的通知。
我们可以通过命令行界面创建新规则，以接收不同警报的电子邮件通知：
1. 创建匹配所有来自
aws.health
端点事件的规则：
$ aws events put-rule \
--name AWSHealth \
--event-pattern '{"source":["aws.health"]}' \
--state ENABLED
- 获取目标SNS主题的ARN：
$ aws sns list-topics | grep alert-email
- 将规则和目标关联起来：
aws events put-targets \
--rule AWSHealth\
--targets Id=1,Arn=arn:aws:sns:us-east-1:511912822958:alert-email
6. 文档记录的重要性
所有的监控和告警工作都需要配套良好的文档。文档至少应涵盖不同的故障场景以及如何从中恢复。
7. 可探索的领域
- 基础设施层面 ：可以开始跟踪AWS成本并创建预算，同时对备份进行监控，确保不会错过备份失败的情况。
- 服务层面 ：使用X-Ray分布式请求跟踪服务来监控性能。
- 构建和发布管道层面 ：对CloudFormation、CodeDeploy和CodePipeline进行一些更改，开始跟踪部署和回滚的频率。还可以对Ansible进行同样的操作，当Ansible运行出错时发出警报。
- 质量方面 ：收集测试代码覆盖率信息，确保在推送新代码前进行单元测试。比较停机频率和错误/工单数量，有时可以发现质量下降与停机增加之间的关联。
综上所述，通过利用AWS提供的各种服务，我们可以有效地为应用和基础设施添加监控和告警功能。同时，要将测量和监控融入公司文化，持续完善和优化整个体系。在后续的工作中，我们还可以从安全的角度进一步利用这些构建的组件。
构建AWS应用与基础设施的监控和告警体系
8. 监控和告警体系的整体流程梳理
为了更清晰地理解整个监控和告警体系的构建过程，我们可以梳理一个流程图：
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
A([开始]):::startend --> B(订阅确认):::process
B --> C(创建应用高错误率告警):::process
C --> D(无责事后分析):::process
D --> E(创建自定义指标告警):::process
E --> F(AWS健康监控与告警):::process
F --> G(文档记录):::process
G --> H(探索可优化领域):::process
H --> I([结束]):::startend
这个流程图展示了从订阅确认开始，逐步构建监控和告警体系的主要步骤，包括创建不同类型的告警、进行事后分析、利用AWS健康服务以及完善文档和探索优化方向等。
9. 各监控指标及告警配置的对比分析
| 监控指标 | 告警名称 | 命名空间 | 统计方式 | 周期 | 评估周期 | 阈值 | 比较运算符 | 告警动作 | 恢复动作 | 数据不足动作 |
|---|---|---|---|---|---|---|---|---|---|---|
| HTTP 5XX错误 | ELBHTTP5xxs | AWS/ELB | 平均 | 60秒 | 3个周期 | 30 | 大于等于阈值 | 发送SMS通知 | 发送SMS通知 | 无 |
| 延迟 | ELBHLatency | AWS/ELB | 平均 | 60秒 | 5个周期 | 0.5秒 | 大于等于阈值 | 发送SMS通知 | 发送SMS通知 | 无 |
| 磁盘空间利用率（警告） | DiskSpaceUtilization-{}-alert-email | System/Linux | 平均 | 300秒 | 2个周期 | 60% | 大于等于阈值 | 发送电子邮件通知 | 发送电子邮件通知 | 无 |
| 磁盘空间利用率（严重） | DiskSpaceUtilization-{}-alert-sms | System/Linux | 平均 | 300秒 | 2个周期 | 80% | 大于等于阈值 | 发送SMS通知 | 发送SMS通知 | 无 |
通过这个表格，我们可以清晰地对比不同监控指标的告警配置，方便在实际应用中进行调整和优化。
10. 监控和告警体系的优化建议
- 自动化程度提升 ：可以进一步优化脚本，实现更多自动化操作。例如，在创建自定义指标告警时，可以根据不同的环境（如开发、测试、生产）自动调整告警阈值。
- 多渠道告警 ：除了SMS和电子邮件通知，还可以集成其他通信工具，如Slack、钉钉等，确保团队成员能够及时收到告警信息。
- 数据可视化 ：利用AWS的QuickSight或第三方工具，将监控数据进行可视化展示，更直观地了解系统的运行状态。
- 告警分级 ：根据告警的严重程度进行分级，对于不同级别的告警采取不同的处理流程，提高处理效率。
11. 监控和告警体系的实际应用案例
假设我们有一个电商应用，部署在AWS上。通过上述的监控和告警体系，我们可以实时监控应用的性能和健康状况。
-
应用高错误率告警
：当HTTP 5XX错误率超过阈值时，系统会及时发送SMS通知给运维团队。运维团队可以迅速排查问题，可能是后端服务器出现故障，及时进行修复，避免影响用户体验。
-
自定义指标告警
：对于EC2实例的磁盘空间利用率，当达到警告阈值时，会发送电子邮件通知。如果继续上升到严重阈值，会发送SMS通知。这样可以提前发现磁盘空间不足的问题，及时进行扩容或清理。
-
AWS健康监控与告警
：当AWS出现服务降级或维护通知时，我们可以通过个性化健康仪表盘和电子邮件通知及时了解情况，提前做好应对措施。
12. 总结与展望
在本文中，我们详细介绍了如何利用AWS的各种服务构建应用和基础设施的监控和告警体系。通过订阅确认、创建不同类型的告警、进行无责事后分析、利用CloudWatch事件和Lambda创建自定义指标告警以及AWS健康监控等步骤，我们可以有效地监控系统的运行状态，及时发现并解决问题。
同时，我们也强调了文档记录的重要性以及可探索的优化领域。在未来的工作中，我们可以不断完善监控和告警体系，提高自动化程度、增加多渠道告警、实现数据可视化等，以更好地保障应用和基础设施的稳定运行。
此外，随着技术的不断发展，我们还可以探索更多的监控和告警技术，如机器学习算法在异常检测中的应用，进一步提升监控的准确性和效率。将监控和告警融入公司文化，让团队成员都重视数据测量和分析，共同推动公司的数字化转型和发展。
总之，构建一个完善的监控和告警体系是一个持续的过程，需要不断地优化和改进，以适应不断变化的业务需求和技术环境。通过合理利用AWS提供的资源，我们可以为公司的应用和基础设施保驾护航，实现更好的业务成果。
扫一扫
177
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
