Фильтр подписки CloudWatch: использование лямбды или прямая подписка - PullRequest
Новая
       31

Фильтр подписки CloudWatch: использование лямбды или прямая подписка

0 голосов
/ 06 ноября 2019

Я изучаю потоки CloudWatch Logs в Firehose. Насколько я понимаю, фильтр подписки Cloudwatch - это событие, которое запускает лямбду, чтобы переварить журналы CloudWatch и отправить ее в другое место назначения (ElasticSearch или Firehose или ... другая настраиваемая лямбда). Пожалуйста, поправьте меня, если я ошибаюсь.

Меня беспокоит случай, когда Cloudwatch Logs Stream to Firehose:

1 / С точки зрения производительности и цены, есть ли разница между:

  • Подписка CloudwatchФильтр -> Firehose
  • Фильтр подписки Cloudwatch -> Лямбда -> Firehose

2 / Какой формат данных Firehose получает от Cloudwatch?

  • Подписка CloudwatchФильтр -> Firehose: я не знаю
  • Фильтр подписки Cloudwatch -> Lambda -> Firehose: я думаю, что lambda может преобразовать журналы в JSON, а затем поместить их в Firehose.

Любое предложение приветствуется.

1 Ответ

1 голос
/ 06 ноября 2019
  1. С точки зрения производительности + ценообразования, есть ли какая-либо разница между [лямбда и прямой ход к пожарному шлангу?]:

Да. С точки зрения производительности, вы увидите немного большую задержку, поскольку ваши данные должны пройти через лямбду, прежде чем они попадут в пожарный рукав, но очень вероятно, что увеличение не будет иметь никакого значения. Вы получите гибкость, имея настраиваемый шаг обработки перед вашим пожарным рукавом - возможность выполнить дополнительное преобразование или более эффективную фильтрацию.

NB, вы бы потеряли Автоматическое сжатие CloudWatch при отправке прямо в пожарный шланг - если вам нужно сжатие, вам придется настроить его самостоятельно (возможно, на пожарном шланге). Кроме того, вы будете платить за лямбда-вызовы для обработки промежуточного шага. Проверьте страницу с ценами , чтобы увидеть, имеет ли это значение на самом деле.

Какой формат данных Firehose получает от Cloudwatch?

При прямом переходе на firehose вы получите выходную конфигурацию firehose (куча записей, добавленных вместев файле), где каждая запись является выходом журналов CloudWatch: 

{
    "owner": "123456789012",
    "logGroup": "CloudTrail",
    "logStream": "123456789012_CloudTrail_us-east-1",
    "subscriptionFilters": [
        "Destination"
    ],
    "messageType": "DATA_MESSAGE",
    "logEvents": [
        {
            "id": "31953106606966983378809025079804211143289615424298221568",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        },
        ...
    ]
}

(взято из SubscriptionFilter docs )

При переходе на лямбду:

Фактическая полезная нагрузка, которую получает Lambda, имеет следующий формат {"awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"}}

(также из документов, связанных выше)

Где data - это (закодированный, сжатый) выходной объект CloudWatch выше.

Учитывая, что вы пишете лямбду, вы можете вывести все, что хотите, чтобы отправлялся в пожарный рукав. Имейте в виду, что firehose будет делать то же самое, что и выше, добавляя несколько записей в каждый выходной файл.

Предостережение: убедитесь, что ваш firehose масштабирован соответствующим образом - есливы не осторожны, и у вас недостаточно масштабный, пожарный шланг put s начнет давать сбои, и вы начнете сбрасывать данные журнала. Убедитесь, что вы отслеживаете ошибки!

...