CloudWatch + OpenSearch = возможность запрашивать логи из OpenSearch
https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-and-amazon-opensearch-service-launch-an-integrated-analytics-experience/
#CloudWatch #OpenSearch #reInvent
https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-and-amazon-opensearch-service-launch-an-integrated-analytics-experience/
#CloudWatch #OpenSearch #reInvent
👍1💩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
Логи Lambda теперь дешевле
https://aws.amazon.com/blogs/compute/aws-lambda-introduces-tiered-pricing-for-amazon-cloudwatch-logs-and-additional-logging-destinations/
Если у вас их было очень много (терабайты - но зачем?), то экономия существенная.
Возможность слать логи в S3 выглядит привлекательно, но как понимаю, это в довесок к CloudWatch, а не вместо — экономия лишь на хранении (а основной расход - ingestion).
#Lambda #CloudWatch #S3
https://aws.amazon.com/blogs/compute/aws-lambda-introduces-tiered-pricing-for-amazon-cloudwatch-logs-and-additional-logging-destinations/
Если у вас их было очень много (терабайты - но зачем?), то экономия существенная.
Возможность слать логи в S3 выглядит привлекательно, но как понимаю, это в довесок к CloudWatch, а не вместо — экономия лишь на хранении (а основной расход - ingestion).
#Lambda #CloudWatch #S3
Amazon
AWS Lambda introduces tiered pricing for Amazon CloudWatch logs and additional logging destinations | Amazon Web Services
Effective logging is an important part of an observability strategy when building serverless applications using AWS Lambda. Lambda automatically captures and sends logs to Amazon CloudWatch Logs. This allows you to focus on building application logic rather…
🍾2
CloudWatch прокачался:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceMap.html
• Auto-discovers relationships between AWS resources
• Creates interactive topology maps of your entire infrastructure
• Transforms telemetry into actionable insights
• One-click navigation to metrics, logs, and traces
Для того, чтобы видеть и пользоваться всей этой красотой прямо из коробки, требуется включить CloudWatch Application Signals.
P.S. Зачем вам теперь какая-то Grafana или Datadog, когда есть такой похорошевший CloudWatch!
#CloudWatch
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceMap.html
• Auto-discovers relationships between AWS resources
• Creates interactive topology maps of your entire infrastructure
• Transforms telemetry into actionable insights
• One-click navigation to metrics, logs, and traces
Для того, чтобы видеть и пользоваться всей этой красотой прямо из коробки, требуется включить CloudWatch Application Signals.
P.S. Зачем вам теперь какая-то Grafana или Datadog, когда есть такой похорошевший CloudWatch!
#CloudWatch
😁17👍4🔥2🤯2👌2🤡1