Есть база данных AWS RDS(8.0.mysql_aurora.3.08.0) + RDS Proxy.
К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.

Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".

Большее обсервабилити, большая детализация. Больше SRE👏
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и

SELECT usename, count(*) 
FROM pg_stat_activity 
GROUP BY usename;

Мне показался туповатым.

❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.

- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager

resource "aws_db_proxy" "this" {
...
  auth {
    auth_scheme               = "SECRETS"
    iam_auth                  = "DISABLED"
    client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
    secret_arn                = aws_secretsmanager_secret.user1_credentials.arn
  }
  auth {
    auth_scheme               = "SECRETS"
    iam_auth                  = "DISABLED"
    client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
    secret_arn                = aws_secretsmanager_secret.user2_credentials.arn
  }
...
}

- создаем новые rds proxy endpoint для каждого из приложений/юзера

resource "aws_db_proxy_endpoint" "this" {
...
  db_proxy_endpoint_name = "${var.project}-${var.environment}-user1"
  target_role            = "READ_WRITE"
...
}

resource "aws_db_proxy_endpoint" "this" {
...
  db_proxy_endpoint_name = "${var.project}-${var.environment}-user2"
  target_role            = "READ_WRITE"
...
}

- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения

Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint

- ClientConnections 
- DatabaseConnections 
- AvailableConnectionPercent
- ConnectionAttempts
- QueryRequests
- QueryRequestsPerSec

Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.

Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.

Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.

#AWS #observability #cloudwatch

"хей Алекс, у нас закончилась демо версия Backup radar, теперь они хотят денег. Сможешь сделать аналог на AWS? Но денег и часов на задачу на один час. Нам просто надо ежедневно получать уведомления, что у нас успешно создаются бекапы. Сами снепшоты/бекапы создаются".

Ну один час, так один час.
EventBridge в чистом виде неудобен, я дольше буду читать про типы сорсов и полей, занимаясь фильтрацией.

1) Используем популярный модуль ИЛИ пилим те же ресурсы в чистом терраформе.
Выбор каждого.
- пример с модулем

module "aws-backup-notifications" {
  source                   = "terraform-aws-modules/notify-slack/aws"
  version                  = "6.5.1"
  sns_topic_name           = "aws-backup-notifications"
  recreate_missing_package = false
  slack_webhook_url        = data.sops_file.sops_file.data.slack-webhook-aws-backup-notifications.url"]
  slack_channel            = "aws-backup-daily-notifications"
  lambda_function_name     = "aws-backup-notifications"
  slack_username           = "AWS Health Event"
}

- пример без модуля будет нечто типа того (в попытке обезличить мог чушь написать, но на то он и пример).
https://gist.github.com/kruchkov-alexandr/e9139d60658175a5a91c186bd7e0f6b3

Ок теперь у нас есть лямбда, роли, пермишны, SNS топик.
При отправке мессаджа в SNS лямбда отправляет сообщение с метаданными в Slack.

2) Теперь нам надо научиться подписываться на события:

# RDS and DocumentDB cluster snapshot events

resource "aws_db_event_subscription" "db_snapshot_events" {
  name             = "aws-backup-notifications"
  sns_topic        = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
  source_type      = "db-cluster-snapshot"
  event_categories = []
  source_ids       = []
  enabled          = true
}

Если нам надо ещё и по Redis, то в существующих ресурсах добавить

resource "aws_elasticache_replication_group" "this" {
...
  notification_topic_arn = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
...
}

Ок, делаем вручную снепшот, видим мессаджи в Slack - задача выполнена.

4) Так, сообщение от Redis(ElastiCache) короткое и удобно читать в слаке, а вот через лямбду некрасивое и много лишней метаданных, давайте порежем лямбду...

oh wait, а час и закончился, сдаём как есть🤣.

Кому хочется красоты и лаконичности, тот знает прайс.

5) Не забываем напомнить заказчику не мьютить сразу новый слак канал #aws-backup-daily-notifications 😁

#aws

* для этой задачи для этих условий
Плюсы с модулем:
- 18 строчек кода
Минусы с модулем:
- мессадж гигантский, занимает половину экрана

Плюсы без модуля:
- можно сделать лямбду с минимальным мессаджем в слак
Минусы без модуля:
- ну в час не успеть
- много кода, либо пилить свой модуль

Не забывайте, что тут данная подписка на снепшоты кластера, на снепшоты инстансов это не распространяется.

Зачем замазывал event id я не знаю🤣

#aws