Question

TLDR

由于＆＃34;编码问题＆＃34; lambda函数无法将firehose日志索引到AWS托管ES中。

实际错误响应

当我从firehose logEvent base64编码单个record并将收集的记录发送到AWS托管ES时，我没有收到任何错误。

有关详细信息，请参阅下一节。

基本64位编码的压缩有效负载正在发送到ES，因为生成的json转换对于ES来说太大而无法索引 - see this ES link。

我从AWS托管ES中收到以下错误：

{
    "deliveryStreamARN": "arn:aws:firehose:us-west-2:*:deliverystream/*",
    "destination": "arn:aws:es:us-west-2:*:domain/*",
    "deliveryStreamVersionId": 1,
    "message": "The data could not be decoded as UTF-8",
    "errorCode": "InvalidEncodingException",
    "processor": "arn:aws:lambda:us-west-2:*:function:*"
  }

如果未压缩输出记录，the body size is too long（小至14MB）。如果没有压缩和简单的base64编码有效负载，我会在Lambda日志中收到以下错误：

{
  "type": "mapper_parsing_exception",
  "reason": "failed to parse",
  "caused_by": {
    "type": "not_x_content_exception",
    "reason": "Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes"
  }
}

描述

我有Cloudwatch日志，它们被大小/间隔缓冲，并被送入Kinesis Firehose。 firehose将日志传输到lambda函数，该函数将日志转换为json记录，然后将其发送到AWS托管的Elasticsearch集群。

lambda函数获得以下JSON结构：

{
    "invocationId": "cf1306b5-2d3c-4886-b7be-b5bcf0a66ef3",
    "deliveryStreamArn": "arn:aws:firehose:...",
    "region": "us-west-2",
    "records": [{
        "recordId": "49577998431243709525183749876652374166077260049460232194000000",
        "approximateArrivalTimestamp": 1508197563377,
        "data": "some_compressed_data_in_base_64_encoding"
    }]
}

lambda函数然后提取.records[].data并将数据解码为base64并解压缩导致以下JSON的数据：

{
  "messageType": "DATA_MESSAGE",
  "owner": "aws_account_number",
  "logGroup": "some_cloudwatch_log_group_name",
  "logStream": "i-0221b6ec01af47bfb",
  "subscriptionFilters": [
    "cloudwatch_log_subscription_filter_name"
  ],
  "logEvents": [
    {
      "id": "33633929427703365813575134502195362621356131219229245440",
      "timestamp": 1508197557000,
      "message": "Oct 16 23:45:57 some_log_entry_1"
    },
    {
      "id": "33633929427703365813575134502195362621356131219229245441",
      "timestamp": 1508197557000,
      "message": "Oct 16 23:45:57 some_log_entry_2"
    },
    {
      "id": "33633929427703365813575134502195362621356131219229245442",
      "timestamp": 1508197557000,
      "message": "Oct 16 23:45:57 some_log_entry_3"
    }
  ]
}

来自.logEvents[]的单个项目被转换为json结构，其中在Kibana中搜索日志时键是所需的列 - 如下所示：

{
    'journalctl_host': 'ip-172-11-11-111',
    'process': 'haproxy',
    'pid': 15507,
    'client_ip': '172.11.11.111',
    'client_port': 3924,
    'frontend_name': 'http-web',
    'backend_name': 'server',
    'server_name': 'server-3',
    'time_duration': 10,
    'status_code': 200,
    'bytes_read': 79,
    '@timestamp': '1900-10-16T23:46:01.0Z',
    'tags': ['haproxy'],
    'message': 'HEAD / HTTP/1.1'
}

转换后的json被收集到一个数组中，该数组获得zlib压缩和base64编码的字符串，然后将其转换为新的json有效负载作为最终的lambda结果：

{
"records": [
    {
        "recordId": "49577998431243709525183749876652374166077260049460232194000000",
        "result": "Ok",
        "data": "base64_encoded_zlib_compressed_array_of_transformed_logs"
    }
]}

Cloudwatch配置

13个日志条目（~4kb）可以转换为大约635kb。

我还减少了awslogs的阈值，希望发送给Lambda函数的日志大小变小：

buffer_duration = 10
batch_count = 10
batch_size = 500

不幸的是，当有爆发时 - 尖峰可以超过2800行，其中大小超过1MB。

当lambda函数产生的有效负载为＆＃34;太大＆＃34; （约13mb的转换日志），在lambda cloudwatch日志中记录错误 - ＆＃34;体型太长＆＃34;。似乎没有任何迹象表明此错误的来源或lambda fn的响应有效负载是否有大小限制。

Answer 1

因此，AWS支持人员告诉我，可以减轻以下限制来解决此问题：

lambda payload size
压缩的firehose有效负载进入lambda，与lambda输出成正比。

相反，我已将架构修改为以下内容：

Cloudwatch日志通过Firehose在S3中备份。
S3事件由lambda函数处理。
如果lambda转换并且能够成功地将日志批量索引到ES中，则lambda函数返回成功代码。
如果lambda函数失败，则使用cloudwatch警报配置死信队列（AWS SQS）。可以找到示例云形式代码段here。
如果存在SQS消息，可以使用这些消息手动调用lambda函数，或者设置AWS批处理作业以使用lambda函数处理SQS消息。但是，应该注意，lambda函数不会再次故障转移到DLQ中。检查lambda cloudwatch日志以检查未处理该消息的原因并将其发送到DLQ。

如何将转换后的日志记录编入索引到AWS Elasticsearch？

TLDR

实际错误响应

描述

Cloudwatch配置

1 个答案: