AWS Observability
https://catalog.us-east-1.prod.workshops.aws/v2/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/intro
Observability от производителя — полный набор воркшопов. Однозначно в закладки.
#observability
https://catalog.us-east-1.prod.workshops.aws/v2/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/intro
Observability от производителя — полный набор воркшопов. Однозначно в закладки.
#observability
Build an observability solution using managed AWS services and the OpenTelemetry standard:
https://aws.amazon.com/blogs/mt/build-an-observability-solution-using-managed-aws-services-and-the-opentelemetry-standard/
▫️
▫️
▫️
▫️
▫️
▫️
#observability
https://aws.amazon.com/blogs/mt/build-an-observability-solution-using-managed-aws-services-and-the-opentelemetry-standard/
We centralized the metrics, traces, and logs collected from workloads running in various AWS accounts using:▫️
ADOT (AWS Distro for OpenTelemetry)▫️
Amazon Managed Grafana▫️
Amazon Managed Service for Prometheus▫️
Amazon OpenSearch Service.To visualize these metrics, traces, logs, and to show correlation, we setup:▫️
OpenSearch dashboard▫️
Grafana workspace with Amazon Managed Grafana.This provided us with a native integration with Amazon Managed Service for Prometheus.We also leveraged a hub-and-spoke architecture for solution scalability.#observability
🔥2👍1
Forwarded from Make. Build. Break. Reflect.
Есть база данных AWS RDS(
К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.
Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".
Большее обсервабилити, большая детализация. Больше SRE👏
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
Мне показался туповатым.
❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.
- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
- создаем новые rds proxy endpoint для каждого из приложений/юзера
- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения
Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.
Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.
Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.
#AWS #observability #cloudwatch
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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍26❤2