Для мониторинга CloudFront, как и любых других сервисов AWS, по умолчанию можно использовать CloudWatch. Тем не менее этот сервис достаточно сильно отличается от других по ряду причин, которые мы как раз рассмотрим в этой статье. Кроме того, разберемся как забирать метрики к себе с помощью cloudwatch_exporter.
Содержание
Мониторинг CloudFront с помощью cloudwatch_exporter
Работа с CloudFront уникальна по части региона AWS, есть также нюансы с именованием ресурсов, но это мы оставим на потом, а пока рассмотрим особенности представления данных.
Сходимость данных
Основным нюансом использования метрик CloudFront является долгая сходимость данных. Выражается это в том, что значения последних пяти одноминутных точек не окончательные и периодически изменяются в большую сторону.
Наиболее наглядно это поведение можно продемонстрировать на метрике BytesDownloaded. Обратите внимание на минутный график ниже. Значение метрики на 07:12 составляет 1 095 578 601:
Теперь тот же график, но минуту спустя:
Указатель все также на точке 07:12, но её значение теперь составляет уже 1 247 892 395! Тот же график, но спустя 4 минуты от первого изображения:
Теперь отметка 07:12 показывает уже 1 288 307 976. На этой цифре все и остановилось.
Подобное поведение заставляет нас брать отметки минимум пятиминутной давности, а лучше подстраховаться и взять все 10 минут назад. В этом случае мы должны будем выставлять у cloudwatch_exporter следующие опции:
|
1 2 3 4 |
delay_seconds: 600 range_seconds: 60 period_seconds: 60 set_timestamp: false |
Подобное поведение я проверял на метриках с большими значениями, поэтому в качестве примера была взята именно BytesDownloaded. На 5xxErrorRate это может быть уже не так заметно, потому что за минуту может не проскочить ни одной пятисотки.
Тэгирование ресурсов
Метрики CloudFront уникально идентифицируются в CloudWatch только по distribution_id (Per-Distribution Metrics). Это неудобно, потому что вместо красивого урла вам придется всматриваться в бессмысленные идентификаторы наподобие E2K15KRJXT93A3. В Прометей он переедет в виде лейбла, например:
|
1 |
aws_cloudfront_requests_sum{distribution_id="E2K15KRJXT93A3", instance="localhost:9106", job="exporters"} 9 |
Способ добавить нужные вам лейблы есть и упирается он в использование тегов 1. В конфигурации Terraform это будет выглядеть так:
|
1 2 3 4 5 6 7 8 9 |
resource "aws_cloudfront_distribution" "name" { ... tags = { Scrape = "true" Env = "stgn" Url = "human-readable-Url-to-cf-distribution" } } |
Далее нужно адаптировать конфигурацию cloudwatch_exporter к снятию метрик ресурсов как раз по этим тегам. Выглядеть она будет примерно так:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
--- delay_seconds: 600 range_seconds: 60 period_seconds: 60 set_timestamp: false metrics: - aws_namespace: AWS/CloudFront aws_metric_name: BytesDownloaded aws_dimensions: [DistributionId,Region] aws_statistics: [Sum] aws_tag_select: tag_selections: Scrape: ["true"] resource_type_selection: "cloudfront:distribution" resource_id_dimension: DistributionId - aws_namespace: AWS/CloudFront aws_metric_name: 5xxErrorRate aws_dimensions: [DistributionId,Region] aws_statistics: [Sum] aws_tag_select: tag_selections: Scrape: ["true"] resource_type_selection: "cloudfront:distribution" resource_id_dimension: DistributionId |
Сам по себе набор лейблов у метрик не изменится, но нужные лейблы появятся у метрики:
|
1 |
aws_resource_info{arn="arn:aws:cloudfront::123456789123:distribution/E2K15KRJXT93A3", distribution_id="E2K15KRJXT93A3", instance="localhost:9106", tag_Scrape="true", tag_Env="stgn", tag_Url="human-readable-Url-to-cf-distribution"} |
Теперь остается делом техники склеить лейблы двух метрик с помощью подобного запроса:
|
1 2 3 |
aws_cloudfront_requests_sum * on(distribution_id) group_left(tag_Url, tag_Scrape) aws_resource_info{tag_Scrape="true"} |
Неудобно, но работает. Хотя на этом нюансы не заканчиваются
Регион
Как известно, в AWS есть множество регионов доступности. Но CloudFront это CDN 2, а значит этот сервис изначально ориентирован на работу по всему миру. В какой регион тогда складывать метрики CloudWatch? В AWS пошли самым нелогичным путем и стали отгружать метрики всегда в US East (N. Virginia) – us-east-1:
To get the CloudFront metrics from the CloudWatch API, you must use the US East (N. Virginia) Region (us-east-1).
Все это ставит нас в затруднительное положение, если мы хотим отправлять в Прометей метрики например RDS, S3 и CloudFront. В этом случае нам нужно поднять два cloudwatch_exporter – один для RDS и S3, а другой для CF. Все потому, что экспортер не позволяет динамически устанавливать регион для каждой метрики.
Кроме того, это накладывает также необходимость постоянно руками переключать регион в веб-интерфейсе.
Выводы
Мониторинг CloudWatch от сервиса к сервису достаточно сильно отличается. Рекордсменом по количеству подводных камней на моей практике как раз является CloudFront. Особенно много неудобств доставляет медленная сходимость данных и в этом случае хотел бы предупредить вас, чтобы вы чаще сравнивали визуально графики на Прометее и в UI CloudWatch.