Если вы используете в облачных провайдерах managed-инсталляции серверных служб вроде RDS или ElastiCache от AWS, то скорее всего уже задавались темой мониторинга инфраструктуры, а главное — оповещений по произошедшим инцидентам. При реализации возникают понятные вопросы:

1. Как можно настроить сбор данных с endpoint’ов в систему мониторинга?

2. Если использовать Prometheus, то какие экспортеры использовать и где их можно запускать?

3. Какие есть варианты готовых алертов для покрытия основных причин аварий/частичной недоступности?

Эта статья в большей степени рассчитана на начинающих инженеров: на примере Prometheus и CloudWatch мы рассмотрим одно из самых простых и понятных решений с помощью cloudwatch_exporter и prometheus_aws_cost_exporter в AWS, напишем для них Helm-чарт и задеплоим его в Kubernetes. (K8s будет выступать удобной площадкой для разворачивания экспортеров.) А также посмотрим, как можно мониторить текущие и ежедневные затраты всей вашей инфраструктуры.

CloudWatch — сервис для мониторинга инфраструктуры. С его помощью можно настраивать уведомления о произошедших инцидентах по почте, что довольно популярно в проектах, где еще нет централизованной системы мониторинга. Однако мы пойдем по другому пути и будем выводить метрики в формате Prometheus, на основе которых строить графики и настраивать алерты.

У AWS есть отдельные типы инстансов с бюджетами кредитов по CPU и дисков с кредитами по IO. Они позволяют накапливать бюджет кредитов во время сниженной нагрузки и тратить его в том случае, если она резко выросла. Но прогнозировать, когда нагрузка может уйти, проблематично. Поэтому есть риск выработать весь бюджет и перейти на режим ограниченного потребления ресурсов. Данный вариант развития событий сложно диагностировать, так как в мониторинге сервера это напрямую не будет отражено. Поэтому очень полезно мониторить кредиты CPU/IO, чтобы понимать, какое количество кредитов доступно в данный момент, какова динамика их потребления и предвидеть их исчерпание.

Итак, возвращаясь к выбранным инструментам: prometheus_aws_cost_exporter будет использоваться для мониторинга потребления финансов, так как cloudwatch_exporter возвращает информацию только за предыдущий день. Зато cloudwatch_exporter позволяет снимать гораздо больше метрик.

Приступим к непосредственной реализации!

1. Настраиваем IAM

Поскольку рассматривать мы будем два экспортера с немного различным функционалом, потребуются два разных аккаунта в IAM (AWS Identity and Access Management). Ниже представлен список ролей, которые нужны обоим аккаунтам:

• cloudwatch:ListMetrics

• cloudwatch:GetMetricStatistics

• tag:GetResources

Для работы prometheus_aws_cost_exporter требуется больший набор прав: необходимо создать отдельную роль и назначить её пользователю. Для удобства роль можно создать из JSON:

{
  "Effect": "Allow",
  "Action": [
    "cloudwatch:PutMetricData",
    "ec2:DescribeVolumes",
    "ec2:DescribeTags",
    "logs:PutLogEvents",
    "logs:DescribeLogStreams",
    "logs:DescribeLogGroups",
    "logs:CreateLogStream",
    "logs:CreateLogGroup",
    "ce:GetCostAndUsage"
  ],
  "Resource": "*"
},
{
  "Effect": "Allow",
  "Action": [
    "ssm:GetParameter"
  ],
  "Resource": [
    "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*",
    "arn:aws:ce:*:*:/GetCostAndUsage"
  ]
}

Для учётных записей экспортеров также требуется создать access key ID и secret access key, которые будут передаваться в виде переменных (AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY).

2. Создаем IAM-роли через веб-интерфейс

Авторизуемся в консоли управления AWS и перейдем в раздел IAM, где для примера создадим пользователя под названием cloudwatch_users.

В поле Access Type включим опцию Programmatic access, которая позволит сгенерировать упомянутые access key ID и secret access key (они потребуются для работы с API, сохраните их куда-нибудь в надёжное хранилище). Следующая вкладка – Attach existing policies directly, где мы создадим новую политику. Для данной IAM-роли требуются права ListMetrics и GetMetricStatistics.

Если удобнее создавать роль через API, можно воспользоваться JSON-сниппетом:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    }
  ]
}

После нажатия на Review policy указываем название для Policy и создаем её (Create policy). Дальнейшие пункты не влияют на функции созданной роли. Однако потребуется вернуться на этап создания IAM-роли, чтобы добавить созданный нами Policy. На самом последнем этапе станут доступны для просмотра значения для переменных AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY, которые надо записать в values.yaml нашего будущего Helm-чарта.

Если вы используете Terraform, то по данной ссылке есть готовый Terraform receipt для создания IAM-роли и пользователей. Ключи API из terraform.tfstate можно получить с помощью jq:

jq '.resources[].instances[].attributes | {(.id): .secret}'

Примечание: запросы к CloudWatch тарифицируются; актуальные цены можно изучить здесь. Исходя из этой информации можете выбрать, как часто выполнять запросы к API — например, раз в час или в сутки в зависимости от задачи.

3. Helm-чарт для экспортеров

Перейдем к деплою cloudwatch-exporter и cost-exporter в Kubernetes. Потребуется написать очень простой Helm-чарт, который будет состоять из нескольких простых объектов.

В самом начале объявим необходимые переменные в values.yaml:

---
aws_access_key_id: <AWS_ACCESS_KEY_ID>
aws_secret_access_key: <AWS_SECRET_ACCESS_KEY>
region: eu-central-1
replicas:  1
resources:
  requests:
    cpu: 1m
    memory: 512Mi
env:
  metric_today_daily_costs: "yes"
  metric_yesterday_daily_costs: "yes"
  query_period: "1800"
  metric_today_daily_usage: "yes"
  metric_today_daily_usage_norm: "yes"

Подробнее о содержимом этого файла:

• В переменных aws_access_key_id и aws_secret_access_key объявляются значения, полученные при создании IAM-роли;

• region — регион, в котором требуется выполнять мониторинг ресурсов;

• query_period — периодичность запроса метрик из AWS (в секундах);

• metric_today_daily_costs, metric_yesterday_daily_costs, metric_today_daily_usage, metric_today_daily_usage_norm — включение/выключение запрашивания метрик затрат (costs) и потребления (usage) за вчера и за сегодня (по умолчанию имеет значение no);

• Параметры из блока env используются cost-exporter’ом (на работу cloudwatch-exporter не влияют).

Ниже — пример листинга с Deployment для cloudwatch-exporter, который носит иллюстративный характер (содержит только основную структуру для удобства чтения). Полная версия доступна здесь.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloudwatch-exporter
spec:
  selector:
    matchLabels:
      app: cloudwatch-exporter
  template:
    metadata:
      labels:
        app: cloudwatch-exporter
    spec:
      containers:
      - name: cloudwatch-exporter
        image: prom/cloudwatch-exporter:cloudwatch_exporter-0.9.0
        env:
        - name: AWS_ACCESS_KEY_ID
          value: "{{ .Values.aws_access_key_id }}"
        - name: AWS_SECRET_ACCESS_KEY
          value: "{{ .Values.aws_secret_access_key }}"
        volumeMounts:
        - name: config
          subPath: config.yml
          mountPath: /config/config.yml
      volumes:
      - name: config
        configMap:
          name: config

Следующий Deployment (точнее, снова его фрагмент) — для cost-exporter:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cost-exporter
spec:
  selector:
    matchLabels:
      app: cost-exporter
  template:
    metadata:
      labels:
        app: cost-exporter
    spec:
      containers:
      - name: cost-exporter
        image: nachomillangarcia/prometheus_aws_cost_exporter:latest
        args:
        - --host
        - 0.0.0.0
        env:
        - name: AWS_ACCESS_KEY_ID
          value: "{{ .Values.aws_access_key_id }}"
        - name: AWS_SECRET_ACCESS_KEY
          value: "{{ .Values.aws_secret_access_key }}"
        - name: METRIC_TODAY_DAILY_COSTS
          value: "{{ .Values.env.metric_today_daily_costs }}"
        - name: METRIC_YESTERDAY_DAILY_COSTS
          value: "{{ .Values.env.metric_yesterday_daily_costs }}"
        - name: QUERY_PERIOD
          value: "{{ .Values.env.query_period }}"
        - name: METRIC_TODAY_DAILY_USAGE
          value: "{{ .Values.env.metric_today_daily_usage }}"
        - name: METRIC_TODAY_DAILY_USAGE_NORM
          value: "{{ .Values.env.metric_today_daily_usage_norm }}"

4. Настраиваем метрики для мониторинга

Остается настроить самое главное — те метрики, которые будут собираться в Prometheus и на основании значений которых мы хотим делать алерты.

Здесь есть пример конфигурационного файла для cloudwatch_exporter с перечислением необходимых для мониторинга метрик.Посмотреть все доступные для мониторинга метрики — например, для EC2 — можно с помощью консольной утилиты aws:

aws cloudwatch list-metrics --namespace EC2

Все параметры конфига берутся из вывода консольной утилиты aws. Типичный фрагмент конфига:

  - aws_namespace: AWS/NetworkELB
    aws_metric_name: HealthyHostCount
    aws_dimensions:
    - LoadBalancer
    - TargetGroup
    aws_statistics:
    - Sum
    period_seconds: 60

Этот фрагмент указывает экспортеру брать из AWS/NetworkELB метрику HealthyHostCount с периодичностью 60 секунд, агрегировать её по LoadBalancer и TargetGroup, выдавать значение Sum.

Бонус! Несколько примеров алертов

Вот так выглядит алерт на использование CPU в Redis у ElastiCache:

  - alert: RedisCPUUsage
    annotations:
    description: |
      Redis CPU utilization on {{`{{$labels.cache_cluster_id}}`}} in cluster is over than 60%
    summary: Redis CPU utilization on {{`{{$labels.cache_cluster_id}}`}} in cluster is over than 60%
    expr: |
      aws_elasticache_cpuutilization_average >= 60
    for: 5m

Алерт на количество target у LoadBalancer:

  - alert: LBTargetGroupIsUnhealthy
    annotations:
    description: Some hosts are target group {{`{{$labels.target_group}}`}} in cluster is unhealthy!
    summary: Some hosts are target group {{`{{$labels.target_group}}`}} in cluster is unhealthy!
    expr: |
      aws_networkelb_healthy_host_count_sum{load_balancer=~".*someservice.*",target_group=~".*someservice.*"} < 3
    for: 1m

Алерт на исчерпание EBS Burst balance:

  - alert: EBSBurst_balance
    annotations:     
    description: EBS Burst balance in cluster is less than 60%                 
    summary: EBS Burst balance in cluster is less than 60%
    expr: |
      aws_ebs_burst_balance_average <= 60         
    for: 5m

В репозитории представлен более обширный список примеров для конфигурации метрик и алертов.

Примеры, как могут выглядеть графики в Prometheus:

Заключение

В статье рассмотрен мониторинг сервисов AWS с помощью известных Prometheus exporter’ов. Настроив его описанным образом, можно получить удобный инструмент для анализа состояния managed-инфраструктуры и ее стоимости, что поможет скорректировать расходы и вовремя получать информацию о потребляемых финансовых ресурсах.

За рамками материала остались некоторые вопросы взаимодействия с Prometheus (как ему сообщать, откуда и куда scrape’ить метрики), а также создание панелей в Grafana. (Кстати, для prometheus_aws_cost_exporter есть dashboard от создателя.) Разобравшись и с ними для своего конкретного случая, можно получить более полное, законченное решение.

P.S.

Читайте также в нашем блоге:

• «Мониторинг и Kubernetes» (обзор и видео доклада);

• «Будущее Prometheus и экосистемы проекта (2020)»;

• «Устройство и механизм работы Prometheus Operator в Kubernetes».