#aws #costoptimization #devops
А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.
Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.
Всё вышенаписанное лишь для того, чтобы подчеркнуть, что ничего нестандартного тут не было, всё как у всех.
Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.
Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг
Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.
Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.
Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.
Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.
В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.
Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.
А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.
Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.
Всё вышенаписанное лишь для того, чтобы подчеркнуть, что ничего нестандартного тут не было, всё как у всех.
Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.
Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг
Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.
Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.
Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.
Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.
В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.
Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.
👍9
#aws #costoptimization #devops
Затем я включил логирование (Standard log destinations) и положил все логи в S3 бакет.
Оставил на полдня, потом написал Bash-скрипт, который сделал простую выборку, например, top 20 requests by path с сортировкой по пути.
Тут меня ждало очередное удивление - в топе были не файлы S3, а балансировщик нагрузки (ALB) и поды Kubernetes🤡 .
То есть, у нас топ трафика - это НЕ кэшируемый трафик!🤬 Через клаудфронт! 🤬
Написал еще пару скриптов - да, у нас внезапно в этой схеме просто трафик шел в EKS и пару мест.
Собрали консилиум с коллегами, рассказал о своей, находке, чтобы спросить "а зачем так?".
Ответ был очевидным типа "ну так было исторически, нам надо было как-то роутить трафик по пути, мы в своё время сделали это через клаудфронт, чтобы не поднимать ещё один балансер или Nginx".
"Пздц" - подумал я и пошёл дальше изучать.
Да, действительно так и оказалось - часть трафика, и это 98% от всего в клаудфронте, шло НЕ для кеша.
Просто в поды кубернетиса.
Быстро напилил альтернативное решение, пару днс записей, проверили на dev - всё работает ок, без клаудфронта.
Дальше стейдж, прод, никаких проблем.
Сижу пишу
Понимаю, что надо сослаться на саппорт амазона, типа они негодяи не присылали кост аномали детекшн письма - но нет, присылали.
Думаю может не было реакции - нет, обсуждали повышения цен, даже текстов в чате.
Как так мы пропустили этот момент?
Подняли исторически все данные и за последние пару лет и только тогда картина полностью стала ясна.
- Изначально был временный костыль в одном из клаудфронтов - если путь /path1 то трафик отправлять в X, а если /-path2, то временно в Y.
- этого трафика была изначально мало и он вовсе попадал во free tier.
- затем его стало больше, стали платить 40 баксов, что было допустимо, затем 80 и так далее.
- пока не вырос до 1000 и 1250 долларов на момент кост инцидента.
Почему не обращали внимание раньше?
Потому что рост цены был медленным:
- кост аномали детекшн ловил рост цены примерно раз в неделю, и сумма каждый раз была небольшая
При постоянном медленном росте кост аномали детекшн начал отправлять всё реже и реже письма - это же очевидное поведение стало.
- все дефолт ссылки ведут на "cost and usage report" с коротким промежутком времени типа последние 30-40 дней
- на графиках и в письмах был небольшой рост - ну кто будет заниматься, если на прошлой недели мы платили 9 баксов день, а теперь 11 долларов в день, копейки же
Лишь взглянув на графики за полгода/год/два года/три года, стало ясно, что цена увеличивались постоянно.
Временный костыль начал в итоге вырабатывать 14 терабайт данных трафика.
Косяк девопса? Да.
Косяк костменеджера? Несомненно.
Косяк "временного решения"? Конечно.
Иногда, чтобы узнать, что проблема есть, надо нырнуть чуть глубже, чем "да вроде по делу списывают да не много же".
Иногда, чтобы узнать, что проблема есть, надо расширить графики больше, чем на две недели.
Суммарные потери последних 8 месяцев до этого кост инцидента - 4400 долларов.
Этот path в клаудфронте и не нужен был, просто поленились много лет назад сделать сразу нормально.
Затем я включил логирование (Standard log destinations) и положил все логи в S3 бакет.
Оставил на полдня, потом написал Bash-скрипт, который сделал простую выборку, например, top 20 requests by path с сортировкой по пути.
Тут меня ждало очередное удивление - в топе были не файлы S3, а балансировщик нагрузки (ALB) и поды Kubernetes
То есть, у нас топ трафика - это НЕ кэшируемый трафик!
Написал еще пару скриптов - да, у нас внезапно в этой схеме просто трафик шел в EKS и пару мест.
Собрали консилиум с коллегами, рассказал о своей, находке, чтобы спросить "а зачем так?".
Ответ был очевидным типа "ну так было исторически, нам надо было как-то роутить трафик по пути, мы в своё время сделали это через клаудфронт, чтобы не поднимать ещё один балансер или Nginx".
"Пздц" - подумал я и пошёл дальше изучать.
Да, действительно так и оказалось - часть трафика, и это 98% от всего в клаудфронте, шло НЕ для кеша.
Просто в поды кубернетиса.
Быстро напилил альтернативное решение, пару днс записей, проверили на dev - всё работает ок, без клаудфронта.
Дальше стейдж, прод, никаких проблем.
Сижу пишу
postmortem.Понимаю, что надо сослаться на саппорт амазона, типа они негодяи не присылали кост аномали детекшн письма - но нет, присылали.
Думаю может не было реакции - нет, обсуждали повышения цен, даже текстов в чате.
Как так мы пропустили этот момент?
Подняли исторически все данные и за последние пару лет и только тогда картина полностью стала ясна.
- Изначально был временный костыль в одном из клаудфронтов - если путь /path1 то трафик отправлять в X, а если /-path2, то временно в Y.
- этого трафика была изначально мало и он вовсе попадал во free tier.
- затем его стало больше, стали платить 40 баксов, что было допустимо, затем 80 и так далее.
- пока не вырос до 1000 и 1250 долларов на момент кост инцидента.
Почему не обращали внимание раньше?
Потому что рост цены был медленным:
- кост аномали детекшн ловил рост цены примерно раз в неделю, и сумма каждый раз была небольшая
При постоянном медленном росте кост аномали детекшн начал отправлять всё реже и реже письма - это же очевидное поведение стало.
- все дефолт ссылки ведут на "cost and usage report" с коротким промежутком времени типа последние 30-40 дней
- на графиках и в письмах был небольшой рост - ну кто будет заниматься, если на прошлой недели мы платили 9 баксов день, а теперь 11 долларов в день, копейки же
Лишь взглянув на графики за полгода/год/два года/три года, стало ясно, что цена увеличивались постоянно.
Временный костыль начал в итоге вырабатывать 14 терабайт данных трафика.
Косяк девопса? Да.
Косяк костменеджера? Несомненно.
Косяк "временного решения"? Конечно.
Иногда, чтобы узнать, что проблема есть, надо нырнуть чуть глубже, чем "да вроде по делу списывают да не много же".
Иногда, чтобы узнать, что проблема есть, надо расширить графики больше, чем на две недели.
Суммарные потери последних 8 месяцев до этого кост инцидента - 4400 долларов.
Этот path в клаудфронте и не нужен был, просто поленились много лет назад сделать сразу нормально.
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡13👏3😢2❤1👍1
#aws #eks #kubernetes #troubleshooting #одинденьизжизни #argocd
"Алекс, у нас что-то приложение не раскатывается, деплой завис. Кластер новый, вроде ты деплоил, посмотри плиз".
Ну раз я, значит мне и смотреть.
Смотрю в арго что там зависло, перехожу в аппликейшнсет - вижу процессинг.
Processing, что же ты за зверь такой?
Это означает, что ArgoCD обнаружил разницу между желаемым состоянием (в гите) и текущим состоянием (в кластере) и активно пытается синхронизировать ресурсы.
Есть проблема, которая мешает завершить развертывание (например, нехватка ресурсов, неправильная конфигурация, ожидание завершения работы пода или борьба между контроллерами).
На самом деле самый дебильный статус, потому что в практике это может быть что угодно🐒 .
Ладно, надо чинить.
Смотрю сперва "а не может ли кто сражаться за ресурсы?"
Вдруг опять арго и оператор вцепились как два деда.
Я как-то выше писал старый пример про #dapr.
Смотрю:
А тут всё нормально:
- helm один раз создал/обновил сам ApplicationSet
- argocd-applicationset-controller дальше управляет этим ApplicationSet и генерит Application(ы)
Значит дело не в конфликте.
Иду дальше, что с самим аппликейшн
И нет ли там конфликтов
Конфликтов нет, ведь:
- argocd-applicationset-controller следит за соответствием шаблону ApplicationSet.
Он не ходит в кластерные ресурсы (Deployment, Service и т.д.), только создаёт/обновляет/удаляет сами Application CR.
- argocd-application-controller следит за тем, чтобы ресурсы в кластере совпадали с Git, и считает health (если хоть один дочерний ресурс не равен Healthy, приложение остаётся Progressing).
Идём дальше. Так какие же ресурсы генерируются и какой у них статус?
Ага! Попался!
Какой-то
Что там с тобой:
Визуально вроде ок,
Стоп, нет,не ок.
Ведь это означает, что контроллер, отвечающий за provision (создание) AWS Load Balancer, не смог выполнить свою работу, и поэтому поле status.loadBalancer.ingress не заполнено IP-адресом или Hostname.
* У нас LoadBalancer создаётся контроллером AWS.
Ещё раз проверяю в дескрайб:
Ладно, иду в неймспейс, где обычно лежит AWS Load Balancer, логи смотреть.
А там нет ничего! Удивляюсь, смотрю
Нет ничего!
Спрашиваю коллег, а мне ехидно говорят "да ты же сам не задеплоил лоадбалансер в этом новом кластере".
https://github.com/kubernetes-sigs/aws-load-balancer-controller
Смотрю свои коммиты, MR - и правда, именно в этом кластере я забыл добавить AWS LB.🐒
Пилю новый MR, добавляю LB, жду, когда всё поднимется - всё, проблема решена!
У проблемного
Добавляю в документацию по кластеру, что "не забыть про LB и иду работать дальше".
Ну хорошо, хоть это не продуктовый кластер, без клиентского ворклоада🤡
"Алекс, у нас что-то приложение не раскатывается, деплой завис. Кластер новый, вроде ты деплоил, посмотри плиз".
Ну раз я, значит мне и смотреть.
Смотрю в арго что там зависло, перехожу в аппликейшнсет - вижу процессинг.
Processing, что же ты за зверь такой?
Это означает, что ArgoCD обнаружил разницу между желаемым состоянием (в гите) и текущим состоянием (в кластере) и активно пытается синхронизировать ресурсы.
Есть проблема, которая мешает завершить развертывание (например, нехватка ресурсов, неправильная конфигурация, ожидание завершения работы пода или борьба между контроллерами).
На самом деле самый дебильный статус, потому что в практике это может быть что угодно
Ладно, надо чинить.
Смотрю сперва "а не может ли кто сражаться за ресурсы?"
Вдруг опять арго и оператор вцепились как два деда.
Я как-то выше писал старый пример про #dapr.
Смотрю:
kubectl get applicationsets APPSET1 \
-n NAMESPACE \
-o jsonpath='{.metadata.managedFields[*].manager}' \
| tr ' ' '\n' | sort | uniq -c
1 argocd-applicationset-controller
1 helm
А тут всё нормально:
- helm один раз создал/обновил сам ApplicationSet
- argocd-applicationset-controller дальше управляет этим ApplicationSet и генерит Application(ы)
Значит дело не в конфликте.
Иду дальше, что с самим аппликейшн
kubectl get applications -n NAMESPACE \
-o wide | grep APP1
APP1 Synced Progressing
И нет ли там конфликтов
kubectl get applications APP1 -n NAMESPACE \
-o jsonpath='{.metadata.managedFields[*].manager}' \
| tr ' ' '\n' | sort | uniq -c
1 argocd-application-controller
1 argocd-applicationset-controller
Конфликтов нет, ведь:
- argocd-applicationset-controller следит за соответствием шаблону ApplicationSet.
Он не ходит в кластерные ресурсы (Deployment, Service и т.д.), только создаёт/обновляет/удаляет сами Application CR.
- argocd-application-controller следит за тем, чтобы ресурсы в кластере совпадали с Git, и считает health (если хоть один дочерний ресурс не равен Healthy, приложение остаётся Progressing).
Идём дальше. Так какие же ресурсы генерируются и какой у них статус?
kubectl get applications APP1 -n NAMESPACE -o json \
| jq '.status.resources[] | select(.health.status != "Healthy")'
...
{
"kind": "ConfigMap",
"name": "CM1",
"namespace": "NAMESPACE",
"status": "Synced",
"version": "v1"
}
...
{
"health": {
"status": "Progressing"
},
"kind": "Service",
"name": "SVC1",
"namespace": "NAMESPACE",
"status": "Synced",
"version": "v1"
}
...
Ага! Попался!
Какой-то
service в процессинге.Что там с тобой:
kubectl get service SVC1 -o yaml -n NAMESPACE
...
type: LoadBalancer
status:
loadBalancer: {}
Визуально вроде ок,
Стоп, нет,не ок.
Ведь это означает, что контроллер, отвечающий за provision (создание) AWS Load Balancer, не смог выполнить свою работу, и поэтому поле status.loadBalancer.ingress не заполнено IP-адресом или Hostname.
* У нас LoadBalancer создаётся контроллером AWS.
Ещё раз проверяю в дескрайб:
kubectl describe service SVC1 -n NAMESPACE
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal EnsuringLoadBalancer 55m ***** Ensuring load balancer
Ладно, иду в неймспейс, где обычно лежит AWS Load Balancer, логи смотреть.
А там нет ничего! Удивляюсь, смотрю
kubectl get pods -A | grep -i load
Нет ничего!
Спрашиваю коллег, а мне ехидно говорят "да ты же сам не задеплоил лоадбалансер в этом новом кластере".
https://github.com/kubernetes-sigs/aws-load-balancer-controller
Смотрю свои коммиты, MR - и правда, именно в этом кластере я забыл добавить AWS LB.
Пилю новый MR, добавляю LB, жду, когда всё поднимется - всё, проблема решена!
У проблемного
applicationsset статус стал Healthy.Добавляю в документацию по кластеру, что "не забыть про LB и иду работать дальше".
Ну хорошо, хоть это не продуктовый кластер, без клиентского ворклоада
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18
#пятница
Мои прогнозы на re:Invent 2025:
- AI
- GenAI
- MCP agents
- Agentic AI
- Generative AI Workflows
- Serverless-VPC-in-a-Container
Никто не знает, зачем, но звучит очень глубоко.
- Zero-ETL-to-Zero-Code
- The Data Lake House Lakehouse Warehouse Mesh Fabric
Просто потому, что
- The Multi-Region-Multi-AZ-Multi-Cloud-Multi-Everything-Architecture
Зарезервировано 100% времени работы, но 1000% затрат.
- AI
Ну, а вдруг вы забыли?
Мои прогнозы на re:Invent 2025:
- AI
- GenAI
- MCP agents
- Agentic AI
- Generative AI Workflows
- Serverless-VPC-in-a-Container
Никто не знает, зачем, но звучит очень глубоко.
- Zero-ETL-to-Zero-Code
- The Data Lake House Lakehouse Warehouse Mesh Fabric
Просто потому, что
Data Mesh уже недостаточно сложно.- The Multi-Region-Multi-AZ-Multi-Cloud-Multi-Everything-Architecture
Зарезервировано 100% времени работы, но 1000% затрат.
- AI
Ну, а вдруг вы забыли?
😁17
#linux
В эпоху активного использования AI, агентов и автокомплитов я стал чаще допускать ошибки.
Чёртовы AI не глядя могут дропнуть нужные файлы:херак раз - и нет важного файла.
С git‑файлами особых опасений нет, но дополнительные вещи вроде
Возвращаюсь к основам и просто запрещаю удаление файла:
Проверить, что флаг установлен, можно так:
Если я сам (а не нейронка) когда‑нибудь захочу удалить файл, сначала придётся снять флаг, а уже потом удалять:
Флаг immutable защищает от:
- перезаписи файла
- случайного удаления
- случайного переименования
- случайного sudo rm -r по директории, где лежит этот файл*
* Будет ошибка типа Operation not permitted на файле, в то время как остальные файлы в директории будут удалены
Если immutable поставить на саму директорию через
Иногда очень полезно вернуться к базовым инструментам Linux и защитить важные файлы и от нейросетей, и от себя самого, который запускает команды, не глядя, как макака.
В эпоху активного использования AI, агентов и автокомплитов я стал чаще допускать ошибки.
Чёртовы AI не глядя могут дропнуть нужные файлы:
С git‑файлами особых опасений нет, но дополнительные вещи вроде
.env в репозитории, которые в гитигноре, или в системе типа ~/.kube/config всё ещё хочется сохранить.Возвращаюсь к основам и просто запрещаю удаление файла:
sudo chattr +i .env
Проверить, что флаг установлен, можно так:
lsattr .env
Если я сам (а не нейронка) когда‑нибудь захочу удалить файл, сначала придётся снять флаг, а уже потом удалять:
sudo chattr -i .env
sudo rm .env
Флаг immutable защищает от:
- перезаписи файла
- случайного удаления
- случайного переименования
- случайного sudo rm -r по директории, где лежит этот файл*
* Будет ошибка типа Operation not permitted на файле, в то время как остальные файлы в директории будут удалены
Если immutable поставить на саму директорию через
chattr +i dir, тогда уже нельзя будет ни создавать, ни удалять, ни переименовывать файлы внутри неё - это ещё более жёсткая защита, но это мне пока не надо.Иногда очень полезно вернуться к базовым инструментам Linux и защитить важные файлы и от нейросетей, и от себя самого, который запускает команды, не глядя, как макака.
👍17🙈6🙉4🙊4
Please open Telegram to view this post
VIEW IN TELEGRAM
😁18💯3🤡1🤣1
#eks #aks #kubernetes
Апгрейд кластера кубернетис.
С чего начинать?
Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes
У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/
В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster
У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster
Это всё облачные куберы и их вендорлок решения.
Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova
Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.
Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.
Апгрейд кластера кубернетис.
С чего начинать?
Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes
У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/
В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster
У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster
Это всё облачные куберы и их вендорлок решения.
Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova
Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.
Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.
43👍16🥰2🙏1
#бытовое
Пауербанк делает бррр вбдыщ вжуу.
Самое время, перед новым годом, принудительно избавится от старых и любимых пауербанков.
Даже если не хочется. Надо, пришла пора, иначе будет как у меня.
Хорошо, что обошлось без травм и пожара😭
Пауербанк делает бррр вбдыщ вжуу.
Самое время, перед новым годом, принудительно избавится от старых и любимых пауербанков.
Даже если не хочется. Надо, пришла пора, иначе будет как у меня.
Хорошо, что обошлось без травм и пожара
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🤯11
#costoptimization #newrelic
И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"
"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".
Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц
Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим
Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing
Да, всё так и есть, лицензии и трафик.
Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.
https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.
Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.
На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу
- топ ивентов
- топ метрик
Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.
Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее
В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:
Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.
Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование
- в golang, например
+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.
Что же я сделал? Я уменьшил количество семплов в минуту.
Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.
Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.
И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"
"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".
Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц
Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим
Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing
Да, всё так и есть, лицензии и трафик.
Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.
Ingestion. Из чего ты состоишь? https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.
Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.
На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу
SELECT bytecountestimate()/10e8 FROM `Span`, `SpanEvent` WHERE instrumentation.provider != 'pixie' FACET appName OR service.name OR entity.name LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp
- топ ивентов
SELECT bytecountestimate()/10e8 FROM `Transaction`, `TransactionError` FACET appName LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp
- топ метрик
SELECT bytecountestimate()/10e8 FROM `Metric` WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie' FACET CASES (WHERE newrelic.source = 'agent' AS 'Metric Time Slices', WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics') SINCE unixtimestamp UNTIL unixtimestamp
Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.
Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее
В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:
newrelic выезжает на дефолтах
Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.
Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование
newrelic.span_events.max_samples_stored = 200 # was 2000
- в golang, например
NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED=200 # was 1000 (default)
NEW_RELIC_TRANSACTION_EVENTS_MAX_SAMPLES_STORED=2000 # was 10000 (default)
NEW_RELIC_APPLICATION_LOGGING_FORWARDING_ENABLED=false # was true (default)
+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.
Что же я сделал? Я уменьшил количество семплов в минуту.
Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.
Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.
11👍3
#costoptimization #newrelic
Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.
В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/
Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами
Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.
Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.
В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/
Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами
Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.
2👍16❤2
#kubernetes #devops
Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro
Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.
Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.
Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.
Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.
Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro
Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.
Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.
Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.
Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.
👍15❤1👏1
Работа работа работа.
Я так и не успел в суете работы купить оперативную память до всего этого хайпа и уж тем более нехватки оперативной памяти на рынке.
Теперь то, что я хочу, даже в наличии нет. Или под заказ на март. Возможно.
Ладно, буду, как и раньше со старым ПК от 2021 года ещё лет 10.😭
Я так и не успел в суете работы купить оперативную память до всего этого хайпа и уж тем более нехватки оперативной памяти на рынке.
Теперь то, что я хочу, даже в наличии нет. Или под заказ на март. Возможно.
Ладно, буду, как и раньше со старым ПК от 2021 года ещё лет 10.
Please open Telegram to view this post
VIEW IN TELEGRAM
😭10🔥2
Вот так незаметно и тихо прошёл год с основания моего авторского телеграм канала. Поздравляю сам себя и всех, кому это интересно читать.
1❤41👍8🎉7🔥4
Приветствую всех.
Поскольку все читатели здесь ради контента, а не моей биографии, сразу перейду к сути.
Этот блог - мои заметки на полях.
Почти не делаю репосты, пишу для души и лишь когда на это есть время/желание.
Обычно это 2-4 поста в неделю.
В основном делюсь:
- информацией, которую узнал только что (даже если она пятилетней давности, но я узнал её сейчас)
- лонгридами, байками или всратыми историями, без указания срока давности
- последовательным описанием моего процесса мышления на работе при решении задач
Интересные, на мой взгляд, сообщения я публикую с тегами:
- пример основных тем канала:
#aws #azure #kubernetes #troubleshooting #costoptimization #longread #devops
- пример второстепенных категорий:
#terragrunt #victoriametrics #git #docker #одинденьизжизни #helm
- для того, чтобы на работе не поехать кукухой, у меня есть:
#пятница #всратость #байки
Сообщения без тегов это просто шутка-минутка или мысль, которая была актуальна лишь на момент написания.
Все заметки не имеют строгой последовательности, читать их можно как угодно:
- начать с самого основания канала (за год постов около 230)
- использовать интересующие теги/поиск
- ну или просто начать с новых постов, пропустив всё ранее написанное😭
Каждый решает, как ему удобно.
Буду рад, если мои заметки помогут кому-то узнать что-то новое, избежать повтора чужих ошибок или просто улыбнуться.
На крайний случай, самоутвердиться за счёт моих факапов или незнания🐒
Всем привет и желаю приятного чтения.
Поскольку все читатели здесь ради контента, а не моей биографии, сразу перейду к сути.
Этот блог - мои заметки на полях.
Почти не делаю репосты, пишу для души и лишь когда на это есть время/желание.
Обычно это 2-4 поста в неделю.
В основном делюсь:
- информацией, которую узнал только что (даже если она пятилетней давности, но я узнал её сейчас)
- лонгридами, байками или всратыми историями, без указания срока давности
- последовательным описанием моего процесса мышления на работе при решении задач
Интересные, на мой взгляд, сообщения я публикую с тегами:
- пример основных тем канала:
#aws #azure #kubernetes #troubleshooting #costoptimization #longread #devops
- пример второстепенных категорий:
#terragrunt #victoriametrics #git #docker #одинденьизжизни #helm
- для того, чтобы на работе не поехать кукухой, у меня есть:
#пятница #всратость #байки
Сообщения без тегов это просто шутка-минутка или мысль, которая была актуальна лишь на момент написания.
Все заметки не имеют строгой последовательности, читать их можно как угодно:
- начать с самого основания канала (за год постов около 230)
- использовать интересующие теги/поиск
- ну или просто начать с новых постов, пропустив всё ранее написанное
Каждый решает, как ему удобно.
Буду рад, если мои заметки помогут кому-то узнать что-то новое, избежать повтора чужих ошибок или просто улыбнуться.
На крайний случай, самоутвердиться за счёт моих факапов или незнания
Всем привет и желаю приятного чтения.
Please open Telegram to view this post
VIEW IN TELEGRAM
10👍31👨💻1
Make. Build. Break. Reflect. pinned «Приветствую всех. Поскольку все читатели здесь ради контента, а не моей биографии, сразу перейду к сути. Этот блог - мои заметки на полях. Почти не делаю репосты, пишу для души и лишь когда на это есть время/желание. Обычно это 2-4 поста в неделю. В основном…»
#costoptimization #aws #cloudwatch #одинденьизжизни
"Алекс, у нас снова траты по амазон, глянь по биллингу, чего можно скостить".
Иду в billing, выбираю последний месяц.
Дааа, много всего опять зачарджило. Чего можно убрать?
О, в топ 10 есть клаудвоч. Начну с него. Почему так много? Почти $2000+.
Смотрю что не так.
Внезапно много идет за графу
200.000.000+ реквестов.
Читаю что это.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html
Ага. Какой-то сторонний механизм/утилита, которая при помощи кредов/роли подключается к AWS API и вытягивает данные по метрикам из клаудвоч.
Из известного мне есть такие два инструмента:
- https://github.com/prometheus/cloudwatch_exporter
- https://github.com/prometheus-community/yet-another-cloudwatch-exporter
Оба эти категории инструмента подключаются к AWS API, дергают метрики, экспортируют в удобный формат, чтобы можно было в victoria metrics/prometheus/grafana видеть эти новые метрики.
Почему новые? Они берут оригинальное название метрики, добавляют префикс и получается новая метрика в нашем хранилище.
Далее поиском по всем репозиториям(гит, арго, хелм) внутри компании ищу - есть ли они у нас.
Да, есть, у нас YACE.
Как оптимизировать? Мне ничего в голову не приходит, как сделать следующее:
- подключаюсь к service через порт форвард
- вытягиваю все метрики в файл
- пишу баш скрипт, который считает количество уникальных метрик и всякое такое
Ага, у нас 54.000+ метрик. Это много.
Иду в конфиг в гите, там нечто типа
И такого там много.
По частоте опроса вроде ок - 300 секунд, около бест практис для клаудвоч экспортёров.
А чего подрезать-то тогда?
Нужен ли max? Min? Avg?
Следим ли мы за натгейтвеем?
А всё просто.
- при том же bash скрипте расписываем все уникальные метрики и их итоговое название.
- идём все репозитории с алертингом и мониторингом (alertmanager, grafana irm, vmalert, grafana dashboards etc)
- если метрика нигде в observability не используется - мы её просто убираем из конфига. Где-то только min, где-то max, где-то полностью всю метрику со всеми значениями
Даже если удастся убрать хотя бы 50% неиспользуемых метрик - это минус 50% от биллинга, а это $1000+
Пулл реквест, ревью, аппрув, раскатываем.
Всё, в следующем месяце ждём снижения костов на клаудвоч на 50%+
"Алекс, у нас снова траты по амазон, глянь по биллингу, чего можно скостить".
Иду в billing, выбираю последний месяц.
Дааа, много всего опять зачарджило. Чего можно убрать?
О, в топ 10 есть клаудвоч. Начну с него. Почему так много? Почти $2000+.
Смотрю что не так.
Внезапно много идет за графу
$0.01 per 1,000 metrics requested using GetMetricData API - US East (Northern Virginia)
200.000.000+ реквестов.
Читаю что это.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html
Ага. Какой-то сторонний механизм/утилита, которая при помощи кредов/роли подключается к AWS API и вытягивает данные по метрикам из клаудвоч.
Из известного мне есть такие два инструмента:
- https://github.com/prometheus/cloudwatch_exporter
- https://github.com/prometheus-community/yet-another-cloudwatch-exporter
Оба эти категории инструмента подключаются к AWS API, дергают метрики, экспортируют в удобный формат, чтобы можно было в victoria metrics/prometheus/grafana видеть эти новые метрики.
Почему новые? Они берут оригинальное название метрики, добавляют префикс и получается новая метрика в нашем хранилище.
Далее поиском по всем репозиториям(гит, арго, хелм) внутри компании ищу - есть ли они у нас.
Да, есть, у нас YACE.
Как оптимизировать? Мне ничего в голову не приходит, как сделать следующее:
- подключаюсь к service через порт форвард
kubectl port-forward svc/yet-another-cloudwatch-exporter 5000:5000
- вытягиваю все метрики в файл
curl localhost:5000/metrics > metrics.txt
- пишу баш скрипт, который считает количество уникальных метрик и всякое такое
Ага, у нас 54.000+ метрик. Это много.
Иду в конфиг в гите, там нечто типа
config: |-
apiVersion: v1alpha1
discovery:
exportedTagsOnMetrics:
AWS/NetworkELB:
- tenant-id
- type
- cluster
jobs:
- type: AWS/NetworkELB
regions:
- us-east-1
...
- eu-central-1
- eu-central-2
period: 300
length: 300
metrics:
- name: ActiveFlowCount
statistics: [Average, Minimum, Maximum]
- name: ActiveFlowCount_TLS
statistics: [Average, Minimum, Maximum]
...
- name: UnHealthyHostCount
statistics: [Average, Minimum, Maximum]
- name: PortAllocationErrorCount
statistics: [Sum]
...
- type: AWS/TransitGateway
regions:
- us-east-1
...
period: 300
length: 300
metrics:
- name: BytesIn
statistics: [Average, Minimum, Maximum, Sum]
- name: BytesOut
statistics: [Average, Minimum, Maximum, Sum]
- name: PacketsIn
statistics: [Average, Minimum, Maximum, Sum]
...
- type: AWS/NATGateway
regions:
- us-east-1
...
- eu-central-2
period: 300
length: 300
metrics:
- name: ActiveConnectionCount
statistics: [Maximum, Sum]
- name: BytesInFromDestination
statistics: [Sum]
...
И такого там много.
По частоте опроса вроде ок - 300 секунд, около бест практис для клаудвоч экспортёров.
А чего подрезать-то тогда?
Нужен ли max? Min? Avg?
Следим ли мы за натгейтвеем?
А всё просто.
- при том же bash скрипте расписываем все уникальные метрики и их итоговое название.
- идём все репозитории с алертингом и мониторингом (alertmanager, grafana irm, vmalert, grafana dashboards etc)
- если метрика нигде в observability не используется - мы её просто убираем из конфига. Где-то только min, где-то max, где-то полностью всю метрику со всеми значениями
Даже если удастся убрать хотя бы 50% неиспользуемых метрик - это минус 50% от биллинга, а это $1000+
Пулл реквест, ревью, аппрув, раскатываем.
Всё, в следующем месяце ждём снижения костов на клаудвоч на 50%+
👍13👏4🎄2🤷♂1❤1❤🔥1
Итог:
я всего лишь проанализировал куда уходят деньги, нашёл конфиг приложения, который чарджит амазон, собрал все метрики, проверил есть ли они в обсервабилити, удалил неиспользуемое (зачем нам собирать то, что мы не используем?).
Ничего сложного, а у нас экономия на пустом месте.
я всего лишь проанализировал куда уходят деньги, нашёл конфиг приложения, который чарджит амазон, собрал все метрики, проверил есть ли они в обсервабилити, удалил неиспользуемое (зачем нам собирать то, что мы не используем?).
Ничего сложного, а у нас экономия на пустом месте.
👍13👏5