Есть база данных 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

Опять observability.

Признаюсь, за весь свой опыт работы с алёртингом я больше тратил время не на технические задачи.
Сделать сбор метрик, отсеять лишние, повесить алёрты и создать каналы слака/телеграма, забив их людьми и повесив дежурство это на самом деле не сложно.
Не сложно и напилить борды в графане и сделать линк до инцидента в самом алёрте.
Технические задачи решаются легче всего.

Самое сложное сперва было
- разобраться с severity levels
- сделать порядок (флоу?rule?) куда чего и как будет идти
- понять кто за что ответственен

Вот допустим мы говорим строго про инженеров платформы/инфраструктуры.
Чего мы хотим видеть в северити:
- info - информативные сообщения, которые скорее всего будут добавлены в канал оповещения с mute и лезть мы туда будем постфактум "а чо было". Например что джоба в кубере выполнялась больше 25 минут.
- warning - предупреждения, что скоро будет не ок. Например 80% заполнения диска на критикал инфре. Пока не проблема, но может стать проблемой в будущем.
- critical - ну тут понятно. Кластер упал, место закончилось, бизнес аппликейшн последние 3 минуты выдает 502 ошибки и всё легло.
Никаких вопросов тут не вызывало никогда у меня, ни развесить северити, ни определиться с каналом оповещения.

А что делать со сторонними сервисами?
Мы так много говорим про девопс, но не можем самим себе ответить на простые вопросы.
Например ArgoCD.
Куда отправлять алёрты такого плана?

argocd_app_info{health_status!="Healthy"} != 0
argocd_app_info{sync_status!="Synced"} != 0

Девелоперам? Инженерам инфры? А если не прод, а demo/UAT кластер?
Нужно ли это смотреть девопсам?
В общий канал про прод критикал инциденты или отдельный для арго?
Если для арго, то один общий на все енвы или под каждый стенд/енв/проект?

Ладно, допустим арго не самая сложная штука.
Мы мониторим Azure Enterprise application (+service principle credentials expire).
Вот в аппликейшн не заходили полгода. Куда писать, чтобы удалить эту неиспользуемую? Это ворнинг или инфо?
Если креды протухнут скоро кому писать? Опсы и девопсы вообще не в курсе что это за креды и где они могут использоваться.

Airflow. Упал DAG.
опять кому писать? о чем?
То, что там нет метода это не важно опсам, но нужно QA.
А если DAG упал, потому что на нодах, где запускаются воркеры нет ресурсов, то это уже инфровая часть.
Как их разделять если там нет привычного label фильтрации.
Нужно ли знать о том, что в проде упал даг или это простая фигня не важная?

Усложняем задачи.
У нас есть базы данных и deadlock. Кому писать?
А дедлок по факту свершения или есть их +5 за последние 5 минут?
Это критикал или ворнинг?

Ладно, trino. На UAT долго повис запрос и сожрал всю память, а остальные 56 запросов висят в очереди час.
(кстати это аффектит и Airflow и всё ETL)
Кому об этом писать и как?


Наверное пора прийти к какому-то шаблону для тех, кто приходит с новым алёртом.
Думаю о варианте типа:
- автор алёрта(команда/человек)
- expr/metric+threashold
- какой severity алёрта
- в какой канал уведомлять(почта/слак/телеграм/голуби)
- правило, если каналов несколько
Нет этой информации - нет и алёрта.
Эх, мечты мечты, придут ко мне срочно и всё равно и без заявки и без ответственного лупану алёрт в общий канал.🤣

То есть большую часть занимают размышление и правильный флоу, чем написание кода и конфигов.

Основная же стратегия пока примерно такая:
- у каждого алёрта есть обязательный severity, который назначается при создании алёрта
например

- alert: JobFailed
  expr: kube_job_status_failed{} > 0
  labels:
    severity: info

- на всех метриках мы используем лейбл cluster(если он есть), либо обогащаем этим лейблом, если это не в кубере(например виртуальная машина)
- а затем через rules мы роутим в нужные каналы уведомлений согласно типа алёрта/кластера/имени алёрта/аутедж и так далее
- пример отобразил на графике

Это не финальный результат, наверняка буду менять не единожды, но это уже работает и большинство коллег устраивает.

#observability #alertmanager