​​AMP — Amazon Managed Prometheus!

https://aws.amazon.com/blogs/aws/join-the-preview-amazon-managed-service-for-prometheus-amp/

На текущий момент поддерживаются лишь ECS, EKS или свой собственный Kubernetes кластер (в том числе on-prem).

В любом случае, теперь стандартный стэк Prometheus+Grafana = AMP+AMG = полный комплект!

#AMP

Настройка Amazon Managed Prometheus (AMP) для EKS

Prometheus как сервис появился на AWS в самом конце 2020-го года. На момент написания поста он всё ещё в открытом превью, означающее, что он спокойно доступен в консоли (в отличие от Amazon Managed Grafana, для доступа к которой нужно писать челобитную).

Материалов по AMP не так много. Основные на сейчас это:

Анонс AMP:
🔹 Getting Started with Amazon Managed Service for Prometheus
🎥 AWS re:Invent 2020: Introducing Amazon Managed Service for Prometheus (AMP)

Настройка AMP в cross-acount варианте (когда AMP в другом AWS аккаунте по отношению к окружению, с которого снимаются метрики):
🔹 Setting up cross-account ingestion into Amazon Managed Service for Prometheus

Даже если просто полистать ссылки, то настораживает обилие баша в процессе настройки, что если и поможет, то лишь в повторении демки создания с нуля VPC+EKS сотоварищи, но не особо годится для интеграции в собственные решения.

Документация в сложных моментах содержит те же простыни баша (всё на текущий момент, очень надеюсь, что после это изменится):
🔹 Set up IAM roles for service accounts

Основные моменты AMP + EKS:
▪️ метрики из EKS шлются в AMP (активный режим)
▪️ AMP может быть в то том же или другом аккаунте/регионе
(дополнительные расходы на трафик, если в другом аккаунте/регионе)
▪️ метрики должны быть авторизованы IAM, для чего вместе с Prometheus-сервером водружается sidecar-контейнером IAM-прокси
▪️ для безопасности, чтобы не отправлять метрики через интернет, можно использовать VPC endpoints

Для реализации в EKS потребуется настроить IAM roles for service accounts (если они ещё не были настроены).

⚠️ Отдельно обращу внимание, чтобы во избежание проблем настраивать всё лучше с последними версиями AWS CLI и eksctl.

Главный сложный момент возникает с ролью (в статьях это EKS-AMP-ServiceAccount-Role), в которую переключается сервисный аккаунт для отсылки метрик. У неё весьма сложная структура с хитрыми Conditions. Как раз во многом из-за неё понаписаны простыни баша.

Вместо баша для объяснения особенностей создания этой роли приведу рабочий пример кода на CloudFormation:

AssumeRolePolicyDocument: !Sub
 - |
  {
   "Version": "2012-10-17",
   "Statement": [
    {
     "Effect": "Allow",
     "Principal": {
      "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}"
     },
     "Action": "sts:AssumeRoleWithWebIdentity",
     "Condition": {
      "StringEquals": {
       "oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}:sub": "system:serviceaccount:${NameSpace}:${ServiceAccount}"
      }
     }
    }
   ]
  }
 - Id:       !Ref OidcProviderId
  Namespace:   !Ref KuberNamespace
  ServiceAccount: !Ref ServiceAccountName

👉 Это лишь фрагмент, полный код в репозитории.

Переменные, которые участвуют в создании роли:
• Id - EKS Cluster OIDC Provider ID, в данном случае лишь его численная часть (без https и др. элементов)
• Namespace - это --namespace, в котором находится Prometheus сервер в EKS кластере
• ServiceAccount - имя сервисного аккаунта Prometheus сервера

Стоит обратить внимание, что в yaml-коде выше используется вкрапление json. Это потому, что в Conditions в качестве ключа нужно передать переменную "oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}:sub", что невозможно сделать в yaml.

Вариант выше для случаев, когда роль создаётся "сбоку", когда ей передаётся OIDC ID. Однако это значение ID такое же и для EKS API server endpoint, которое можено получить при создании кластера и тогда создание данной роли можно делать прямо при создании EKS кластера.

- Id: !Select [0, !Split ['.', !Select [1, !Split ['://', !GetAtt eksCluster.Endpoint]]]]

👉 пример фрагмента для EKS репозитории.

От EKS кластера получаем айдишник вида, https://1CF1A05E85DFDB5D489942FCC82AD99E.gr7.eu-west-1.eks.amazonaws.com, которому первым селектом (по "баяну" '://') отсекаем https://, а потом берём всё до первой точки. На выходе получаем то же значение, что и для OpenID!

#AMP

Кому прилетел негуманный прайс за Amazon Managed Prometheus, есть хорошие новости — с 4 мая цены резко снижены (до шести раз на больших объёмах):

https://aws.amazon.com/about-aws/whats-new/2021/05/aws-announces-a-price-reduction-for-amazon-managed-service-for-prometheus-amp/

Также предположу, что после окончания месяца пересчитают и предыдущий период.

#AMP

​​Мониторинг Lambda в AMP (Amazon Managed Service for Prometheus) с помощью ADOT (AWS Distro for OpenTelemetry):

https://aws.amazon.com/blogs/opensource/aws-lambda-metrics-support-for-amazon-managed-service-for-prometheus-now-available-in-aws-distro-for-opentelemetry/

To support generating, collecting, and exporting application metrics from AWS Lambda to Prometheus, we extended the OpenTelemetry Lambda layer to ensure end-to-end support for the metric pipeline. In addition to supporting Prometheus, a separate layer is also able to support exporting metrics to Amazon Managed Service for Prometheus (AMP).

#Lambda #AMP #ADOT #OpenTelemetry