

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Health 检查日志
<a name="load-balancer-health-check-logs"></a>

Elastic Load Balancing 提供运行状况检查日志，用于捕获有关注册目标运行状况检查状态的详细信息，包括运行状况检查失败时的失败原因。EC2 实例、IP 地址和 Lambda 函数目标都支持运行状况检查日志。每个日志条目都包含运行状况检查请求类型或连接、时间戳、目标地址、目标组 ID、健康状态和原因代码等信息。您可以使用这些运行状况检查日志来分析目标运行状况模式、监控运行状况变化并解决问题。

Health check 日志是一项可选功能，默认情况下处于禁用状态。为负载均衡器启用运行状况检查日志后，Elastic Load Balancing 会捕获日志并将其作为压缩文件存储在您指定的 Amazon S3 存储桶中。您可以随时禁用运行状况检查日志。

您需要支付 Amazon S3 的存储费用，但无需支付 Elastic Load Balancing 用以将日志文件发送到 Amazon S3 的带宽费用。有关存储成本的更多信息，请参阅 [Amazon S3 定价](https://www.amazonaws.cn/s3/pricing/)。

**Topics**
+ [Health 检查日志文件](#health-check-log-file-format)
+ [Health check 日志条目](#health-check-log-entry-format)
+ [示例 日志条目](#health-check-log-file-entries)
+ [配置日志传输通知](#health-check-log-event-notifications)
+ [处理运行状况检查日志文件](#health-check-log-processing-tools)
+ [为 Application Load Balancer 启用运行状况检查日志](enable-health-check-logging.md)
+ [禁用 Application Load Balancer 的运行状况检查日志](disable-health-check-logging.md)

## Health 检查日志文件
<a name="health-check-log-file-format"></a>

Elastic Load Balancing 每 5 分钟为每个负载均衡器节点发布一次日志文件。当有大量目标连接到负载均衡器或配置了较小的运行状况检查间隔（例如，每 5 秒）时，负载均衡器可以在同一时间段内传送多个日志。

运行状况检查日志的文件名使用以下格式：

```
{{bucket}}[/{{prefix}}]/AWSLogs/{{aws-account-id}}/elasticloadbalancing/{{region}}/{{yyyy}}/{{mm}}/{{dd}}/health_check_log_{{aws-account-id}}_elasticloadbalancing_{{region}}_app.{{load-balancer-id}}_{{end-time}}_{{ip-address}}_{{random-string}}.log.gz
```

*bucket*  
S3 存储桶的名称。

*prefix*  
（可选）存储桶的前缀（逻辑层级结构）。您指定的前缀不得包含字符串 `AWSLogs`。要获取更多信息，请参阅[使用前缀整理对象](https://docs.amazonaws.cn/AmazonS3/latest/userguide/using-prefixes.html)。

`AWSLogs`  
我们会在您指定的存储桶名称和可选前缀后添加以 `AWSLogs` 开头的文件名部分。

*aws-account-id*  
所有者的 Amazon 账户 ID。

*region*  
负载均衡器和 S3 存储桶所在的区域。

*yyyy*/*mm*/*dd*  
传输日志的日期。

*load-balancer-id*  
负载均衡器的资源 ID。如果资源 ID 包含任何正斜杠 (/)，这些正斜杠将替换为句点 (.)。

*end-time*  
日志记录间隔结束的日期和时间。例如，结束时间 20140215T2340Z 包含在 UTC 时间（即祖鲁时间）23:35 和 23:40 之间发出的请求的条目。

*ip-address*  
处理请求的负载均衡器节点的 IP 地址。对于内部负载均衡器，这是私有 IP 地址。

*random-string*  
系统生成的随机字符串。

以下是一个带前缀的日志文件名示例：

```
s3://amzn-s3-demo-logging-bucket/logging-prefix/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz
```

以下是一个不带前缀的日志文件名示例：

```
s3://amzn-s3-demo-logging-bucket/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz
```

日志文件可以在存储桶中存储任意长时间，不过您也可以定义 Amazon S3 生命周期规则以自动存档或删除日志文件。有关更多信息，请参阅《Amazon S3 用户指南》中的[对象生命周期管理](https://docs.amazonaws.cn/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)**。

## Health check 日志条目
<a name="health-check-log-entry-format"></a>

Elastic Load Balancing 记录目标运行状况检查结果，包括该负载均衡器的所有注册目标的失败原因。每个日志条目都包含对注册目标进行的单个运行状况检查结果的详细信息。

**Topics**
+ [语法](#health-check-log-entry-syntax)
+ [错误原因代码](#health-check-error-reason-codes)

### 语法
<a name="health-check-log-entry-syntax"></a>

下表按顺序描述了运行状况检查日志条目的字段。使用空格分隔所有字段。添加新字段时，我们会将其添加到日志条目的末尾。当我们准备发布新字段时，您可能会在该字段发布之前看到一个额外的尾号“-”。务必要将日志解析配置为在最后一个记录的字段之后停止，并在我们发布新字段后更新日志解析。


| 字段（位置） | 说明 | 
| --- | --- | 
| type（1） | 运行状况检查请求或连接的类型。可能的值如下 (忽略任何其他值)：[See the AWS documentation website for more details](http://docs.amazonaws.cn/elasticloadbalancing/latest/application/load-balancer-health-check-logs.html) | 
| time（2） | 对目标启动运行状况检查的时间戳，格式为 ISO 8601。 | 
| 延迟 (3) | 完成当前运行状况检查所用的总时间（以秒为单位）。 | 
| target\_addr (4) | 目标的 IP 地址和端口，格式为 IP: 端口。如果目标是 Lambda 函数，则为 Lambda 的 ARN。 | 
| 目标群组 ID (5) | 与目标关联的目标组的名称。 | 
| 状态 (6) | 运行状况检查的状态。`PASS`如果运行状况检查成功，则此值为。运行状况检查失败时，该值为 `FAIL` | 
| 状态码 (7) | 从目标收到的运行状况检查请求的响应代码。 | 
| 原因代码 (8) | 如果运行状况检查失败，则失败的原因。请参阅 [错误原因代码](#health-check-error-reason-codes)。 | 

### 错误原因代码
<a name="health-check-error-reason-codes"></a>

如果目标运行状况检查失败，负载均衡器将在运行状况检查日志中记录以下原因代码之一。


| 代码 | 说明 | 
| --- | --- | 
| `RequestTimedOut` | Health 检查请求在等待响应时超时 | 
| `ConnectionTimedOut` | 由于 TCP 连接尝试超时，Health 检查失败 | 
| `ConnectionReset` | 由于连接重置，Health 检查失败 | 
| `ResponseCodeMismatch` | 目标对运行状况检查请求的响应的 HTTP 状态代码与配置的状态码不匹配 | 
| `ResponseStringMismatch` | 目标返回的响应正文不包含目标组运行状况检查配置中配置的字符串 | 
| `InternalError` | 内部负载均衡器错误 | 
| `TargetError` | Target 在响应运行状况检查请求时返回 5xx 错误代码 | 
| `GRPCStatusHeaderEmpty` | GRPC 目标响应有一个没有值的 grpc-status 标头 | 
| `GRPCUnexpectedStatus` | GRPC 目标以意外的 grpc 状态进行响应 | 

## 示例 日志条目
<a name="health-check-log-file-entries"></a>

以下是运行状况检查日志条目的示例。请注意，示例文本以多行形式显示，这只是为了更方便阅读。

以下是成功运行状况检查的日志条目示例。

```
http 2025-10-31T12:44:59.875678Z 0.019584011 172.31.20.97:80 HCLogsTestIPs PASS 200 -
```

以下是运行状况检查失败的示例日志条目。

```
http 2025-10-31T12:44:58.901409Z 1.121980746 172.31.31.9:80 HCLogsTestIPs FAIL 502 TargetError
```

## 配置日志传输通知
<a name="health-check-log-event-notifications"></a>

要在弹性负载均衡将日志传输到 S3 存储桶时收到通知，请使用 Amazon S3 事件通知功能。Elastic Load Balancing 使用[PutObject[CreateMultipartUpload](https://docs.amazonaws.cn/AmazonS3/latest/API/API_CreateMultipartUpload.html)](https://docs.amazonaws.cn/AmazonS3/latest/API/API_PutObject.html)、和 [POST 对象](https://docs.amazonaws.cn/AmazonS3/latest/API/RESTObjectPOST.html)将日志传输到 Amazon S3。为确保您收到所有日志传输通知，请在配置中包含所有这些对象创建事件。

有关更多信息，请参阅《Amazon Simple Storage Service 用户指南》中的 [Amazon S3 事件通知](https://docs.amazonaws.cn/AmazonS3/latest/userguide/EventNotifications.html)**。

## 处理运行状况检查日志文件
<a name="health-check-log-processing-tools"></a>

运行状况检查日志文件已压缩。如果您下载这些文件，则必须对其进行解压才能查看信息。

如果您的网站上有大量需求，则负载均衡器可以生成包含大量数据的日志文件 (以 GB 为单位)。您可能无法使用处理来 line-by-line处理如此大量的数据。因此，您可能必须使用提供并行处理解决方案的分析工具。例如，您可以使用以下分析工具来分析和处理运行状况检查日志：
+ Amazon Athena 是一种交互式查询服务，方便使用标准 SQL 分析 Amazon S3 的数据。
+ [Loggly](https://documentation.solarwinds.com/en/success_center/loggly/content/admin/s3-ingestion-auto.htm)
+ [Splunk](https://splunk.github.io/splunk-add-on-for-amazon-web-services/)
+ [Sumo Logic](https://www.sumologic.com/application/elb/)