Сообщество RSS DEV
Подписаться
CloudWatch в OTel: Разрушение паттерна моста наблюдаемости
Шаблон моста CloudWatch — OpenTelemetry является распространенным решением для финансовых платформ, которым необходимо консолидировать метрики AWS в унифицированные бэкенды наблюдаемости. Его основная цель — устранить фрагментацию наблюдаемости путем перенаправления метрик из служб AWS во внешнюю систему, поддерживающую OpenTelemetry. Этот шаблон обычно включает в себя службы AWS, отправляющие метрики в CloudWatch, которые затем захватываются потоками метрик CloudWatch (CloudWatch Metric Streams) или извлекаются через API GetMetricData. Эти метрики преобразуются в формат OpenTelemetry, часто с помощью функции Lambda или коллектора OpenTelemetry, перед отправкой в бэкенд наблюдаемости, такой как Datadog или Grafana.
Однако это "очевидное" решение несет в себе скрытые сложности, особенно в высоконагруженных финансовых средах, где свежесть метрик и стоимость API имеют решающее значение. Шаблон имеет два основных пути приема данных: потоки метрик CloudWatch с Kinesis Firehose обеспечивают низкую задержку и предсказуемые затраты, в то время как опрос с помощью GetMetricData обеспечивает детальный контроль, но сопряжен с риском превышения лимитов скорости API и высоких затрат. Надежная функция преобразования Lambda должна быть идемпотентной, включать автоматический выключатель для внешнего конечного узла и иметь очередь недоставленных сообщений (Dead Letter Queue) с оповещениями.
Этот шаблон подходит, когда требуется внешний бэкенд, поддерживающий OTLP, объем метрик оправдывает стоимость потока, и требуется соглашение об уровне обслуживания (SLO) по свежести метрик в 60 секунд или менее. Он также помогает отделить наблюдаемость от AWS и обеспечивает корреляцию трассировок и метрик. Безопасность имеет первостепенное значение, требуя строгих политик IAM с условиями ресурсов, шифрования KMS для данных в пути и контролируемого исходящего сетевого трафика. Антипаттерны, которых следует избегать, включают наивный опрос, функции Lambda без надлежащей обработки ошибок или зарезервированной параллельности, а также попытки перенаправить журналы или трассировки через этот мост, ориентированный на метрики. Хорошо спроектированная реализация отдает приоритет фильтрации метрик на уровне потока, использует эффективную буферизацию, инструментирует сам мост для наблюдаемости и применяет строгие меры безопасности.
