WEBKT

Serverless架构监控告警策略详解：指标选择、阈值设置与实战案例

49 0 0 0

Serverless 监控告警的特殊性

指标选择：关注核心业务

告警阈值设置：动态调整，避免误报

告警通知方式：及时触达，快速响应

实战案例：基于 Serverless Framework 的告警实践

总结

Serverless 架构的兴起，让开发者能够更专注于业务逻辑的实现，而无需过多关注底层基础设施的管理。然而，这并不意味着运维工作可以被完全忽略。相反，Serverless 架构的特殊性，对监控和告警提出了新的挑战。如何有效地监控 Serverless 应用，及时发现并解决问题，保障应用的稳定性和可用性，是每个 Serverless 运维人员都需要面对的问题。接下来，我将结合自己的经验，深入探讨 Serverless 架构下的监控告警策略。我会尽量避免学院派的术语，用更贴近实际工作的语言来和你聊聊。

Serverless 监控告警的特殊性

在传统的 IT 架构中，我们通常会监控服务器的 CPU、内存、磁盘 I/O 等指标。但在 Serverless 架构中，这些指标的意义已经不大。因为我们不再直接管理服务器，而是使用云厂商提供的函数计算、API 网关、对象存储等服务。这些服务本身具有弹性伸缩的特性，能够根据实际负载自动调整资源。因此，我们需要关注的是更贴近业务的指标，例如：

  • 函数执行时间： 函数的执行时间直接影响用户的响应速度，过长的执行时间可能意味着代码存在性能问题，或者资源分配不足。
  • 函数调用次数： 函数的调用次数反映了业务的活跃程度，异常的调用次数可能意味着存在攻击或者Bug。
  • 函数错误率： 函数的错误率是衡量应用稳定性的重要指标，过高的错误率需要及时排查原因。
  • API 网关延迟： API 网关是 Serverless 应用的入口，其延迟直接影响用户的体验。
  • 数据库查询时间： Serverless 应用通常需要与数据库交互，数据库的查询时间会影响整体性能。

除了监控指标的选择，Serverless 架构的告警策略也需要进行相应的调整。在传统的 IT 架构中，我们通常会设置静态阈值，例如 CPU 使用率超过 80% 就触发告警。但在 Serverless 架构中，由于弹性伸缩的特性，静态阈值可能并不适用。例如，在流量高峰期，函数的 CPU 使用率可能会短暂超过 80%，但这并不一定意味着存在问题。因此，我们需要采用更智能的告警策略，例如：

  • 动态阈值： 基于历史数据，使用机器学习算法自动计算阈值，能够更好地适应流量的变化。
  • 异常检测： 使用异常检测算法，自动发现与历史模式不符的异常行为，例如函数调用次数突然增加。
  • 多指标联动： 将多个指标关联起来，综合判断是否需要触发告警，例如当函数执行时间增加，同时错误率也增加时，才触发告警。

指标选择：关注核心业务

选择合适的监控指标是构建有效监控告警体系的第一步。我们需要根据具体的业务场景，选择最能反映应用健康状况的指标。一般来说，可以从以下几个方面入手：

  1. 函数层面：

    • Invocations (调用次数): 监控函数的调用频率，可以帮助我们了解业务的活跃程度，并及时发现异常的流量波动。例如，如果某个函数突然被大量调用，可能意味着存在恶意攻击。你需要区分正常流量增长和恶意攻击，前者可能需要你扩容资源，后者则需要安全策略介入。
    • Errors (错误次数): 监控函数执行过程中发生的错误次数，是评估应用稳定性的关键指标。错误可能源于代码 Bug、资源不足、依赖服务故障等多种原因。如果错误率持续升高，就需要立即排查问题。
    • Duration (执行时间): 监控函数执行所花费的时间，是评估应用性能的重要指标。过长的执行时间可能意味着代码存在性能瓶颈，或者资源分配不足。你需要关注平均执行时间和最大执行时间，后者可以帮助你发现偶发的性能问题。
    • Throttled (限流次数): 监控函数被云厂商限流的次数。当函数调用超过云厂商的限制时，就会被限流。这通常意味着你需要增加分配给函数的资源，或者优化代码以减少资源消耗。
    • DeadLetterErrors (死信队列错误): 如果你的函数使用了死信队列，那么你需要监控死信队列中的错误。死信队列用于存储处理失败的消息，监控死信队列可以帮助你发现异步处理中的问题。这个指标容易被忽略，但它对于保证数据一致性非常重要。
    • IteratorAge (迭代器延迟): 如果你的函数被用作流处理的消费者，例如从 Kafka 或 Kinesis 中读取数据，那么你需要监控迭代器延迟。迭代器延迟表示函数处理数据的速度落后于数据产生的速度，过高的迭代器延迟可能导致数据积压。想象一下，你的函数像一个水龙头，而数据源像一个水库。如果水龙头流出的速度太慢，水库就会溢出。迭代器延迟就是用来衡量水龙头是否堵塞的指标。

  2. API 网关层面：

    • Count (请求次数): 监控 API 的请求次数，可以帮助我们了解 API 的使用情况，并及时发现异常的流量波动。与函数调用次数类似，你需要区分正常流量增长和恶意攻击。
    • Latency (延迟): 监控 API 的响应延迟，是评估用户体验的关键指标。延迟过高可能导致用户流失。你需要关注平均延迟和 P95/P99 延迟，后者可以帮助你发现长尾延迟问题。P95 延迟指的是 95% 的请求的延迟低于该值，P99 延迟同理。长尾延迟往往是影响用户体验的关键因素。
    • 4XXError (客户端错误): 监控 API 返回的 4XX 错误，表示客户端请求存在问题。例如，400 Bad Request 表示请求参数错误，404 Not Found 表示请求的资源不存在。你需要分析 4XX 错误的具体原因，并及时修复。
    • 5XXError (服务端错误): 监控 API 返回的 5XX 错误，表示服务端处理请求时发生错误。例如，500 Internal Server Error 表示服务器内部错误，503 Service Unavailable 表示服务不可用。5XX 错误通常需要立即排查，因为它可能意味着服务出现严重问题。

  3. 数据库层面：

    • Connections (连接数): 监控数据库的连接数，可以帮助我们了解数据库的负载情况。过高的连接数可能导致数据库性能下降，甚至崩溃。你需要根据数据库的类型和配置，设置合理的连接数阈值。
    • Latency (查询延迟): 监控数据库查询的延迟，是评估数据库性能的重要指标。延迟过高可能导致应用响应缓慢。你需要关注平均查询延迟和 P95/P99 查询延迟，并针对慢查询进行优化。
    • Errors (错误次数): 监控数据库操作的错误次数，可以帮助我们发现数据库连接问题、权限问题、SQL 错误等。你需要分析错误日志，并及时修复问题。
    • CPU Utilization (CPU 使用率): 监控数据库服务器的 CPU 使用率，可以帮助我们了解数据库的资源消耗情况。过高的 CPU 使用率可能导致数据库性能下降。你需要根据数据库的类型和配置，设置合理的 CPU 使用率阈值。
    • Memory Utilization (内存使用率): 监控数据库服务器的内存使用率，可以帮助我们了解数据库的资源消耗情况。过高的内存使用率可能导致数据库性能下降，甚至崩溃。你需要根据数据库的类型和配置，设置合理的内存使用率阈值。

  4. 其他服务层面：

    • 消息队列长度： 如果你的应用使用了消息队列，例如 SQS 或 Kafka，那么你需要监控消息队列的长度。过长的队列长度可能意味着消费者处理消息的速度跟不上生产者生产消息的速度，导致消息积压。你需要增加消费者数量，或者优化消费者代码以提高处理速度。
    • 对象存储请求延迟： 如果你的应用使用了对象存储，例如 S3，那么你需要监控对象存储的请求延迟。延迟过高可能影响应用的性能。你需要检查网络连接、对象大小、存储桶配置等因素。
    • 外部 API 调用延迟： 如果你的应用调用了外部 API，那么你需要监控外部 API 的调用延迟。延迟过高可能影响应用的性能。你需要与外部 API 提供商联系，了解是否存在问题。

在选择监控指标时，你需要避免过度监控。监控过多的指标不仅会增加运维成本，还会分散你的注意力，让你难以发现真正的问题。你需要根据业务的重要性，选择最关键的指标进行监控。同时，你还需要定期审查监控指标，删除不再需要的指标，并添加新的指标以适应业务的变化。

告警阈值设置：动态调整，避免误报

设置合理的告警阈值是构建有效监控告警体系的另一个关键环节。过高的阈值可能导致问题被忽略，过低的阈值可能导致频繁的误报。在 Serverless 架构中，由于弹性伸缩的特性，静态阈值往往难以满足需求。我们需要采用更智能的阈值设置方法，例如：

  1. 静态阈值：

    • 固定值： 设置一个固定的数值作为阈值。例如，当函数错误率超过 1% 时触发告警。这种方法简单直接，适用于对指标有明确的容忍范围的情况。你需要根据历史数据和业务需求，选择合适的固定值。
    • 百分比： 设置一个百分比作为阈值。例如，当 API 延迟超过历史平均值的 20% 时触发告警。这种方法能够适应流量的变化，但需要定期更新历史平均值。你需要选择合适的时间窗口来计算历史平均值，以避免受到异常数据的影响。

  2. 动态阈值：

    • 基于统计： 使用统计方法，例如平均值、标准差、中位数等，自动计算阈值。例如，当函数执行时间超过过去 7 天的平均值加上 3 个标准差时触发告警。这种方法能够适应流量的变化，并自动调整阈值。你需要选择合适的统计方法和时间窗口，以避免受到异常数据的影响。
    • 基于机器学习： 使用机器学习算法，例如异常检测、时间序列预测等，自动计算阈值。例如，使用异常检测算法，自动发现与历史模式不符的异常行为，并触发告警。这种方法能够更准确地识别异常，并减少误报。你需要选择合适的机器学习算法和训练数据，以保证算法的准确性。

  3. 多维度阈值：

    • 组合阈值： 将多个指标组合起来，设置告警阈值。例如，当函数执行时间超过 1 秒，并且错误率超过 1% 时，才触发告警。这种方法能够更准确地判断是否存在问题，并减少误报。你需要根据业务场景，选择合适的指标组合。
    • 分时段阈值： 根据不同的时间段，设置不同的告警阈值。例如，在流量高峰期，可以适当提高阈值，以避免频繁的误报。你需要分析流量模式，并设置合适的时间段和阈值。

在设置告警阈值时，你需要充分考虑以下因素：

  • 业务重要性： 对于重要的业务，应该设置更低的阈值，以便及时发现问题。
  • 历史数据： 参考历史数据，了解指标的正常范围，并设置合理的阈值。
  • 容忍范围： 了解业务对指标的容忍范围，并设置合适的阈值。
  • 误报率： 评估误报率，并根据需要调整阈值。

你需要不断地调整告警阈值，以适应业务的变化。你可以通过监控告警的准确率和召回率，来评估阈值的效果。准确率指的是告警的真实性，召回率指的是问题被发现的概率。你需要根据业务需求，平衡准确率和召回率。

告警通知方式：及时触达，快速响应

选择合适的告警通知方式是构建有效监控告警体系的最后一个关键环节。告警通知的目的是及时将问题通知给相关人员，以便快速响应并解决问题。一般来说，可以选择以下几种告警通知方式：

  1. 邮件：

    • 优点： 邮件是一种非实时的通知方式，适用于对响应时间要求不高的场景。邮件可以包含详细的告警信息，方便问题排查。
    • 缺点： 邮件容易被忽略，可能导致问题得不到及时处理。

  2. 短信：

    • 优点： 短信是一种实时的通知方式，能够及时将告警信息通知给相关人员。
    • 缺点： 短信的长度有限制，可能无法包含详细的告警信息。短信容易被骚扰，可能导致重要告警被忽略。

  3. 电话：

    • 优点： 电话是一种最直接的通知方式，能够确保告警信息被及时接收。
    • 缺点： 电话容易打扰到相关人员，只适用于非常紧急的告警。

  4. 即时通讯工具：

    • 优点： 即时通讯工具，例如企业微信、钉钉、Slack 等，是一种实时的通知方式，能够及时将告警信息通知给相关人员。即时通讯工具可以支持富文本消息，方便问题排查。
    • 缺点： 即时通讯工具容易被骚扰，可能导致重要告警被忽略。

  5. 告警平台：

    • 优点： 告警平台能够统一管理告警信息，并提供丰富的告警处理功能，例如告警升级、告警抑制、告警聚合等。告警平台能够提高告警处理效率，并减少告警疲劳。
    • 缺点： 告警平台需要一定的学习成本，并且可能需要付费使用。

在选择告警通知方式时，你需要充分考虑以下因素：

  • 告警级别： 对于不同级别的告警，应该选择不同的通知方式。例如，对于紧急告警，可以选择电话或短信通知，对于非紧急告警，可以选择邮件或即时通讯工具通知。
  • 响应时间： 对于需要快速响应的告警，应该选择实时的通知方式。对于不需要快速响应的告警，可以选择非实时的通知方式。
  • 人员职责： 根据人员的职责，选择合适的通知对象。例如，对于数据库告警，应该通知数据库管理员，对于 API 告警，应该通知 API 开发人员。
  • 值班制度： 建立完善的值班制度，确保告警信息能够被及时处理。

你需要不断地优化告警通知方式，以提高告警处理效率。你可以通过监控告警的响应时间和解决时间，来评估通知方式的效果。同时，你还需要定期审查告警通知规则，删除不再需要的规则，并添加新的规则以适应业务的变化。

实战案例：基于 Serverless Framework 的告警实践

接下来，我将结合 Serverless Framework，介绍一个基于 Serverless 架构的告警实践案例。我们将使用 Serverless Framework 部署一个简单的 API，并使用 CloudWatch Alarms 监控 API 的延迟和错误率。当延迟超过 1 秒，或者错误率超过 1% 时，我们将通过邮件发送告警通知。

  1. 创建 Serverless 项目：

    首先，我们需要创建一个 Serverless 项目。你可以使用 Serverless Framework 提供的模板，快速创建一个基本的项目结构。

    		serverless create --template aws-nodejs --path alarm-demo
    		cd alarm-demo

  2. 定义 API：

    接下来，我们需要定义一个简单的 API。我们将在 handler.js 文件中编写 API 的处理逻辑。

    		module.exports.hello = async (event) => {
    		  // 模拟 API 延迟
    		  await new Promise(resolve => setTimeout(resolve, 500));
    		 
    		  return {
    		    statusCode: 200,
    		    body: JSON.stringify(
    		      {
    		        message: 'Go Serverless v3.0! Your function executed successfully!',
    		        input: event,
    		      },
    		      null,
    		      2
    		    ),
    		  };
    		};

    这个 API 会模拟 500 毫秒的延迟，并返回一个简单的 JSON 响应。

  3. 配置 Serverless.yml：

    然后，我们需要配置 serverless.yml 文件，定义 API 的路径和函数配置。

    		service: alarm-demo
    		 
    		frameworkVersion: '3'
    		 
    		provider:
    		  name: aws
    		  runtime: nodejs14.x
    		  region: ap-southeast-1 # 替换为你的 AWS 区域
    		  iam:
    		    role:
    		      statements:
    		        - Effect: 'Allow'
    		          Action:
    		            - 'cloudwatch:PutMetricData'
    		          Resource: '*'
    		 
    		functions:
    		  hello:
    		    handler: handler.hello
    		    events:
    		      - http:
    		          path: hello
    		          method: get

    在这个配置文件中，我们定义了一个名为 hello 的函数，并将其绑定到 /hello 路径的 GET 请求上。我们还添加了 IAM 权限，允许函数向 CloudWatch 发送指标数据。

  4. 创建 CloudWatch Alarms：

    现在，我们需要创建 CloudWatch Alarms，监控 API 的延迟和错误率。我们可以使用 Serverless Framework 提供的 resources 属性，在 serverless.yml 文件中定义 CloudWatch Alarms。

    		resources:
    		  Resources:
    		    ApiGatewayLatencyAlarm:
    		      Type: AWS::CloudWatch::Alarm
    		      Properties:
    		        AlarmName: ApiGatewayLatencyAlarm
    		        AlarmDescription: Triggered when API Gateway latency exceeds 1 second
    		        Namespace: AWS/ApiGateway
    		        MetricName: Latency
    		        Dimensions:
    		          - Name: ApiName
    		            Value: alarm-demo-dev # 替换为你的 API Gateway 名称
    		          - Name: Stage
    		            Value: dev
    		        Statistic: Average
    		        Period: 60
    		        EvaluationPeriods: 1
    		        Threshold: 1000 # 毫秒
    		        ComparisonOperator: GreaterThanThreshold
    		        TreatMissingData: notBreaching
    		        AlarmActions:
    		          - !Ref ApiGatewayAlarmTopic
    		 
    		    ApiGatewayErrorAlarm:
    		      Type: AWS::CloudWatch::Alarm
    		      Properties:
    		        AlarmName: ApiGatewayErrorAlarm
    		        AlarmDescription: Triggered when API Gateway error rate exceeds 1%
    		        Namespace: AWS/ApiGateway
    		        MetricName: 5XXError
    		        Dimensions:
    		          - Name: ApiName
    		            Value: alarm-demo-dev # 替换为你的 API Gateway 名称
    		          - Name: Stage
    		            Value: dev
    		        Statistic: Sum
    		        Period: 60
    		        EvaluationPeriods: 1
    		        Threshold: 1
    		        ComparisonOperator: GreaterThanThreshold
    		        TreatMissingData: notBreaching
    		        AlarmActions:
    		          - !Ref ApiGatewayAlarmTopic
    		 
    		    ApiGatewayAlarmTopic:
    		      Type: AWS::SNS::Topic
    		      Properties:
    		        Subscription:
    		          - Endpoint: your_email@example.com # 替换为你的邮箱地址
    		            Protocol: email

    在这个配置文件中，我们定义了两个 CloudWatch Alarms：ApiGatewayLatencyAlarm 和 ApiGatewayErrorAlarm。ApiGatewayLatencyAlarm 监控 API 的平均延迟，当延迟超过 1 秒时触发告警。ApiGatewayErrorAlarm 监控 API 的 5XX 错误，当错误次数超过 1 次时触发告警。当告警触发时，我们会通过 SNS Topic ApiGatewayAlarmTopic 发送邮件通知。你需要将 your_email@example.com 替换为你的邮箱地址，并将 alarm-demo-dev 替换为你的 API Gateway 名称。API Gateway 的名称可以在 AWS 控制台中找到。

  5. 部署 Serverless 项目：

    最后，我们需要部署 Serverless 项目。

    serverless deploy

    部署完成后，你可以通过 API Gateway 的 URL 访问 API。你可以尝试增加 API 的延迟，或者模拟 API 错误，来触发 CloudWatch Alarms。当告警触发时，你会收到一封邮件通知。

这个案例只是一个简单的示例，你可以根据实际需求，扩展告警的监控指标和通知方式。例如，你可以添加函数层面的告警，监控函数的执行时间、错误次数、限流次数等。你还可以使用其他的告警通知方式，例如短信、电话、即时通讯工具等。

总结

Serverless 架构的监控告警是一个复杂而重要的课题。你需要根据具体的业务场景，选择合适的监控指标，设置合理的告警阈值，并选择合适的告警通知方式。你需要不断地优化监控告警策略，以适应业务的变化，并提高告警处理效率。希望这篇文章能够帮助你更好地理解 Serverless 架构的监控告警，并构建更稳定、更可靠的 Serverless 应用。

记住，监控告警不是一劳永逸的事情，而是一个持续改进的过程。你需要不断地学习新的技术和方法，并将其应用到你的 Serverless 应用中。只有这样，你才能真正地掌握 Serverless 架构的运维，并充分发挥其优势。

Serverless老司机 Serverless监控告警策略CloudWatch Alarms

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9591