"Вернись обратно"
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
Переключиться на предыдущий контекст Kubernetes
Переключиться на предыдущий namespace в Kubernetes
Переключиться на предыдущую ветку в git
Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
cd - Переключиться на предыдущий контекст Kubernetes
kubectx - Переключиться на предыдущий namespace в Kubernetes
kubens -Переключиться на предыдущую ветку в git
git checkout -Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
👍10❤2
Не амазоном едины.
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
На стеке
ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
- создавать новые
То есть через
Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
observability.Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
Azure у нас есть целая матрица IOPS дисков, которая зависит от размера и сторадж класса + бёрстабл мод по времени.https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
records.На стеке
victoria metrics(да вообще и в прометиусе тоже на самом деле) мы легко можем создавать такую сущность как vmalert и vmrule.ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
rule для алёртов- создавать новые
recordsТо есть через
records мы можем создавать свои, абсолютно удобные для нас метрики со своими лейблами. Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
pvc_iops_utilization_percent = 80 говорит о том, что мы для этого кластера/неймспейса/пода упирираемся в 80% от возможностей этого диска, использующего этот тип стораджа класса.И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
👏3👍1
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlert
metadata:
name: ${NAME}
namespace: ${NAMESPACE}
spec:
replicaCount: 1
datasource:
url: ${URL_DATASOURCE}
notifier:
url: ${URL_NOTIFIER}
evaluationInterval: "30s"
selectAllByDefault: true
remoteWrite:
url: http://vminsert-victoria-metrics-cluster.service:8480/insert/0/prometheus/
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
metadata:
name: vmrule-storage-iops
namespace: ${NAMESPACE}
spec:
groups:
- name: storage_monitoring
interval: 30s
rules:
- record: storage_class_iops_limits
expr: |
sum by(persistentvolume, storageclass, cluster) (
(kube_persistentvolume_info{storageclass=~"azureblob-fuse-premium|azureblob-nfs-premium"} * 15000) or
(kube_persistentvolume_info{storageclass=~"managed-premium|managed-csi-premium|managed-premium-burstable"} * 20000) or
(kube_persistentvolume_info{storageclass=~"managed|managed-csi|default"} * 6000) or
(kube_persistentvolume_info{storageclass="managed-csi-os-warm-nodes"} * 6000) or
(kube_persistentvolume_info{storageclass=~"azurefile-premium|azurefile-csi-premium|azurefile-nonroot|azurefile-sc-fips|sc-rwm"} * 100000) or
(kube_persistentvolume_info{storageclass=~"azurefile|azurefile-csi|azurefile-standart-nonroot"} * 10000) or
(kube_persistentvolume_info * 500)
)
- record: pod_pvc_info
expr: |
max by(cluster, exported_namespace, pod, persistentvolumeclaim) (
kube_pod_spec_volumes_persistentvolumeclaims_info
)
- record: pvc_storage_info
expr: |
max by(cluster, exported_namespace, persistentvolumeclaim, storageclass) (
kube_persistentvolumeclaim_info
)
- record: pvc_current_iops
expr: |
sum by(cluster, pod, namespace, persistentvolumeclaim, storageclass) (
(
rate(container_fs_reads_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m]) +
rate(container_fs_writes_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m])
)
)
* on(cluster, pod) group_left(persistentvolumeclaim, exported_namespace)
pod_pvc_info
* on(cluster, exported_namespace, persistentvolumeclaim) group_left(storageclass)
pvc_storage_info
- record: pvc_iops_utilization_percent
expr: |
sum by(cluster, namespace, pod, persistentvolumeclaim, storageclass) (pvc_current_iops)
* 100
/ on(cluster, storageclass) group_left()
max by(cluster, storageclass) (storage_class_iops_limits)
---
- alert: HighIOPSUtilization
expr: round(pvc_iops_utilization_percent) > 85
for: 40m
labels:
severity: warning
annotations:
summary: "IOPS is `{{ $value }}%` on `{{ $labels.cluster }}`/`{{ $labels.namespace }}`/`{{ $labels.pod }}`."
✍1
Ну вот и график в графане.
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
😁2👍1
Утро началось с осознания, что:
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
🔥8
#victoriametrics
Итак, кросс-алёртинг.
Название мною выдуманное, я не знаю как такие вещи должны называться, может давно уже другое официальное слово есть.
Допустим у вас есть система мониторинга, трейсинга и алёртинга.
Это может быть
Она работает в кластере или нескольких.
Оповещает по алёртам ваш Slack/PagerDuty/telegram etc.
Всё работает и всё отлично.
А что делать, если POD с Alertmanager упал? Что делать, если у вас накрылся весь кластер?
Вы ведь даже не узнаете об этом - некому сообщить о том, что всё упало.
Есть готовые реализации, но нам не подошло большинство из-за цены, способа интеграции или недостаточного для меня функционала. А что это значит? Прааааавильно, пишем свой велосипед😅.
У
Этот алёрт горит ВСЕГДА.
То есть "если у алёртменеджера всё хорошо" - значит горит алерт.
Если "если вочдог не горит" - алертменеджер умер/конфиг с ошибкой/недоступен и так далее.
Логика наоборот.
В зависимости от вашей системы обсервабилити и способа установки он может быть включен по умолчанию, но если его нет, то вы его легко можете добавить(пример для VM стека):
Итак, алёрт у нас есть.
Дальше что?
А дальше идея такая:
- мы пишем новый микросервис, пусть будет на Python, все переменные в хардкоде для удобства этого демо
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/main.py
- пишем докерфайл для запуска в кубах (я вообще не заморачивался с оптимизацией тут)
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/Dockerfile
- деплоим его в ДРУГОЙ/ДРУГИЕ кластера кубернетиса, можно хоть хелм чарт на него написать, если есть желание, у меня сделано через ArgoCD - путь к имаджу и переменные и всё
- в конфиг алертменеджера добавляем новый route и receiver чтобы watchdog alert отправлялся в новый микросервис
Итак, кросс-алёртинг.
Название мною выдуманное, я не знаю как такие вещи должны называться, может давно уже другое официальное слово есть.
Допустим у вас есть система мониторинга, трейсинга и алёртинга.
Это может быть
kube-prometheus-stack или victoria-metrics-k8s-stack или любой другой стек или оператор.Она работает в кластере или нескольких.
Оповещает по алёртам ваш Slack/PagerDuty/telegram etc.
Всё работает и всё отлично.
А что делать, если POD с Alertmanager упал? Что делать, если у вас накрылся весь кластер?
Вы ведь даже не узнаете об этом - некому сообщить о том, что всё упало.
Есть готовые реализации, но нам не подошло большинство из-за цены, способа интеграции или недостаточного для меня функционала. А что это значит? Прааааавильно, пишем свой велосипед😅.
У
Alertmanager есть механизм, который называется Watchdog.Этот алёрт горит ВСЕГДА.
То есть "если у алёртменеджера всё хорошо" - значит горит алерт.
Если "если вочдог не горит" - алертменеджер умер/конфиг с ошибкой/недоступен и так далее.
Логика наоборот.
В зависимости от вашей системы обсервабилити и способа установки он может быть включен по умолчанию, но если его нет, то вы его легко можете добавить(пример для VM стека):
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
...
spec:
groups:
...
- name: "alertmanager"
rules:
- alert: Watchdog
expr: vector(1)
for: 5m
labels:
severity: info
annotations:
summary: "This is an Watchdog alert that is always firing."
...
Итак, алёрт у нас есть.
Дальше что?
А дальше идея такая:
- мы пишем новый микросервис, пусть будет на Python, все переменные в хардкоде для удобства этого демо
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/main.py
- пишем докерфайл для запуска в кубах (я вообще не заморачивался с оптимизацией тут)
https://github.com/kruchkov-alexandr/cross-alerting/blob/main/Dockerfile
- деплоим его в ДРУГОЙ/ДРУГИЕ кластера кубернетиса, можно хоть хелм чарт на него написать, если есть желание, у меня сделано через ArgoCD - путь к имаджу и переменные и всё
- в конфиг алертменеджера добавляем новый route и receiver чтобы watchdog alert отправлялся в новый микросервис
route:
...
routes:
##############################################################
# Watchdog #
##############################################################
# DO NOT REMOVE THIS ROUTE!!!
# DO NOT ADD ROUTES ABOVE!!!
- receiver: 'webhook-receiver'
group_wait: 10s
group_interval: 30s
repeat_interval: 30s
matchers:
- alertname = "Watchdog"
continue: true
...
receivers:
...
- name: 'webhook-receiver'
webhook_configs:
- url: 'https://cross-alerting.domain.io/api/alert'
send_resolved: true
....
✍3
Собственно и всё:
- алертменеджер каждые 5 минут отправляет вебхуки на URL cross-alerting
- скрипт запускает веб-сервер, который слушает POST-запросы на /api/alert.
- каждый раз, когда приходит запрос на этот endpoint, обновляется время последнего вебхука.
- в фоновом режиме работает тред, который проверяет, как давно приходил последний вебхук.
- если вебхук не приходил дольше, чем WEBHOOK_CHECK_INTERVAL(2 минуты), система считается "упавшей", и отправляется уведомление в Slack.
- если система была "упавшей", но вебхук пришел, отправляется уведомление о восстановлении.
- если pod был перезапущен в течение последних 30 секунд, отправляется уведомление о восстановлении.
* Давайте ток не душнить про овнокод на питоне и докерфайл, задачи по оптимизации не стояло.
Надо было просто написать так, чтобы перекрёстный мониторинг и алёртинг работал, он работает, а значит задача решена. Для себя можете писать Свой Идеальный Божественный Код.
- алертменеджер каждые 5 минут отправляет вебхуки на URL cross-alerting
- скрипт запускает веб-сервер, который слушает POST-запросы на /api/alert.
- каждый раз, когда приходит запрос на этот endpoint, обновляется время последнего вебхука.
- в фоновом режиме работает тред, который проверяет, как давно приходил последний вебхук.
- если вебхук не приходил дольше, чем WEBHOOK_CHECK_INTERVAL(2 минуты), система считается "упавшей", и отправляется уведомление в Slack.
- если система была "упавшей", но вебхук пришел, отправляется уведомление о восстановлении.
- если pod был перезапущен в течение последних 30 секунд, отправляется уведомление о восстановлении.
* Давайте ток не душнить про овнокод на питоне и докерфайл, задачи по оптимизации не стояло.
Надо было просто написать так, чтобы перекрёстный мониторинг и алёртинг работал, он работает, а значит задача решена. Для себя можете писать Свой Идеальный Божественный Код.
👍3
Ночь, бессонница.
Горение.
Читаю комментарии к разным статьям про развитие UI/UX, про размеры приложений на телефон в 1300 мегабайт для чтения pdf файлов без редактирования.
Про максимально ставший абсолютным рекордсменом говна - ноушн. Я словно Нео в драке с мистером Андерсоном отбиваюсь каждый день от новых всплывающих окон с НУ ВОТ ТЕПЕРЬ ТОЧНО НОВАЯ ПОЛЕЗНАЯ ФИЧА ХОТЬ ТЫ И НЕ ПРОСИЛ НА ВОТ СОРТИРУЙ СВОИ СЧЕТА ЗА АПРЕЛЬ ПО НОВОМУ AI В ЗАМЕТКАХ.
Не менее всратый слак - джигурдаллион фичей ежедневно, половина из них умерло до их релиза и, особенно, использования реальными людьми.
Везде AI. Везде pop-up, бесячая джира и конфлюенс каждый день(!) высирает новые окошки с новой абсолютно бесполезной херней.
Мы уже даже привыкли их закрывать, многим реально понасрать что там у вас вышло.
Ноушн, банк клиент, стриминг плеер. Открыл Яндекс музыку - автоматически оформил ипотеку в Перми.
Люди, разработчики, аналитики, корпорации - все они/мы перестали делать ПРОСТО ПРИЛОЖЕНИЕ.
То, ради чего к ним пришли и пользуются/платят.
Не добавляя сторизы в калькулятор, не добавляя предложение о кредите в фотоальбом.
Все наши телефоны от 50 баксов с Али до топов за 3000, умеют на Марс летать и рассчитывать орбиту геостационарных спутников за 0.00001наносекунд, но ослиное приложение по просто вызову такси тормозит так, что я уже пешком дошёл, потому что у нас ЭКОСИСТЕМА СУПЕРАПП. 😂
Я реально прекратил пользоваться около 25 приложениями, потому что вместо простого и обещанного функционала оно превратилось в ишачий кал с AI и сторизами от курьеров-случайных-контактов из Узбекистана.
Кое-кто даже перестал выполнять свою изначальную функцию, что печалит.
Бог с ним, с размером, благо у нас больше не дискетки, что произошло с главным - функционалом?
Что не так с индустрией? Почему мы начали делать говно?
Не соглашусь, что мы всегда делали говно, ещё есть приложения, которые всё ещё просто делают свою работу.
Кто виноват? Зумеры айтишники? AI проклятый век? Эффективные менеджеры?
Старые пердуны сишники?
Вкатуны(как я)? Или всё испортили статьи про аджайл и влажные маня фантазии инвесторов?
Кому разбить лицо?
* Возгорание произошло из-за обновления Spotify, он мне на ПК вертикальные сторизы-тизеры-песен-без-способности-прослушать-весь-трек выдал😂 . На ПК🤭 .
Зачем это дерьмо вообще релизили?
Горение.
Про максимально ставший абсолютным рекордсменом говна - ноушн. Я словно Нео в драке с мистером Андерсоном отбиваюсь каждый день от новых всплывающих окон с НУ ВОТ ТЕПЕРЬ ТОЧНО НОВАЯ ПОЛЕЗНАЯ ФИЧА ХОТЬ ТЫ И НЕ ПРОСИЛ НА ВОТ СОРТИРУЙ СВОИ СЧЕТА ЗА АПРЕЛЬ ПО НОВОМУ AI В ЗАМЕТКАХ.
Не менее всратый слак - джигурдаллион фичей ежедневно, половина из них умерло до их релиза и, особенно, использования реальными людьми.
Везде AI. Везде pop-up, бесячая джира и конфлюенс каждый день(!) высирает новые окошки с новой абсолютно бесполезной херней.
Мы уже даже привыкли их закрывать, многим реально понасрать что там у вас вышло.
Ноушн, банк клиент, стриминг плеер. Открыл Яндекс музыку - автоматически оформил ипотеку в Перми.
Люди, разработчики, аналитики, корпорации - все они/мы перестали делать ПРОСТО ПРИЛОЖЕНИЕ.
То, ради чего к ним пришли и пользуются/платят.
Не добавляя сторизы в калькулятор, не добавляя предложение о кредите в фотоальбом.
Все наши телефоны от 50 баксов с Али до топов за 3000, умеют на Марс летать и рассчитывать орбиту геостационарных спутников за 0.00001наносекунд, но ослиное приложение по просто вызову такси тормозит так, что я уже пешком дошёл, потому что у нас ЭКОСИСТЕМА СУПЕРАПП.
Я реально прекратил пользоваться около 25 приложениями, потому что вместо простого и обещанного функционала оно превратилось в ишачий кал с AI и сторизами от курьеров-случайных-контактов из Узбекистана.
Кое-кто даже перестал выполнять свою изначальную функцию, что печалит.
Бог с ним, с размером, благо у нас больше не дискетки, что произошло с главным - функционалом?
Что не так с индустрией? Почему мы начали делать говно?
Не соглашусь, что мы всегда делали говно, ещё есть приложения, которые всё ещё просто делают свою работу.
Кто виноват? Зумеры айтишники? AI проклятый век? Эффективные менеджеры?
Старые пердуны сишники?
Вкатуны(как я)? Или всё испортили статьи про аджайл и влажные маня фантазии инвесторов?
Кому разбить лицо?
* Возгорание произошло из-за обновления Spotify, он мне на ПК вертикальные сторизы-тизеры-песен-без-способности-прослушать-весь-трек выдал
Зачем это дерьмо вообще релизили?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8💯4🤣3
Самая удивительная особенность, которая обнаружилась после перехода RDS(
А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.
Когда был
Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для
Когда переключили на
- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.
Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена
* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.
#AWS #CostOptimization
8.0.mysql_aurora.3.08.0) на Gravitron v2, это способность на высокий утилизации CPU не снижать эффективность/производительность.А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.
Когда был
db.r5.2xlarge, при CPU usage 85-100% длительностью больше 10-15 минут начиналась небольшая, но деградация работы с базой данных.Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для
Debezium+Kafka для реалтайма)Когда переключили на
db.r6g.2xlarge при ровно таких же жёстких нагрузках:- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.
Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена
c5->r6 или же невероятная магия ARM у Gravitron.* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.
#AWS #CostOptimization
👍4
Реальность 2025:
- удалил 3 игры из Стима, которые занимали много места на двух-терабайтном диске, чтобы установить модели типа https://ollama.com/library/deepseek-r1, потому как все паблик AI сервисы(чатгпт,дипсик,копайлот,клаудия) достаточно серьёзно часто тормозят/висят(даже с PRO), а мне работать надо и нейронки помогают писать юнит тесты.🚬
Пока сижу локально гоняю модельки, терпимо.
* у вас может и не получиться скачать, сам качал долго, постоянно EOF😭
- удалил 3 игры из Стима, которые занимали много места на двух-терабайтном диске, чтобы установить модели типа https://ollama.com/library/deepseek-r1, потому как все паблик AI сервисы(чатгпт,дипсик,копайлот,клаудия) достаточно серьёзно часто тормозят/висят(даже с PRO), а мне работать надо и нейронки помогают писать юнит тесты.
Пока сижу локально гоняю модельки, терпимо.
* у вас может и не получиться скачать, сам качал долго, постоянно EOF
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
#devops
Когда есть частая задача быстро смотреть содержимое секретов кубера, например пароли:
Пример использования:
Особенности:
- для тех, кто не любит тяжёлые плагины с kubectl или k9s
- эта функция-пример не учитывает неймспейс, но я всегда юзаю
*kvs - kube view secret
Когда есть частая задача быстро смотреть содержимое секретов кубера, например пароли:
~/.bashrc (или любой другой шелл)function kvs() {
kubectl get secret "$1" -o json | jq '.data | map_values(@base64d)'
}Пример использования:
> kvs grafana-monitoring
{
"admin-password": "pupupu",
"admin-user": "pupupu@pupupu.ded",
"ldap-toml": ""
}
Особенности:
- для тех, кто не любит тяжёлые плагины с kubectl или k9s
- эта функция-пример не учитывает неймспейс, но я всегда юзаю
kubens и свичусь всегда, так что для меня ок*kvs - kube view secret
👍10
#пятница
Не, ну а какой ещё может быть мой ответ при росте бизнеса и утроению количества клиентов. Вечно накидывать ресурсы не выйдет.
Не, ну а какой ещё может быть мой ответ при росте бизнеса и утроению количества клиентов. Вечно накидывать ресурсы не выйдет.
😁7🤣5💯3
Очень важный апдейт со стороны let's encrypt.
https://letsencrypt.org/2025/01/22/ending-expiration-emails/
Надеюсь, что у всех настроен мониторинг и алертинг протухшести сертификатов.
Пример на базе
Так же не забывайте смотреть и в другие места, например сертменеджер.
Можно украсть у https://github.com/monitoring-mixins/website/blob/master/assets/cert-manager/alerts.yaml
Всегда краду алёрты.
#alertmanager #monitoring
https://letsencrypt.org/2025/01/22/ending-expiration-emails/
Надеюсь, что у всех настроен мониторинг и алертинг протухшести сертификатов.
Пример на базе
nginx ingress controller + alertmanager для kubernetes:rules:
- alert: SSLexpiresSoon
expr: nginx_ingress_controller_ssl_expire_time_seconds - time() <= 7 * 24 * 60 * 60
annotations:
summary: "SSL for `{{ $labels.host }}` expires in {{ .Value | humanizeDuration }}"
Так же не забывайте смотреть и в другие места, например сертменеджер.
Можно украсть у https://github.com/monitoring-mixins/website/blob/master/assets/cert-manager/alerts.yaml
Всегда краду алёрты.
#alertmanager #monitoring
🔥5👍2
Есть база данных 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
👍9
Мониторинг. Алёртинг. Трейсинг.
Мы любим всё мониторить и алёртить.
Смотрим на показатели
Смотрим в
Иногда выбираемся из своих сетей и смотрим на
Когда базовые вещи покрыты иделать нечего мы растём дальше, у каждого из нас наступает момент развития.
Добавляются всякие шутки типа:
- кросс мониторинг алертинг
- срок действия кредов для azure service principle для разных тенантов
- мониторинг срока действия сертификатов SSL
и так далее.
Сегодня встала задача следить за токенами(PAT) в GitLab.
Не секрет, что, что эти токены могут использоваться везде, да хотя бы даже в sidecar контейнерах для gitsync, например, у airflow с DAGs. Когда токены протухают становится больно и мы страдаем.
Я потратил некоторое время на изучение как мне лучше их мониторить:
- собирать метрики напрямую из гитлаба. не подошло, он не отдаёт ничего по expired/revoke токенам
- обратиться к API гитлаба, удалить все старые/expired/неактивные токены. не прошло - гитлаб НЕ удаляет токены, он их ревоукает, если метод delete использовать. то есть нельзя вот так просто удалить токены, а потом написать свой собственный инструмент для мониторинга новых токенов, кто протухает.
Кстати можете глянуть сколько старых токенов у вас в гитлабе
В общем много изучал и читал, в итоге отказался от идеи работать с метриками.
Решил просто написать скрипт.
Как это работает:
- создаём новый репозиторий в гитлабе
- пилим пайплайн
- пилим requirements.txt
- ну и сам скрипт check_tokens.py
https://gist.github.com/kruchkov-alexandr/354cf4500f0471d10717c2f9197d08e2
* скрипт писла нейронка, мне было лень, все претензии к моей лени
- затем добавляем две переменные в гитлаб CICD, masked, protected
- не забывает включить крон для пайплайна
Что же всё это делает:
- раз в сутки запускается пайплайн в самом же гитлабе
- скрипт использует креды для подключения к апи гитлаба
- при помощи пагинации собирает инфу по всем токенам всех пользователей
- проверяет дифф между "текущая дата" и "срок действия токенов"
- если в течении ближайших 10 дней будет протухание - отправляет в слак уведомление
Мы любим всё мониторить и алёртить.
Смотрим на показатели
kube-state-metrics и его метриками, чтобы узнать как часто поды рестартились kube_pod_container_status_restarts_total.Смотрим в
node-exporter, чтобы оценить нагрузку ЦПу на нодах node_cpu_seconds_total.Иногда выбираемся из своих сетей и смотрим на
blackbox exporter чтобы прочекать доступностьт внешних сайтов через probe_success.Когда базовые вещи покрыты и
Добавляются всякие шутки типа:
- кросс мониторинг алертинг
- срок действия кредов для azure service principle для разных тенантов
- мониторинг срока действия сертификатов SSL
и так далее.
Сегодня встала задача следить за токенами(PAT) в GitLab.
Не секрет, что, что эти токены могут использоваться везде, да хотя бы даже в sidecar контейнерах для gitsync, например, у airflow с DAGs. Когда токены протухают становится больно и мы страдаем.
Я потратил некоторое время на изучение как мне лучше их мониторить:
- собирать метрики напрямую из гитлаба. не подошло, он не отдаёт ничего по expired/revoke токенам
- обратиться к API гитлаба, удалить все старые/expired/неактивные токены. не прошло - гитлаб НЕ удаляет токены, он их ревоукает, если метод delete использовать. то есть нельзя вот так просто удалить токены, а потом написать свой собственный инструмент для мониторинга новых токенов, кто протухает.
Кстати можете глянуть сколько старых токенов у вас в гитлабе
token="glpat-***"
gitlab_url="https://gitlab***"
page=1
while true; do
response=$(curl -s --header "PRIVATE-TOKEN: $token" "$gitlab_url/api/v4/personal_access_tokens?page=$page&per_page=50")
if [[ -z "$response" || "$response" == "[]" ]]; then
break
fi
echo "$response" | jq -r '.[] | select(.expires_at < "2025-01-01") | .id' >> expired_token_ids.txt
((page++))
done
В общем много изучал и читал, в итоге отказался от идеи работать с метриками.
Решил просто написать скрипт.
Как это работает:
- создаём новый репозиторий в гитлабе
- пилим пайплайн
# .gitlab-ci.yml
check-tokens:
image: python:3.11-slim
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
when: always
- if: $CI_PIPELINE_SOURCE == "web"
when: always
before_script:
- pip install --no-cache-dir -r requirements.txt
script:
- python3 check_tokens.py
variables:
GITLAB_TOKEN: ${GITLAB_API_TOKEN}
GITLAB_URL: "https://gitlab.****" #на самом деле тут есть CI дефолт переменная, надо переделать после написания заметки
SLACK_WEBHOOK_URL: ${SLACK_WEBHOOK_URL}
tags:
- docker
- пилим requirements.txt
python-gitlab>=3.15.0
requests>=2.31.0
python-dateutil>=2.8.2
- ну и сам скрипт check_tokens.py
https://gist.github.com/kruchkov-alexandr/354cf4500f0471d10717c2f9197d08e2
* скрипт писла нейронка, мне было лень, все претензии к моей лени
- затем добавляем две переменные в гитлаб CICD, masked, protected
GITLAB_API_TOKEN
SLACK_WEBHOOK_URL
- не забывает включить крон для пайплайна
0 10 * * *Что же всё это делает:
- раз в сутки запускается пайплайн в самом же гитлабе
- скрипт использует креды для подключения к апи гитлаба
- при помощи пагинации собирает инфу по всем токенам всех пользователей
- проверяет дифф между "текущая дата" и "срок действия токенов"
- если в течении ближайших 10 дней будет протухание - отправляет в слак уведомление
👍6
То есть необязательно смотреть метрики(а их и нет штатно), необязательно пилить новый экспортёр (уверен, наверняка он уже есть для гитлаба). Можно просто решить задачу мониторинга уставших токенов через скрипт и апишку с уведомлением в слак.
Да и вообще нам не надо смотреть в старые, уже не используемые токены, мы смотрим лишь разницу между сегодня и ближайшими 10 днями. Всё просто, я решил не переусложнять в этот раз.
Да и вообще нам не надо смотреть в старые, уже не используемые токены, мы смотрим лишь разницу между сегодня и ближайшими 10 днями. Всё просто, я решил не переусложнять в этот раз.
👍3🔥1
Просто мои собственные мысли.
Не наброс, просто мысли.
В начале 2025 года я решил не заниматься всей активностью, связанную с социальными сетями для поиска работы.
Полностью прекратил что-либо писать на linkedin. За последние пару лет и вовсе всё удалил оттуда, включая работодателя.
Не поддерживаю резюме на hh.ru и любых подобных ресурсах.
Удалил профили со всяких indeed.** и xing.de
Перестал видеть в этом смысл для себя, совсем.
Для себя и решил поддерживать эти виды деятельности:
- продолжать писать полезные статей публично(например habr и medium)
- писать заметки в Телеграме тут, технические и не только
- раз в полгода-год обновлять свой локальный CV в one-page PDF + three-page PDF
- пытаться выступать на конференциях хотя бы раз в год (сейчас готовлю материал)
- помогать комьюнити в чатах, том же @kubernetes_ru "светить лицом инженера"
На мой взгляд тратить время на поддерживание профилей в том же линкедине не стоит
Сейчас современный мир, заполнен AI.
1) кандидаты обманывают потенциальных работодателей
- - ходят на собеседования с наушниками
- - сидят с десятью дисплеями во время интервью с подсказками
- - врут о своем опыте
- - да даже CV им пишет AI
- - пишут ботов, чтобы заполняли везде бессмысленные комментарии типа
- - нанимают специальных людей, которые их менторят и подготовки к собеседованию, так и первые таски помогают решать
2) работодатели ленивые
- - так же на автомате тоннами обрабатывают письма и CV кандидатов при помощи AI, отсеивая то, что не проходит по паттернам
- - не задумываясь над тем нужно это или нет, заставляет решать какие-то логические задачки перед техническим собеседованием
- - плохо проводят собеседования, не делая акцент чем нужно заниматься, а гоняют по "типикал 300 вопросов на собесе девопс", которые, как правило, не имеют ничего общего с реальностью
- - даже страницы социальных сетей парсят при помощи AI чтобы по паттернам им подобрали кандидата
3) социальные сети добавляют(давно уже) рейтинги типа LinkedIn SSI Score🤣
HR с уровнем оладушка такие:
- - мммм у кандидата рейтинг SSI 85%, он тратит несколько часов ежедневно на посты в социальной сети, на лайки и генерациюмусорных комментариев, ну это наш кандидат! Совершенно точно знает свою профессию! Специалист! 🤣
2024-2025 это годы тотально поломанного найма(с обоих сторон) и переоценке вспомогательных инструментов для соискателя и работодателя, лишь ещё более ломающие этот найм.
При поломанном мире найма тратить время на шелуху в линкедине и других социальных сетях для поиска работы не вижу смысла.
Пишут в нем часто при помощи AI, и AI же всё парсит, комментирует и читает.
Пока основной план такой:
Когда я захочу найти себе новую работу я просто обновлю свой локальный PDF CV, открою сайт(ы) для поиска работы, благо сейчас много агрегаторов есть, отправлю запрос.
- если же работодатель воспользуется AI инструментом, дропнув моё письмо/заявку через 0.00001ms, значит тому и быть.
Будем писать другим работодателям. Значит этому работодателю кандидат не нужен.
- если в случае преодоления AI файрвола мною заинтересуются, закину им свои статьи, блог и CV PDF.
Если и это вас не заинтересует, ну значит и я вам не подхожу и вы мне. Пора менять стратегию.
Быть может я вскоре и переобуюсь, но на данный момент план пока такой.
* Вышесказанное касается только меня и может не совпадать с мнением кого-либо, как и не быть единственной истиной.
Это нормально.
Не наброс, просто мысли.
В начале 2025 года я решил не заниматься всей активностью, связанную с социальными сетями для поиска работы.
Полностью прекратил что-либо писать на linkedin. За последние пару лет и вовсе всё удалил оттуда, включая работодателя.
Не поддерживаю резюме на hh.ru и любых подобных ресурсах.
Удалил профили со всяких indeed.** и xing.de
Перестал видеть в этом смысл для себя, совсем.
Для себя и решил поддерживать эти виды деятельности:
- продолжать писать полезные статей публично(например habr и medium)
- писать заметки в Телеграме тут, технические и не только
- раз в полгода-год обновлять свой локальный CV в one-page PDF + three-page PDF
- пытаться выступать на конференциях хотя бы раз в год (сейчас готовлю материал)
- помогать комьюнити в чатах, том же @kubernetes_ru "светить лицом инженера"
На мой взгляд тратить время на поддерживание профилей в том же линкедине не стоит
Сейчас современный мир, заполнен AI.
1) кандидаты обманывают потенциальных работодателей
- - ходят на собеседования с наушниками
- - сидят с десятью дисплеями во время интервью с подсказками
- - врут о своем опыте
- - да даже CV им пишет AI
- - пишут ботов, чтобы заполняли везде бессмысленные комментарии типа
Valuable insights! Good job! Thanks for sharing (ну не сами же люди это вживую пишут, ведь да? young_padmé_amidala.png)- - нанимают специальных людей, которые их менторят и подготовки к собеседованию, так и первые таски помогают решать
2) работодатели ленивые
- - так же на автомате тоннами обрабатывают письма и CV кандидатов при помощи AI, отсеивая то, что не проходит по паттернам
- - не задумываясь над тем нужно это или нет, заставляет решать какие-то логические задачки перед техническим собеседованием
- - плохо проводят собеседования, не делая акцент чем нужно заниматься, а гоняют по "типикал 300 вопросов на собесе девопс", которые, как правило, не имеют ничего общего с реальностью
- - даже страницы социальных сетей парсят при помощи AI чтобы по паттернам им подобрали кандидата
3) социальные сети добавляют(давно уже) рейтинги типа LinkedIn SSI Score
HR с уровнем оладушка такие:
- - мммм у кандидата рейтинг SSI 85%, он тратит несколько часов ежедневно на посты в социальной сети, на лайки и генерацию
2024-2025 это годы тотально поломанного найма(с обоих сторон) и переоценке вспомогательных инструментов для соискателя и работодателя, лишь ещё более ломающие этот найм.
При поломанном мире найма тратить время на шелуху в линкедине и других социальных сетях для поиска работы не вижу смысла.
Пишут в нем часто при помощи AI, и AI же всё парсит, комментирует и читает.
Пока основной план такой:
Когда я захочу найти себе новую работу я просто обновлю свой локальный PDF CV, открою сайт(ы) для поиска работы, благо сейчас много агрегаторов есть, отправлю запрос.
- если же работодатель воспользуется AI инструментом, дропнув моё письмо/заявку через 0.00001ms, значит тому и быть.
Будем писать другим работодателям. Значит этому работодателю кандидат не нужен.
- если в случае преодоления AI файрвола мною заинтересуются, закину им свои статьи, блог и CV PDF.
Если и это вас не заинтересует, ну значит и я вам не подхожу и вы мне. Пора менять стратегию.
Быть может я вскоре и переобуюсь, но на данный момент план пока такой.
* Вышесказанное касается только меня и может не совпадать с мнением кого-либо, как и не быть единственной истиной.
Это нормально.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤4💯4🔥2
Airflow. Алёртинг.
К сожалению я так и не нашёл нормального эспортёра для метрик.
Пробовал около 5 разных, все не ок и пахнут коричневой магией.
В основном метрики "у вас где-то что-то случилось, возможно упал DAG, но я не знаю почему и это не точно".
В худшем варианте экспортёры вообще не сообщали, что падают даги.
Решено использовать нативный способ алёртинга на email.😭
Ниже описание для AirFlow, задеплоенный в кубернетес через helm chart.
Порядок действия:
- добавляем новый git репозиторий для хранения файлов
В GIT у нас будут храниться html темплейты(airflow не умеет в хранение этого в переменных).
- пилимGitLab PAT токен service account bot для доступа к git
- в новом гит репозитории создаём файл
https://gist.github.com/kruchkov-alexandr/a5c5387e1ba5cac773d60aa144fa6a90
* в данном примере я напихал в html ВСЁ!!!.
Вы можете сформировать свой формат html файла, который будет приходить к вам на почту.
Можно оставить только кластер и ошибку, можно ссылку на лог упавшего дага. Как вам удобнее.
С гитом мы закончили. переходим к чарту AirFlow и его values.
- добавляем креды для SMTP
Используя эти креды будут рассылаться письма.
- добавляем сайдкар контейнер, который будет запускаться рядом с AirFlow и запихивать к себе вовнутрь html темплейт (вовнутрь контейнера в директорию
- теперь переходим к переменным, которые будут отвечать за темплейтирование
Тут мы говорим откуда брать html шаблон
- ну и наконец включаем сам алёртинг через переменные
Финальная часть не забываем в глобал конфиге(уже в DAG) добавить в
* у вас может отличаться, спросите у ваших датасатанистов как настроен alerting!!! и я хз почему исторически там префикс orc.
Как это работает вкратце:
- airflow стартует, сайдкар тянет из гита html шаблон
- падает DAG
- AirFlow берёт свои данные и переменные, генерирует на базе html шаблона ответ и отправляет на почту
- вы получаете сообщение
- профит
Неудобно? Да, мне неудобно.
Я привык к Slack и почта мне неудобна.
Однако этот способ алёртинга пока единственно мне известный способ выводить точную и Детальную(!) информацию.
К сожалению я так и не нашёл нормального эспортёра для метрик.
Пробовал около 5 разных, все не ок и пахнут коричневой магией.
В основном метрики "у вас где-то что-то случилось, возможно упал DAG, но я не знаю почему и это не точно".
В худшем варианте экспортёры вообще не сообщали, что падают даги.
Решено использовать нативный способ алёртинга на email.
Ниже описание для AirFlow, задеплоенный в кубернетес через helm chart.
---
name: airflow
namespace: airflow
repoURL: https://airflow.apache.org/
targetRevision: 1.11.0
chart: airflow
Порядок действия:
- добавляем новый git репозиторий для хранения файлов
В GIT у нас будут храниться html темплейты(airflow не умеет в хранение этого в переменных).
- пилим
- в новом гит репозитории создаём файл
/templates/html_content_template.html
https://gist.github.com/kruchkov-alexandr/a5c5387e1ba5cac773d60aa144fa6a90
* в данном примере я напихал в html ВСЁ!!!.
Вы можете сформировать свой формат html файла, который будет приходить к вам на почту.
Можно оставить только кластер и ошибку, можно ссылку на лог упавшего дага. Как вам удобнее.
С гитом мы закончили. переходим к чарту AirFlow и его values.
- добавляем креды для SMTP
config:
smtp:
smtp_host: smtp.sendgrid.net
smtp_starttls: True
smtp_ssl: False
smtp_user: *****
smtp_password: ****
smtp_port: 587
smtp_mail_from: "no-reply@pupupu.ded"
Используя эти креды будут рассылаться письма.
- добавляем сайдкар контейнер, который будет запускаться рядом с AirFlow и запихивать к себе вовнутрь html темплейт (вовнутрь контейнера в директорию
/opt/airflow/ )extraContainers:
...
- name: git-sync-templates
image: registry.k8s.io/git-sync/git-sync:v4.1.0
volumeMounts:
- name: templates
mountPath: /templates
env:
- name: GITSYNC_REPO
value: https://****/templates-airflow.git
- name: GITSYNC_REF
value: master
- name: GITSYNC_ROOT
value: /templates
- name: GITSYNC_LINK
value: repo
- name: GITSYNC_PERIOD
value: 60s
- name: GITSYNC_ONE_TIME
value: "false"
- name: GITSYNC_USERNAME
value: airflow-git-sync
- name: GITSYNC_PASSWORD
valueFrom:
secretKeyRef:
name: airflow-gitsync-password
key: password
- теперь переходим к переменным, которые будут отвечать за темплейтирование
env:
- name: AIRFLOW__EMAIL__HTML_CONTENT_TEMPLATE
value: /opt/airflow/templates/repo/templates/html_content_template.html
Тут мы говорим откуда брать html шаблон
- ну и наконец включаем сам алёртинг через переменные
# email notifications:
- name: ORC_ALERT_ON_FAILURE
value: "True"
- name: ORC_FAILURE_EMAIL
value: "airflow-alerts@pupupu.ded"
Финальная часть не забываем в глобал конфиге(уже в DAG) добавить в
global_config.pyORC_FAILURE_EMAIL = os.getenv("ORC_FAILURE_EMAIL")
ORC_ALERT_ON_FAILURE = os.getenv("ORC_ALERT_ON_FAILURE") in ["True", "true"]
AIRFLOW_DEFAULT_ARGS = {
"owner": "airflow",
"email": ["pupupu@pupupu.ded" if is_development() else ORC_FAILURE_EMAIL],
"email_on_failure": ORC_ALERT_ON_FAILURE,
"email_on_retry": False,
"retries": 0,
"retry_delay": timedelta(seconds=10),
}* у вас может отличаться, спросите у ваших датасатанистов как настроен alerting!!! и я хз почему исторически там префикс orc.
Как это работает вкратце:
- airflow стартует, сайдкар тянет из гита html шаблон
- падает DAG
- AirFlow берёт свои данные и переменные, генерирует на базе html шаблона ответ и отправляет на почту
- вы получаете сообщение
- профит
Неудобно? Да, мне неудобно.
Я привык к Slack и почта мне неудобна.
Однако этот способ алёртинга пока единственно мне известный способ выводить точную и Детальную(!) информацию.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2👍1