Итоги:
- zalando operator так себе, это далеко не первый баг/моя претензия к нему
- я узнал о новых для себя вещах типа Distributed Configuration Store (DCS)
- не всегда ситуация "делаем рестарт бизнес пода = помогает" это проблема приложения. иногда мартышки это мы🐒
- CNPG - лучший❤️, не используйте никогда zalando
- zalando operator так себе, это далеко не первый баг/моя претензия к нему
- я узнал о новых для себя вещах типа Distributed Configuration Store (DCS)
- не всегда ситуация "делаем рестарт бизнес пода = помогает" это проблема приложения. иногда мартышки это мы
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍11👎1
Скоро обновлять подписку JetBrains.
Немного расстроен.
Всегда любил продукты JetBrains.
Много и часто использовал/использую IDEA, DataGrip, PyCharm, Goland(когда пытался в голанг учиться), Aqua, немного DataSpell и другие.
Мне нравится их программа поощрения, когда при продлении подписки All Products Pack дают 20% скидки.
При поиске промокода вообще недорого выходит продление и у меня есть доступ сразу к десятками инструментов.
Однако это было в 2020-2024 годах.
В 2024-2025 ситуация поменялась и последние годы у нас есть невероятно стабильный, скоростной и бесплатный VSCode с кучей крутых экстеншнов.
Появились AI-based IDE (кто-то любит, кто-то хейтит, речь не об этом) - Cursor, Windsurf и тысячи их.
Появились MCP агенты, чаты и даже нейронки, умеющие в мульти контекст.
Баги правятся оперативно(возможно даже благодаря вайб-патч-кодингу).
А JetBrains остались в стороне. Не буду ругать за AI ассистента - он терпимый, работает на современном уровне, даже на gpt4o. Сами ответы ок, хоть и интерфейс/взаимодействие полный треш.
Меня больше расстроило, что долго исправляют баги и часто ломают своими релизами примерно всё.
DataGrip за последний год у меня ломался 8 раз.
Каждый сраный релиз новые болезни:
- открываешь БД, раскрываешь каталоги/таблицы/схемы - он крутится-крутится и потом херак - схлопывается. А он просто не показывает что есть внутри. Либо рестарт приложения, либо рефреш, пока он не покажет все таблицы снова.
- запускаешь кверю через едитор в монгу - а он просто терминейтит окошко, ну что такое
- подключаешься к трино, а он при больших кверях отжирает много CPU. Локально. Алё! Это воркеры, а не клиентская часть выполняет аналитический запрос! откуда нагрузка??
И так постоянно.
IDEA (и другие на самом деле IDE) тоже постоянно с багами.
- проблема с плагинами повсеместно - то YAML стандарт нарушает, то схему не так читает
- то плагины просто сломаны и месяцами(!) не фиксятся
Например в этом/том году месяцев 8 вроде ждал исправления.
Воркэраунд был такой
Ну не песец, а? (они исправили и потом через несколько месяцев снова сломали по терраформу).
Writerside стал не актуальным с появлением context-based утилит и автогенерации документации, но и он пару раз какую-то херню выдавал, не помню уже.
В общем количество багов, неповоротливые долго запускающиеся (на wsl, на маке терпимо ок) IDE меня утомили.
Думаю не смогу продлить в этом году подписку, потеряю все последующие скидки, но я правда в этом году не вижу ни одного плюса у jetbrains. Мне кажется они перестали успевать за рынком и требованиями пользователей.
Жаль, IDEA была для меня легендарной IDE.❤️
Похоже время попрощаться со всем набором ПО от этих ребят, держаться за них лишь за скидки наверное ну такое, странное.😔
Немного расстроен.
Всегда любил продукты JetBrains.
Много и часто использовал/использую IDEA, DataGrip, PyCharm, Goland(когда пытался в голанг учиться), Aqua, немного DataSpell и другие.
Мне нравится их программа поощрения, когда при продлении подписки All Products Pack дают 20% скидки.
При поиске промокода вообще недорого выходит продление и у меня есть доступ сразу к десятками инструментов.
Однако это было в 2020-2024 годах.
В 2024-2025 ситуация поменялась и последние годы у нас есть невероятно стабильный, скоростной и бесплатный VSCode с кучей крутых экстеншнов.
Появились AI-based IDE (кто-то любит, кто-то хейтит, речь не об этом) - Cursor, Windsurf и тысячи их.
Появились MCP агенты, чаты и даже нейронки, умеющие в мульти контекст.
Баги правятся оперативно(возможно даже благодаря вайб-патч-кодингу).
А JetBrains остались в стороне. Не буду ругать за AI ассистента - он терпимый, работает на современном уровне, даже на gpt4o. Сами ответы ок, хоть и интерфейс/взаимодействие полный треш.
Меня больше расстроило, что долго исправляют баги и часто ломают своими релизами примерно всё.
DataGrip за последний год у меня ломался 8 раз.
Каждый сраный релиз новые болезни:
- открываешь БД, раскрываешь каталоги/таблицы/схемы - он крутится-крутится и потом херак - схлопывается. А он просто не показывает что есть внутри. Либо рестарт приложения, либо рефреш, пока он не покажет все таблицы снова.
- запускаешь кверю через едитор в монгу - а он просто терминейтит окошко, ну что такое
- подключаешься к трино, а он при больших кверях отжирает много CPU. Локально. Алё! Это воркеры, а не клиентская часть выполняет аналитический запрос! откуда нагрузка??
И так постоянно.
IDEA (и другие на самом деле IDE) тоже постоянно с багами.
- проблема с плагинами повсеместно - то YAML стандарт нарушает, то схему не так читает
- то плагины просто сломаны и месяцами(!) не фиксятся
Например в этом/том году месяцев 8 вроде ждал исправления.
Воркэраунд был такой
Дальнейший поиск вывел на чудесные комментарии к плагину
https://plugins.jetbrains.com/plugin/7808-terraform-and-hcl/reviews
и решение в виде
Settings -> Tools -> External tools
- add new
- name: "terraform fmt"
- program: "/path/to/terraform/binary"
- arguments: "fmt $FilePath$"
- save
Теперь ctrl+alt+L форматирует корректно.
Ну не песец, а? (они исправили и потом через несколько месяцев снова сломали по терраформу).
Writerside стал не актуальным с появлением context-based утилит и автогенерации документации, но и он пару раз какую-то херню выдавал, не помню уже.
В общем количество багов, неповоротливые долго запускающиеся (на wsl, на маке терпимо ок) IDE меня утомили.
Думаю не смогу продлить в этом году подписку, потеряю все последующие скидки, но я правда в этом году не вижу ни одного плюса у jetbrains. Мне кажется они перестали успевать за рынком и требованиями пользователей.
Жаль, IDEA была для меня легендарной IDE.❤️
Похоже время попрощаться со всем набором ПО от этих ребят, держаться за них лишь за скидки наверное ну такое, странное.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2😢2
#kubernetes #azure #aks #troubleshooting #argo #dapr #api
Ныряем в Azure AKS API.
Часть 1 из 2.
У нас болел кубернетис апи.
Болел долго, со вкусом.
Словно мужчина 30+ лет с температурой 37.2, с опекой рядом кудахтающей супруги.
Мы честно хотели его вылечить, но у меня лично никогда не было глубокого опыта дебага апи, часть команды было просто пофиг. Вроде работает? Хорошо. Бизнес, само собой, такими вещами и не интересуется.
Это вызывало массу сайд эффектов: 4 или 5 из моих историй это следствие загрузки K8S API.
Работа операторов, работа кеды и dcs демоушн.
Однажды мненадо было списать много времени по трекеру интересно разобраться с причиной.
Путь первый. Невежественность.
В кластере много компонентов, которые работают с кубернетес апи.
ArgoCD, Kyverno, десятки операторов. Много всего.
Первый мой шаг - поэтапно вырубать контроллеры
То есть я тупо один за одним вырубал какие-то компоненты.
и ждал. 30-60 минут, есть ли эффект.
Конечно же предупреждая коллег, и в случае необходимости тут же скейлил вверх.
Эта идея была тупая, я убил несколько часов/дней.
Никакого результата.
Путь второй. Наивность.
Дальше я выбрал путь наивности - ходил по приложениям, операторам и где мог, подкручивал параметры, чтобы обращения к АПИ был реже. Всякие реконсилейшн у арго, демоушн патрони, частота запросов кеда оператора и так далее.
Помогло ли это? Нет. Стало ли лучше? Глобально - да, ведь я просто оттюнил к лучшему.
К пункту наивности я бы добавил все мои попытки разобраться "что не так с апи по метрикам".
Метрики никак и никогда не дают информации кто же даёт основную нагрузку.
Путь третий. Просветление.
Очевидно предыдущие попытки были унылы и тупы.
Почитал интернет, нейронки, документацию.
Первым делом включаю аудит-лог.
Azure-Kubernetes-Monitoring-Diagnostic settings.
Дальше включаю для Kubernetes API и сохранение в Log Analytics workspace.
Сохраняю, иду в
Там выбираю Logs и ищу сперва все ошибки.
Вижу кучу ошибок.
Ок, начнем с рандом частой ошибки:
Не заостряю внимание на продукте, мне он знаком (можно почитать на https://github.com/dapr/dapr/).
По ошибке проблема сервиса(хоть и странный адрес), а есть ли он?
Он есть.
Почему возникает эта ошибка?Сперва смотрю валуес
Нет ничего интересно, как и в нашем values файле.
Иду в чарт и качаю его к себе https://github.com/dapr/helm-charts/blob/master/dapr-1.14.2.tgz
Вижу кучу темплейтов, хелперсов, CRD.
В CRD указано, что сам оператор реплейсит CRD.
То есть оператор время от времени должен реплейсить неймспейс внутри CRD с
А он не реплейсит. Хорошо, меняю сам руками, смотрю результат.
Радуюсь, иду в логи - а там снова ошибка.
Непонятно. Возвращаюсь обратно а там
Да камон.
Ныряем в Azure AKS API.
Часть 1 из 2.
У нас болел кубернетис апи.
Болел долго, со вкусом.
Словно мужчина 30+ лет с температурой 37.2, с опекой рядом кудахтающей супруги.
Мы честно хотели его вылечить, но у меня лично никогда не было глубокого опыта дебага апи, часть команды было просто пофиг. Вроде работает? Хорошо. Бизнес, само собой, такими вещами и не интересуется.
Это вызывало массу сайд эффектов: 4 или 5 из моих историй это следствие загрузки K8S API.
Работа операторов, работа кеды и dcs демоушн.
Однажды мне
Путь первый. Невежественность.
В кластере много компонентов, которые работают с кубернетес апи.
ArgoCD, Kyverno, десятки операторов. Много всего.
Первый мой шаг - поэтапно вырубать контроллеры
То есть я тупо один за одним вырубал какие-то компоненты.
kubectl scale --replicas 0 sts/name
kubectl scale --replicas 0 deploy/name
и ждал. 30-60 минут, есть ли эффект.
Конечно же предупреждая коллег, и в случае необходимости тут же скейлил вверх.
Эта идея была тупая, я убил несколько часов/дней.
Никакого результата.
Путь второй. Наивность.
Дальше я выбрал путь наивности - ходил по приложениям, операторам и где мог, подкручивал параметры, чтобы обращения к АПИ был реже. Всякие реконсилейшн у арго, демоушн патрони, частота запросов кеда оператора и так далее.
Помогло ли это? Нет. Стало ли лучше? Глобально - да, ведь я просто оттюнил к лучшему.
К пункту наивности я бы добавил все мои попытки разобраться "что не так с апи по метрикам".
Метрики никак и никогда не дают информации кто же даёт основную нагрузку.
Путь третий. Просветление.
Очевидно предыдущие попытки были унылы и тупы.
Почитал интернет, нейронки, документацию.
Первым делом включаю аудит-лог.
Azure-Kubernetes-Monitoring-Diagnostic settings.
Дальше включаю для Kubernetes API и сохранение в Log Analytics workspace.
Сохраняю, иду в
Log Analytics workspace.Там выбираю Logs и ищу сперва все ошибки.
AKSControlPlane
| where Category == "kube-apiserver" and Level == "ERROR"
| limit 40
| project TimeGenerated, Level, Message
Вижу кучу ошибок.
Ок, начнем с рандом частой ошибки:
cacher (subscriptions.dapr.io): unexpected ListAndWatch error: failed to list dapr.io/v1alpha1, Kind=Subscription: conversion webhook for dapr.io/v2alpha1, Kind=Subscription failed: Post "https://dapr-webhook.replaceme.svc:443/convert?timeout=30s": service "dapr-webhook" not found; reinitializing...
Не заостряю внимание на продукте, мне он знаком (можно почитать на https://github.com/dapr/dapr/).
По ошибке проблема сервиса(хоть и странный адрес), а есть ли он?
kubectl get svc -n dapr-system | grep webhook
dapr-webhook ClusterIP 10.0.12.141 <none> 443/TCP
Он есть.
Почему возникает эта ошибка?Сперва смотрю валуес
helm show values dapr/dapr --version 1.14.2
Нет ничего интересно, как и в нашем values файле.
Иду в чарт и качаю его к себе https://github.com/dapr/helm-charts/blob/master/dapr-1.14.2.tgz
Вижу кучу темплейтов, хелперсов, CRD.
В CRD указано, что сам оператор реплейсит CRD.
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
...
spec:
group: dapr.io
conversion:
strategy: Webhook
webhook:
clientConfig:
service:
namespace: replaceme # Patched by post-install webhook
То есть оператор время от времени должен реплейсить неймспейс внутри CRD с
replaceme на реальный dapr-system.А он не реплейсит. Хорошо, меняю сам руками, смотрю результат.
kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: dapr-system
Радуюсь, иду в логи - а там снова ошибка.
Непонятно. Возвращаюсь обратно а там
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: replaceme
Да камон.
👍8
#kubernetes #azure #aks #troubleshooting #argo #dapr #api
Часть 2 из 2.
Думаю ну может я дурак, Меняю снова, уже не иду в логи, А проверяю на месте.
И картина там такая:
Бррр, как такое возможно.
Иду в гугл, нейронку, мне говорят "а ты посмотри - кто последний то меняет объект?".
Смотрю
Пффф, а арго то тут причем?
Снова меняю, снова смотрю - да, арго меняет обратно неймспейс на дефолт.
Иду в репозиторий арго, но там просто
Ну и
А больше мы ничего не меняем.
Снова документация, гугл.
Оказалось вот что:
- арго выкачивает ВЕСЬ чарт, внутри есть директория CRD и там внутри дефолт(путь к чарту был выше, внутри есть CRD директория с манифестами).
Промежуточное описание проблемы:
каждый N период времени оператор DAPR меняет namespace в CRD, тут же сам applicationset DAPR переходит в OutOfSync, арго начинает резко синкать, подтягивает весь чарт, видит, что поменялся CRD и меняет на дефолт. И так по кругу. Насилие ради насилия.
Я и коллега начали фиксить это несколькими вариантами через
Затем снова руками меняю неймспейс, смотрю - ура.
Неймспейс больше не ревратится, в аудит логе АПИ ошибки(этой) больше нет.
Да, арго больше не меняет.
Нагрузку снизили на ... на 4%. Мало, но уже что-то.
Выключаю аудит лог(он оооооооооочень дорогой), закрываю одну из саб-тасок касательно АПИ.
Ещё раз описание ишшуи:
- задеплоили арго аппликейшнсет через сторонний чарт с DAPR
- арго создаёт все сущности через хелмп темплейт (даже те, о которых мы в явном виде не знали)
- затем вебхук от оператора дапр переписывает CRD
- арго при синке видит дифф по CRD и переписывыает его снова
- и так по кругу
Пока не глянешь в кишки и не добавишь в игнор - насилие над апи кубера, так как весь функционал арго и дапра - через кубер апи.
Итог:
- я научился смотреть в логи аудита по Azure AKS API
- сгорел от дурости DAPR оператора и ArgoCD оператора в попытках переписать друг за другом CRD
- узнал про игноры в арго (вообще есть и иные решения для проблемы, но игнор самый простой)
- снизил нагрузку на 4% лишь с одним фиксом
Впереди ещё несколько подходов к апи, есть десятки других ошибок, буду с каждой разбираться отдельно.
Это оказалось интересно.
Часть 2 из 2.
Думаю ну может я дурак, Меняю снова, уже не иду в логи, А проверяю на месте.
И картина там такая:
kubectl edit crd subscriptions.dapr.io
customresourcedefinition.apiextensions.k8s.io/subscriptions.dapr.io edited
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: dapr-system
kubectl get crd subscriptions.dapr.io -o yaml | grep namespace
namespace: replaceme
Бррр, как такое возможно.
Иду в гугл, нейронку, мне говорят "а ты посмотри - кто последний то меняет объект?".
Смотрю
kubectl get crd subscriptions.dapr.io -o jsonpath='{.metadata.managedFields[*].manager}' | tr ' ' '\n' | sort | uniq -c
1 argocd-controller
1 kube-apiserver
1 kubectl-edit
1 operatorПффф, а арго то тут причем?
Снова меняю, снова смотрю - да, арго меняет обратно неймспейс на дефолт.
Иду в репозиторий арго, но там просто
---
name: dapr
namespace: dapr-system
repoURL: https://dapr.github.io/helm-charts/
targetRevision: 1.14.2
chart: dapr
Ну и
applicationset есть.А больше мы ничего не меняем.
Снова документация, гугл.
Оказалось вот что:
- арго выкачивает ВЕСЬ чарт, внутри есть директория CRD и там внутри дефолт(путь к чарту был выше, внутри есть CRD директория с манифестами).
Промежуточное описание проблемы:
каждый N период времени оператор DAPR меняет namespace в CRD, тут же сам applicationset DAPR переходит в OutOfSync, арго начинает резко синкать, подтягивает весь чарт, видит, что поменялся CRD и меняет на дефолт. И так по кругу. Насилие ради насилия.
Я и коллега начали фиксить это несколькими вариантами через
applicationset, типа---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
...
template:
...
spec:
...
ignoreDifferences:
...
- group: apiextensions.k8s.io
kind: CustomResourceDefinition
name: subscriptions.dapr.io
jqPathExpressions:
- .spec.conversion.webhook.clientConfig.service.namespace
Затем снова руками меняю неймспейс, смотрю - ура.
Неймспейс больше не ревратится, в аудит логе АПИ ошибки(этой) больше нет.
Да, арго больше не меняет.
Нагрузку снизили на ... на 4%. Мало, но уже что-то.
Выключаю аудит лог(он оооооооооочень дорогой), закрываю одну из саб-тасок касательно АПИ.
Ещё раз описание ишшуи:
- задеплоили арго аппликейшнсет через сторонний чарт с DAPR
- арго создаёт все сущности через хелмп темплейт (даже те, о которых мы в явном виде не знали)
- затем вебхук от оператора дапр переписывает CRD
- арго при синке видит дифф по CRD и переписывыает его снова
- и так по кругу
Пока не глянешь в кишки и не добавишь в игнор - насилие над апи кубера, так как весь функционал арго и дапра - через кубер апи.
Итог:
- я научился смотреть в логи аудита по Azure AKS API
- сгорел от дурости DAPR оператора и ArgoCD оператора в попытках переписать друг за другом CRD
- узнал про игноры в арго (вообще есть и иные решения для проблемы, но игнор самый простой)
- снизил нагрузку на 4% лишь с одним фиксом
Впереди ещё несколько подходов к апи, есть десятки других ошибок, буду с каждой разбираться отдельно.
Это оказалось интересно.
1❤10👍7🔥5
#kubernetes
Тупости и лени пост.
Иногда бывает такое, что кластер обновился, развалился, автоматически секьюрити апдейтнулся(аригато, Azure), руками апгрейднулся(аригато, AWS, за принудительно-добровольные апгрейды, иначе денег-денег-денег дай).
Всё тоже самое, но с релизами приложений.
Выбрать любое.
После этого события у нас иногда сразу многое не работает и прилетает куча разных алёртов, ошибок, миллион ивентов.
Побуду бесплатным адвокатом AWS, такое крайне редко, чаще в Azure проблемы.
Проблема: в моменте не очень понятно - а куда вообще смотреть, чего чинить первым?
1) Я сразу по заранее сохранённой ссылке в
Фильтр
Ссылка формата
+ есть аналог дашборда в графане, но по привычке лезу сразу в
Grafana красивее, нагляднее и удобнее, но привычка дело такое.
Тут ничего для всех нового, но алертов СЛИШКОМ много. Надо как-отфильтровать последнее.
2) Иду в кластер(ы) и одним махом очищаю всё, что мне помешает Быстрой диагностике.
Да, я знаю потенциальные последствия, на 100% их понимаю, что делают команды.
У меня есть алиасы формата
Я прям иногда ввожу
Что это даёт мне:
- все подвисшие/unknown/комплетед/файлед и так далее поды уходят в небытие и мне просто глазами визуально удобнее следить/чинить то, что надо, а не что исторически не релевантно
- все файлед джобы от кронджобов подчищаются и перестают лететь тонны алертов о незавершенных джобах.
Цель: быстро избавить визуальное пространство от "мусорных" исторических алертов и failed объектов, чтобы быстрее найти и починить главное и актуальное.
3) При необходимости смотрю ивенты, с фильтром по времени и не нормал северити
4) Снова иду в графану/алертменеджер, смотрю, что осталось(обычно 90-95% шума улетает сразу) и чиню релевантное оставшееся.
Минусы подхода должны быть очевидны опытным инженерам и совсем не очевидны для начинаюших специалистов.
Для никому не нужной интриги минусы под спойлер.
- если у нас не собираются где-то все ивенты и логи, то мы теряем историю и причины, почему был failed, unknown, crashloopback etc. Если всё логируется, то пофиг, разве что exit code/reason мы не увидим(а оно нам надо? итак видно, что кластер обновился).
- если у нас есть velero ( https://velero.io/ ), то есть не иллюзорный шанс проетерять потенциальные бекапы. Например POD velero висел в pending, ожидая ресурсов(или иная причина), а я его убиваю.
Значит бекап, который должен был запуститься, будет запущен при следующем расписании. А сейчас его не будет.
В пендинге он может висеть, например, потому что разом запустилось по расписанию 100500 подов бекапа и упираемся(временно) в количество PVC/disk на ноде/нехватка нод во время апдейта.
Спустя время это проходит, но мои действия потенциально убивают штатный бекап.
С велеро я беру все риски на себя, осознавая, что он скоро (пере)запуститься и бекап будет готов. Так же у нас есть алерты по велеро, так что мне ок.
Возможно стоит переделать алиасы, добавив xargs и добавив в игнор велеро, но пока руки не дошли.
Да и не так часто такие ситуации бывают.
Тупости и лени пост.
Иногда бывает такое, что кластер обновился, развалился, автоматически секьюрити апдейтнулся(аригато, Azure), руками апгрейднулся(аригато, AWS, за принудительно-добровольные апгрейды, иначе денег-денег-денег дай).
Всё тоже самое, но с релизами приложений.
Выбрать любое.
После этого события у нас иногда сразу многое не работает и прилетает куча разных алёртов, ошибок, миллион ивентов.
Побуду бесплатным адвокатом AWS, такое крайне редко, чаще в Azure проблемы.
Проблема: в моменте не очень понятно - а куда вообще смотреть, чего чинить первым?
1) Я сразу по заранее сохранённой ссылке в
alertmanager, где стоит фильтр по кластеру(ам) и, иногда severity.Фильтр
cluster=~".*prod.*"Ссылка формата
+ есть аналог дашборда в графане, но по привычке лезу сразу в
alertmanager.Grafana красивее, нагляднее и удобнее, но привычка дело такое.
Тут ничего для всех нового, но алертов СЛИШКОМ много. Надо как-отфильтровать последнее.
2) Иду в кластер(ы) и одним махом очищаю всё, что мне помешает Быстрой диагностике.
Да, я знаю потенциальные последствия, на 100% их понимаю, что делают команды.
У меня есть алиасы формата
alias kkndp="k delete pod --field-selector 'status.phase!=Running' -A --force"
alias kkndj="kubectl delete jobs --all-namespaces --field-selector status.successful=0"
Я прям иногда ввожу
kkndp && kkndj в шелле.Что это даёт мне:
- все подвисшие/unknown/комплетед/файлед и так далее поды уходят в небытие и мне просто глазами визуально удобнее следить/чинить то, что надо, а не что исторически не релевантно
- все файлед джобы от кронджобов подчищаются и перестают лететь тонны алертов о незавершенных джобах.
Цель: быстро избавить визуальное пространство от "мусорных" исторических алертов и failed объектов, чтобы быстрее найти и починить главное и актуальное.
3) При необходимости смотрю ивенты, с фильтром по времени и не нормал северити
alias kwe="k get events -A --sort-by='.metadata.creationTimestamp' | grep -v Normal"
4) Снова иду в графану/алертменеджер, смотрю, что осталось(обычно 90-95% шума улетает сразу) и чиню релевантное оставшееся.
Минусы подхода должны быть очевидны опытным инженерам и совсем не очевидны для начинаюших специалистов.
Для никому не нужной интриги минусы под спойлер.
- если у нас есть velero (
Значит бекап, который должен был запуститься, будет запущен при следующем расписании. А сейчас его не будет.
В пендинге он может висеть, например, потому что разом запустилось по расписанию 100500 подов бекапа и упираемся(временно) в количество PVC/disk на ноде/нехватка нод во время апдейта.
Спустя время это проходит, но мои действия потенциально убивают штатный бекап.
С велеро я беру все риски на себя, осознавая, что он скоро (пере)запуститься и бекап будет готов. Так же у нас есть алерты по велеро, так что мне ок.
Возможно стоит переделать алиасы, добавив xargs и добавив в игнор велеро, но пока руки не дошли.
Да и не так часто такие ситуации бывают.
1👍11❤2
#ocr #ats #cv #ai #ASCII #PDF
Возможно кто-то из инженеров сейчас сидит и не может найти работу, потому что его CV в PDF файле не могут распарсить AI боты и ATS. Банальный баг и невнимательность.
Внезапно узнал, что если вы, как и я, создаёте шаблон CV в MS Word, а потом сохраняете как PDF, то есть бага.
Word -> print as PDF = ❌ non-ASCII characters
Word -> save as PDF = ✅ всё ок (кроме сраных длинных типографских тире)
С печатью в PDF, например, вместо сочетания
Ровно как и все типы минусов/дефис/тире (их вроде около 5-6 типов).
Быстро советы:
- НЕ используйте печать как PDF для сохранения документа
- сделал PDF(любым способом) - открыл PDF - выделил всё ctrl+A - скопировал ctrl+c - вставил на странице https://pages.cs.wisc.edu/~markm/ascii.html - и так до тех пор, пока не будет спецсимволов.
Сейчас всё обрабатывают роботы при первичном скрининге.
Дайте роботам шанс дотащить ваш CV хотя бы до HR, сделайте его читаемым.❤️
Ссылки на почитать(опционально):
- https://pages.cs.wisc.edu/~markm/ascii.html
- https://my.onu.edu/sites/default/files/applicant_tracking_system_resume_guide.pdf
- https://careerservices.uic.edu/wp-content/uploads/sites/26/2017/08/Ensure-Your-Resume-Is-Read-ATS.pdf
- https://drive.google.com/file/d/1X5pOmi-s_ZIKPkKsVVElWhSjv80ihyS5/view
Возможно кто-то из инженеров сейчас сидит и не может найти работу, потому что его CV в PDF файле не могут распарсить AI боты и ATS. Банальный баг и невнимательность.
Внезапно узнал, что если вы, как и я, создаёте шаблон CV в MS Word, а потом сохраняете как PDF, то есть бага.
Word -> print as PDF = ❌ non-ASCII characters
Word -> save as PDF = ✅ всё ок (кроме сраных длинных типографских тире)
С печатью в PDF, например, вместо сочетания
TI/ti будет спецсимвол.documenta�on, suppor�ng, GitHub Ac�ons
Ровно как и все типы минусов/дефис/тире (их вроде около 5-6 типов).
Быстро советы:
- НЕ используйте печать как PDF для сохранения документа
- сделал PDF(любым способом) - открыл PDF - выделил всё ctrl+A - скопировал ctrl+c - вставил на странице https://pages.cs.wisc.edu/~markm/ascii.html - и так до тех пор, пока не будет спецсимволов.
Сейчас всё обрабатывают роботы при первичном скрининге.
Дайте роботам шанс дотащить ваш CV хотя бы до HR, сделайте его читаемым.❤️
Ссылки на почитать(опционально):
- https://pages.cs.wisc.edu/~markm/ascii.html
- https://my.onu.edu/sites/default/files/applicant_tracking_system_resume_guide.pdf
- https://careerservices.uic.edu/wp-content/uploads/sites/26/2017/08/Ensure-Your-Resume-Is-Read-ATS.pdf
- https://drive.google.com/file/d/1X5pOmi-s_ZIKPkKsVVElWhSjv80ihyS5/view
5❤14👍6👾3🔥2
#argocd #gitops
В рамках самостоятельной профессиональной регулярной переподготовки поработал пару ночей над ArgoCD https://argo-cd.readthedocs.io/
Вообще я с ним давно работаю, всё умею, вношу правки, добавляю новые аппликейшны/аппликейшнсеты, траблшутю и вообще всё понятно.
Но что, если всё поднять с нуля и не подглядывать за ранее написанным кодом?
Насколько сильно обделаюсь в свои портки за 40 грошей?
Задача простая: есть тестовая организация в GitHub, внутри 3 тестовых репозитория с 3 микросервисами, 1 репозиторий с универсальным helm chart, который подходит всем 3 тестовым микросервисам, 1 репозиторий argocd с манифестами Application + Application Set. Всё сделать сперва на мастер ветке, потом по тегам докер имиджа.
Мы стильные молодёжные, так что сразу с SSO авторизацией.
Есть тестовый(студенческий) аккаунт MS Azure + MS Entra.
Финишем добавить пару общий хелмчартов, ну не знаю, допустим прометиус стек, так же через арго.
Признаюсь, первые часа два я дичайше тупил.🚬
Сперва долго тупил с SSO. Потом орнул с разделения админ центра/enterprise applications/app service.
Ок, авторизацию прикрутил и это хорошо.
Потом долго пытался понять а как вообще цеплять репозитории к арго серверу.
Все валуес файлы делать в каждом репозитории? Или все валуес файлы хранить в репах с аппликейшнсетами?
Аппликейшн или аппликейшнсеты пилить? С учётом на рост(теории).
Если валуес хранить в репозиториях микросервисах, получается мне надо каждый из них внести по отдельности вместе с кредами? А как лучше - через https или git? А как проходит авторизация с гитом?
В итоге сделал через PAT GitHub и логин git (внезапно).
Ладно, репы подключил, но что если я всё ещё хочу валуес файлы хранить в репе с сервисам, а не в арго репе - мне все репы отдельно подключать надо?? Это же бред. Потом прочитал(и спросил у коллеги) про креденшл темплейт, что облегчило мою задачу, ведь всё в одной организации гитхаба. Не надо каждый подключать, очень удобно.
С репами вроде закончил.
Затем я перечитал десятки страниц документации, всякие how to/get started etc.
А у меня ничего не получалось.
Просто не было понимания как стартовать с нуля.
Вроде вот всё понятно: вот репы, вот чарт, вот аппликейшнсет, сейчас будет
Не хватало какого-то краеугольного куска гранита для понимания что не так.
В общем просто "изначальный" аппликешйн, который должен играть роль init/controller/bootstrap/App-of-Apps/mainapp (назвать как удобно), который и указывает аргохе куда смотреть на основные аппликейшнсеты...надо создавать руками через
Я не нашёл иных способов, как изначальную инициацию сделать без разового ввода команды.
Ок, это заработало, засинкалось. Появились аппликейшн сеты, пробовал добавить ещё, новые репы и так далее. Всё заработало.
Потом я ковырялся в реконселейшн арго, так как k8s кластер тестовый, free tier и его апишку просто ломало полностью от 8 приложений(+5 от чартов).
Вернулся к ролевой модели, поковырялся кто может видеть логи, кто может делать рестарт подов и удалять ресурсы, тоже потратил время.
В общем и целом задача закрыта - поднял всё с нуля. Не удивлюсь, что где-то сделал глупо, но идеально и не стояло задачи.
Увлекательное время.
Закрыл несколько пробелов в знаниях, освежил старые знаний.
Всё же одно дело работать с инструментом, который я либо настроил давно, либо вообще делали без меня, другое дело поднять всё с нуля.
В рамках самостоятельной профессиональной регулярной переподготовки поработал пару ночей над ArgoCD https://argo-cd.readthedocs.io/
Вообще я с ним давно работаю, всё умею, вношу правки, добавляю новые аппликейшны/аппликейшнсеты, траблшутю и вообще всё понятно.
Но что, если всё поднять с нуля и не подглядывать за ранее написанным кодом?
Насколько сильно обделаюсь в свои портки за 40 грошей?
Задача простая: есть тестовая организация в GitHub, внутри 3 тестовых репозитория с 3 микросервисами, 1 репозиторий с универсальным helm chart, который подходит всем 3 тестовым микросервисам, 1 репозиторий argocd с манифестами Application + Application Set. Всё сделать сперва на мастер ветке, потом по тегам докер имиджа.
Мы стильные молодёжные, так что сразу с SSO авторизацией.
Есть тестовый(студенческий) аккаунт MS Azure + MS Entra.
Финишем добавить пару общий хелмчартов, ну не знаю, допустим прометиус стек, так же через арго.
Признаюсь, первые часа два я дичайше тупил.
Сперва долго тупил с SSO. Потом орнул с разделения админ центра/enterprise applications/app service.
Ок, авторизацию прикрутил и это хорошо.
Потом долго пытался понять а как вообще цеплять репозитории к арго серверу.
Все валуес файлы делать в каждом репозитории? Или все валуес файлы хранить в репах с аппликейшнсетами?
Аппликейшн или аппликейшнсеты пилить? С учётом на рост(теории).
Если валуес хранить в репозиториях микросервисах, получается мне надо каждый из них внести по отдельности вместе с кредами? А как лучше - через https или git? А как проходит авторизация с гитом?
В итоге сделал через PAT GitHub и логин git (внезапно).
Ладно, репы подключил, но что если я всё ещё хочу валуес файлы хранить в репе с сервисам, а не в арго репе - мне все репы отдельно подключать надо?? Это же бред. Потом прочитал(и спросил у коллеги) про креденшл темплейт, что облегчило мою задачу, ведь всё в одной организации гитхаба. Не надо каждый подключать, очень удобно.
С репами вроде закончил.
Затем я перечитал десятки страниц документации, всякие how to/get started etc.
А у меня ничего не получалось.
Просто не было понимания как стартовать с нуля.
Вроде вот всё понятно: вот репы, вот чарт, вот аппликейшнсет, сейчас будет
????? и ???? и всё заработает.Не хватало какого-то краеугольного куска гранита для понимания что не так.
В общем просто "изначальный" аппликешйн, который должен играть роль init/controller/bootstrap/App-of-Apps/mainapp (назвать как удобно), который и указывает аргохе куда смотреть на основные аппликейшнсеты...надо создавать руками через
kubectl apply -f init.yamlЯ не нашёл иных способов, как изначальную инициацию сделать без разового ввода команды.
Ок, это заработало, засинкалось. Появились аппликейшн сеты, пробовал добавить ещё, новые репы и так далее. Всё заработало.
Потом я ковырялся в реконселейшн арго, так как k8s кластер тестовый, free tier и его апишку просто ломало полностью от 8 приложений(+5 от чартов).
Вернулся к ролевой модели, поковырялся кто может видеть логи, кто может делать рестарт подов и удалять ресурсы, тоже потратил время.
В общем и целом задача закрыта - поднял всё с нуля. Не удивлюсь, что где-то сделал глупо, но идеально и не стояло задачи.
Увлекательное время.
Закрыл несколько пробелов в знаниях, освежил старые знаний.
Всё же одно дело работать с инструментом, который я либо настроил давно, либо вообще делали без меня, другое дело поднять всё с нуля.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍17
#azure #billing #truedevops #sql #ai
Меня вдохновили одной историей-задачей от коллеги, но расскажу всё от своего имени, а что вы мне сделаете, заметки то мои🤣
На мой личный взгляд это потрясающая работа сильного, профессионального и изобретательного инженера.
Была подзадача "перетащить часть проекта с Azure stack на Bare metal".
С платформой и стеком выбор был уже почти сделан, надо было лишь развернуть инфру и перетащить данные.
Инфру развернули за 0.0001мс - мы же все гитопсы теперь.
С данными вышла засада - их было 330+ терабайт. И это лишь в одном блобе. Блобов много.
Мы были не готовы к таким цифрам в bare metal и это пахло проблемами.
И капасити и скорость передачи данных в бар метал - это сколько недель ждать?
Решили вообще узнать - а все ли данные нужны?
Зашли к девелоперам по
Это отличный пойнт, а значит время для анализа.
Базово ажур ничего не даёт по аналитике, либо за деньги, а потому надо всё включать.
Первым делом включили
Ок, у нас есть миллионы строчек, но сами же мы не будем глазами считать.
Создаём локально базу данных
Затем создаём табличку типа (тут есть ошибки, но это не влияет на саму задачу)
https://gist.github.com/kruchkov-alexandr/9f1210db954c92b059113835e950562e
Запускаем
Данные по объектам в блобе, а значит пора мучать любимый AI ассистент SQL запросами, нечто типа
https://gist.github.com/kruchkov-alexandr/73096e1a8a78274944dcb3c02c45f090
Оба запроса собирают статистику по контейнерам blob, считая количество файлов и их суммарный размер в GiB, также выводят общий итог по всем контейнерам.
Возвращаемся к девелоперам, показываем статистику, анализ, все в шоке, срочный колл, разбор полётов.
Не буду опускаться в суть бизнес процессов, почему и где была логическая проблема, но в общем у нас был сбой
и данные дублировались. Трижды всё проверили, расписали план и двинулись дальше:
- удалили часть данных
- включили лайфсайкл полиси на 1 день
- выключили safe delete или как это называется
- что-то ещё, но я уже не помню
В общем на момент истории блоб весит 44 терабайта, удалено больше 280 терабайт.
Какие же потери мы понесли с момента бага с дублированием?
- чтение/перечтение данных каждый день
- операции
- хранение
Итого $3500+ в месяц. За один только блоб.
Просто три с половиной шутки за мусорную дату каждый месяц....
Дальше создали задачи по всем энвайронментам пройтись, по всем стораджам, сделать такой же анализ и сходить по командам за уточнением процессинга и хранения даты, чтобы везде снизить косты, раз уж у нас был один инцидент.
Да, компания специализируется на дате, её очень много, и само собой никто уже с огромными объемами не мониторил банальный сбой и дублирование / версионирование / сейфделиты / редубликацию трафика на ингрессе и так далее. Когда данных петабайты, особо не следишь где чего и сколько. Всем кажется, что это нормально.
Итоги:
-коллега я, крутой и мощщный синёр помидор, показал всем, как делать аналитику сотен миллионов объектов в блобе
- узнали о величайшем(нет) провале по мониторингу биллинга и размера даты
- на момент стори снизили косты на $3500+ в месяц😭 Точная сумма будет известно потом, когда завершаться все работы по всем стораджам, а их не мало.
- отчасти сняли блокер по переносу даты в барметал (нет, но это другая история)
Меня вдохновили одной историей-задачей от коллеги, но расскажу всё от своего имени, а что вы мне сделаете, заметки то мои
На мой личный взгляд это потрясающая работа сильного, профессионального и изобретательного инженера.
Была подзадача "перетащить часть проекта с Azure stack на Bare metal".
С платформой и стеком выбор был уже почти сделан, надо было лишь развернуть инфру и перетащить данные.
Инфру развернули за 0.0001мс - мы же все гитопсы теперь.
С данными вышла засада - их было 330+ терабайт. И это лишь в одном блобе. Блобов много.
Мы были не готовы к таким цифрам в bare metal и это пахло проблемами.
И капасити и скорость передачи данных в бар метал - это сколько недель ждать?
Решили вообще узнать - а все ли данные нужны?
Зашли к девелоперам по
datawarehouse стеку, они сказали нечто типа "ну мы, конечно же, компания, специализирующая на данных, данных у нас ОЧЕНЬ много, но цифра не похожа на настоящую".Это отличный пойнт, а значит время для анализа.
Базово ажур ничего не даёт по аналитике, либо за деньги, а потому надо всё включать.
Первым делом включили
Inventory - специальный инструмент, позволяющий получать отчёт о всех данных внутри блоба. Запустили, сутки ждали, он сформировался в CSV файле, вроде около 150 мегабайт.Ок, у нас есть миллионы строчек, но сами же мы не будем глазами считать.
Создаём локально базу данных
PostgreSQL.Затем создаём табличку типа (тут есть ошибки, но это не влияет на саму задачу)
https://gist.github.com/kruchkov-alexandr/9f1210db954c92b059113835e950562e
Запускаем
DBeaver и импортируем CSV файл в это локальную базу данных PostgreSQL.Данные по объектам в блобе, а значит пора мучать любимый AI ассистент SQL запросами, нечто типа
https://gist.github.com/kruchkov-alexandr/73096e1a8a78274944dcb3c02c45f090
Оба запроса собирают статистику по контейнерам blob, считая количество файлов и их суммарный размер в GiB, также выводят общий итог по всем контейнерам.
Возвращаемся к девелоперам, показываем статистику, анализ, все в шоке, срочный колл, разбор полётов.
Не буду опускаться в суть бизнес процессов, почему и где была логическая проблема, но в общем у нас был сбой
и данные дублировались. Трижды всё проверили, расписали план и двинулись дальше:
- удалили часть данных
- включили лайфсайкл полиси на 1 день
- выключили safe delete или как это называется
- что-то ещё, но я уже не помню
В общем на момент истории блоб весит 44 терабайта, удалено больше 280 терабайт.
Какие же потери мы понесли с момента бага с дублированием?
- чтение/перечтение данных каждый день
- операции
- хранение
Итого $3500+ в месяц. За один только блоб.
Просто три с половиной шутки за мусорную дату каждый месяц....
Дальше создали задачи по всем энвайронментам пройтись, по всем стораджам, сделать такой же анализ и сходить по командам за уточнением процессинга и хранения даты, чтобы везде снизить косты, раз уж у нас был один инцидент.
Да, компания специализируется на дате, её очень много, и само собой никто уже с огромными объемами не мониторил банальный сбой и дублирование / версионирование / сейфделиты / редубликацию трафика на ингрессе и так далее. Когда данных петабайты, особо не следишь где чего и сколько. Всем кажется, что это нормально.
Итоги:
-
- узнали о величайшем(нет) провале по мониторингу биллинга и размера даты
- на момент стори снизили косты на $3500+ в месяц
- отчасти сняли блокер по переносу даты в барметал (нет, но это другая история)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20🔥5❤1😁1
#пятница #байки #troubleshooting
Задолго до работы в айти я был простым советским инженером спутниковой связи.
Тарелки, антенны, модемы, кабели, бесконечные командировки. В то время случалось масса странных историй.
Мы разрабатывали спутниковое оборудование - модем.
Ну, типа коробочка: в один конец втыкается ethernet, в другой - кабель для спутниковой антенны. Если объяснять совсем упрощённо.
Однажды поступил сигнал, что в одном месте, куда мы поставляли железо, периодически перестаёт работать связь. Там уже меняли всё: и внешнее оборудование (LNB, передатчик), и кабели, и внутреннее - модемы и блоки питания. Не помогало.
Основная гипотеза была: враги, конкуренты или радиолюбители мешают на спутнике.
Короче, время от времени канал тупил.
Худшая гипотеза - наше оборудование овно, а это тревожный звонок для бизнеса.
Сначала я пытался разобраться удалённо.
Соорудил наспех snmp-monitoring-схему, даже просил людей записывать на бумажке время, когда "глючит". Получилось, что срывы происходят утром, днём и вечером - плюс-минус в одно и то же время.
Но удалённо разобраться не вышло.
А это клиенты, так что надо было срочно решать проблему.
В итоге меня отправили в командировку на три дня.
Меня поселили в гостинице рядом, но на саму территорию связи просто так не пускали.
Утром провели внутрь для диагностики.
Я весь день таскался со своим измерительным оборудованием (два ящика, кстати!), слонялся туда‑сюда, выглядел, наверное, как идиот-“следящий”. Но одного дня мне хватило.
К концу первого дня я понял, в чём дело.
За стеной пункта связи оказалось другое помещение - кухня.
Там сотрудники по утрам грели еду, потому что дома не успевали.
Включали самую паршивую китайскую микроволновку, которая фонит во всех, бл… диапазонах - даже в L band!
Излучение пробивало стену и било прямо по стойке с оборудованием.
Влиял не только наш модем, но и соседнее железо, просто про это никто даже не догадывался.
Днём они грели обед, вечером - кофе.
Я поставил анализаторы, показал сотрудникам и начальнику графики и реальные замеры.
Для чистоты эксперимента включал микроволновку и демонстрировал, как ровно в этот момент садится спутниковый сигнал.
После этого микроволновку перестали включать - и все проблемы исчезли.
Я добавил, что если все они не хотят получить рак через полгода, то пусть заменят это дерьмо на нормальное оборудование.
Народ так перепугался, что рванул на кухню и выкинул микроволновку ещё до того, как я закончил проверку и вышел из кабинета.
Оставшееся время командировки я гулял по местному лесу и думал о том, сколько таких дешевых микроволновок по всему миру, и как редко рядом оказывается человек с анализатором.
Задолго до работы в айти я был простым советским инженером спутниковой связи.
Тарелки, антенны, модемы, кабели, бесконечные командировки. В то время случалось масса странных историй.
Мы разрабатывали спутниковое оборудование - модем.
Ну, типа коробочка: в один конец втыкается ethernet, в другой - кабель для спутниковой антенны. Если объяснять совсем упрощённо.
Однажды поступил сигнал, что в одном месте, куда мы поставляли железо, периодически перестаёт работать связь. Там уже меняли всё: и внешнее оборудование (LNB, передатчик), и кабели, и внутреннее - модемы и блоки питания. Не помогало.
Основная гипотеза была: враги, конкуренты или радиолюбители мешают на спутнике.
Короче, время от времени канал тупил.
Худшая гипотеза - наше оборудование овно, а это тревожный звонок для бизнеса.
Сначала я пытался разобраться удалённо.
Соорудил наспех snmp-monitoring-схему, даже просил людей записывать на бумажке время, когда "глючит". Получилось, что срывы происходят утром, днём и вечером - плюс-минус в одно и то же время.
Но удалённо разобраться не вышло.
А это клиенты, так что надо было срочно решать проблему.
В итоге меня отправили в командировку на три дня.
Меня поселили в гостинице рядом, но на саму территорию связи просто так не пускали.
Утром провели внутрь для диагностики.
Я весь день таскался со своим измерительным оборудованием (два ящика, кстати!), слонялся туда‑сюда, выглядел, наверное, как идиот-“следящий”. Но одного дня мне хватило.
К концу первого дня я понял, в чём дело.
За стеной пункта связи оказалось другое помещение - кухня.
Там сотрудники по утрам грели еду, потому что дома не успевали.
Включали самую паршивую китайскую микроволновку, которая фонит во всех, бл… диапазонах - даже в L band!
Излучение пробивало стену и било прямо по стойке с оборудованием.
Влиял не только наш модем, но и соседнее железо, просто про это никто даже не догадывался.
Днём они грели обед, вечером - кофе.
Я поставил анализаторы, показал сотрудникам и начальнику графики и реальные замеры.
Для чистоты эксперимента включал микроволновку и демонстрировал, как ровно в этот момент садится спутниковый сигнал.
После этого микроволновку перестали включать - и все проблемы исчезли.
Я добавил, что если все они не хотят получить рак через полгода, то пусть заменят это дерьмо на нормальное оборудование.
Народ так перепугался, что рванул на кухню и выкинул микроволновку ещё до того, как я закончил проверку и вышел из кабинета.
Оставшееся время командировки я гулял по местному лесу и думал о том, сколько таких дешевых микроволновок по всему миру, и как редко рядом оказывается человек с анализатором.
1🔥31😁3👍2
#kubernetes #secrets #api
(заметка не несёт никакой ценности, лишь мысли)
Иногда, для самого себя, я провожу теоретические, вперемешку с практическими, изыскания.
Выбираю узкопрофильную тему и ковыряю, пока не дохожу до кишков.
Это может быть знания зачем
Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".
Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько
https://kubernetes.io/docs/reference/using-api/api-concepts/
Знания и поиск по документации привел к тому, что есть
То есть каждый раз при этих действиях идёт
Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.
Затем мои поиски вывели на отличную опцию
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.
"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде😀
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки
В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)
- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)
- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.
Всё выглядит как сказка, а что на деле?
Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.
Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой
Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.
Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭
(заметка не несёт никакой ценности, лишь мысли)
Иногда, для самого себя, я провожу теоретические, вперемешку с практическими, изыскания.
Выбираю узкопрофильную тему и ковыряю, пока не дохожу до кишков.
Это может быть знания зачем
EXPOSE в докер файле и на что это влияет, какая разница между cgroup v1 и cgroup v2 или различия хранилищ для больших данных и миллиардов мелких файлов по 6 KB.Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".
Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько
VERBs.https://kubernetes.io/docs/reference/using-api/api-concepts/
Знания и поиск по документации привел к тому, что есть
WATCH запрос, который идёт каждый раз от kubelet, когда стартует под или скейлится или происходит редеплой через любую из стратегий, при использовании секрета кубернетиса.То есть каждый раз при этих действиях идёт
WATCH.Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.
sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))Затем мои поиски вывели на отличную опцию
immutable в секретах (вру, я слышал и знал о ней раньше, но прям в проде не использовал).https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.
"если секрет иммутабл, то кублет(с каждой ноды) не делает WATCH запрос в апишку".
"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки
В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)
sum(rate(apiserver_request_duration_seconds_sum{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)
/
sum(rate(apiserver_request_duration_seconds_count{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)
sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.
Всё выглядит как сказка, а что на деле?
Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.
Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой
immutable секрет замонитирован на ноде более, чем в один под(разные деплойменты) то такой секрет не подтянется при изменим даже при рестарте.Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.
Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤1
#victoriametrics #traces
Я ждал-ждал и наконец-то дождался.
Helm чарт трейсов в VM и саппорт в операторе.
Скорее всего с багами, ибо первый релиз, но всё равно в dev домой накачу вечером.
- https://github.com/VictoriaMetrics/helm-charts/pull/2400
- https://github.com/VictoriaMetrics/operator/pull/1499
Я ждал-ждал и наконец-то дождался.
Helm чарт трейсов в VM и саппорт в операторе.
Скорее всего с багами, ибо первый релиз, но всё равно в dev домой накачу вечером.
- https://github.com/VictoriaMetrics/helm-charts/pull/2400
- https://github.com/VictoriaMetrics/operator/pull/1499
🔥4
#aws #eks #kubernetes #bottlerocket #troubleshooting
Case:
AWS EKS, Bottlerocket AMI. Случайно уронили коллектор логов, сбора не было несколько часов, но логи нужны прям сейчас. Если коллектор починить, то ждать долго(кстати какого фига долго я хз).
Нужных логов в поде нет, в ArgoCD их тоже нет(логично же).
Как быть?
Можно слить с EKS node(s), но этот путь не очевидный, ведь у нас
Для начала нужно быть уверен, что вы включали админ доступ в TOML конфиге.
Ок, админ доступ включён.
Смотрим на какой ноде запущен наш под.
Узнаем айди инстанса.
Подключаемся к инстансу через SSM
Сейчас нет никаких прав, переходим в админа.
Ок, мы стали админами(через контейнер), теперь нам нужен шелл - шелти.
Дальше просто смотрим в
Ну и смотрим логи
"но Алекс, нам нужны все логи, как их слить к себе локально?"
Ок, запускаем сборку логов в шелти
После коллекции у нас логи хранятся на ноде в
Теперь со своей локальной машины дёргаем их к себе через k8s API (да-да, я тоже не знал)
У нас локально теперь все логи в
Задача решена.
Case:
AWS EKS, Bottlerocket AMI. Случайно уронили коллектор логов, сбора не было несколько часов, но логи нужны прям сейчас. Если коллектор починить, то ждать долго(кстати какого фига долго я хз).
Нужных логов в поде нет, в ArgoCD их тоже нет(логично же).
Как быть?
Можно слить с EKS node(s), но этот путь не очевидный, ведь у нас
Bottlerocket.Для начала нужно быть уверен, что вы включали админ доступ в TOML конфиге.
*# Доступ к системным логам, получению root-оболочки (sheltie), запуску journalctl, logdog и пр.
[settings.host-containers.admin]
enabled = true
# Доступ к Bottlerocket API для настроек и диагностики, но без глубокого доступа к логам и файловой системе ноды.
[settings.host-containers.control]
enabled = true
Ок, админ доступ включён.
Смотрим на какой ноде запущен наш под.
kubectl get pods -o wide | grep podname
... ip-10-1-114-226.ec2.internal ...
Узнаем айди инстанса.
kubectl get node -o yaml ip-10-1-114-226.ec2.internal | grep -A4 -i "nodeid"
... "i-09cd72826bee50209" ...
Подключаемся к инстансу через SSM
aws ssm start-session --target i-09cd72826bee50209
Сейчас нет никаких прав, переходим в админа.
enter-admin-container
Ок, мы стали админами(через контейнер), теперь нам нужен шелл - шелти.
[root@admin]# sudo sheltie
Дальше просто смотрим в
/var/log/ls /var/log/containers/
argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log
...
Ну и смотрим логи
cat argo-cd-argocd-application-controller-0_argo-cd_application-controller-dfb4d12f601e71ac373b30bfaad8d02b56141218e7bcc5f1358f3a7d8f7df7f7.log
"но Алекс, нам нужны все логи, как их слить к себе локально?"
Ок, запускаем сборку логов в шелти
bash-5.1# logdog
После коллекции у нас логи хранятся на ноде в
logs are at: /var/log/support/bottlerocket-logs.tar.gz
Теперь со своей локальной машины дёргаем их к себе через k8s API (да-да, я тоже не знал)
kubectl get --raw "/api/v1/nodes/ip-10-1-114-226.ec2.internal/proxy/logs/support/bottlerocket-logs.tar.gz" > ./bottlerocket-logs.tar.gz
У нас локально теперь все логи в
bottlerocket-logs.tar.gzЗадача решена.
*** Если изначально админ доступ не включён, то всё не ок. По идее если его включаешь в момент задачи, то ноды пересоздаются и старые логи с нод исчезают в пучине небытия и бездны. Тогда уж лучше ждать окончания работы починенного коллектора логов.** При необходимости повторить для других нод, если исторически старый под был запущен на других нодах.👍8❤5🔥3
#пятница #всратость
Интервью где-то в параллельной вселенной.
- Переходим к следующему вопросу. Что происходит, когда вы вводите команду
-
- А, ладно, допустим установлен. Попробуем снова.
-
- (Раздражённо) Нет-нет, файл точно есть.
-
- (Устало) Так, у нас есть все бинари, ямл и контекст
-
- (обречённо) Да что же вы мне всё путаете, ок, есть файлы и контекст и доступ по сетке с VPN и с RBAC проблем нет
- Хорошо,
Затем...
- (удивлённо прерывая) Стоп-стоп, эээ... я вообще думал про шедулер и поды с кублетом..
- До этого мы ещё даже не дошли. Могу предложить перейти сразу к продакшн-кейсам по вашей вакансии для ведущего инженера, а не к тесту на внимательность и глубокое ныряние в омут, в котором, порой, можно потонуть всем и сразу?
- Да-да, пожалуй вы правы, мне стоит пересмотреть точность и корректность вопросов практикующим инженерам..
Интервью где-то в параллельной вселенной.
- Переходим к следующему вопросу. Что происходит, когда вы вводите команду
kubectl apply -f file.yaml?-
kubectl: command not found- А, ладно, допустим установлен. Попробуем снова.
-
error: the path "file.yaml" does not exist- (Раздражённо) Нет-нет, файл точно есть.
-
error: You must be logged in to the server (Unauthorized)- (Устало) Так, у нас есть все бинари, ямл и контекст
-
Unable to connect to the server: dial tcp 10.0.0.1:443: i/o timeout- (обречённо) Да что же вы мне всё путаете, ок, есть файлы и контекст и доступ по сетке с VPN и с RBAC проблем нет
- Хорошо,
kubectl apply по умолчанию использует Server-Side Apply, если не ошибаюсь с Kubernetes 1.23, где сервер разрешает конфликты полей через field managers. На клиенте YAML конвертируется в JSON для отправки на API-сервер. В случае client-side apply добавляется аннотация last-applied-configuration для 3-way merge. После получения запроса API-сервером объект проходит через mutating admission controllers и затем validating admission controllers, прежде чем сохраняется в etcd. В etcd данные хранятся в protobuf, а каждый write увеличивает resourceVersion - счётчик версий, который контроллеры используют для optimistic concurrency control, избегая race conditions. Затем...
- (удивлённо прерывая) Стоп-стоп, эээ... я вообще думал про шедулер и поды с кублетом..
- До этого мы ещё даже не дошли. Могу предложить перейти сразу к продакшн-кейсам по вашей вакансии для ведущего инженера, а не к тесту на внимательность и глубокое ныряние в омут, в котором, порой, можно потонуть всем и сразу?
- Да-да, пожалуй вы правы, мне стоит пересмотреть точность и корректность вопросов практикующим инженерам..
👏22😁15❤3
#байки #troubleshooting #kubernetes #openshift
В далёком уже 2020-2021 я пилил обучающие онлайн видео для компании, где работал.
Ну типа внутренние онлайн видео встречи "что такое кубернетес/опеншифт" на минималках для ВНЕШНЕЙ компании-партнёра из другой страны. От моей компании передача знаний другой компании-партнёру.
Ничего интересного там не было, общий концепт куба, общие уровни абстракции и так далее.
Помимо этого были куски про CICD и так далее от коллег по компании.
В общем "DevOps онлайн уроки на минималках", галопам поевропам skill-опам.
Одна из частей уроков была подготовка стенда во внутренней сети компании для студентов, чтобы они вживую всё это потыкали и сделали ДЗ.
Этим занимались системные администраторы(крутые ребята, между прочим!) внутри компании.
Установили GitLab, OpenShift, TeamCity, Nexus OSS etc.
Мы, "преподаватели", лишь дали указания, что нам надо, количество нод, версии и всё.
Когда админы всё подготовили, нам дали лишь эндпойнты и креды.
Нам лишь надо было подготовить домашки и всё проверить самостоятельно.
Без проблемных историй не обошлось.
Прибегает ко мне второй преподаватель(часть обучения по контейнеризации), говорит стенд не работает, не понятно почему.
Пилит локально имадж, пушит в реджистри - всё ок.
Делает деплоймент в опеншифте, а он не может пулить (я честно не помню точный текст ошибки, да и байка это, зачем точности тут).
Проверяю - да, пуллинга нет.
Пишу админам - проверьте сетку между нодами кубера и реджистри - пишут всё ок, сеть ок.
Но у нас всё ещё не работает. Спрашиваю у них за файрвол и прочее - всё ок, говорят они.
Сидим, оба "преподавателя" и хлопаем глазами🤡 .
Признаться над своей некомпетентностью стыдно. Даже самому себе.
Потом, меня, внезапно, осеняет. Говорю:
- "а как ты проверял от себя локально? Какие команды вводил?"
- "ну докер билд, докер пуш, докер пулл для проверки"
- "а какой рантайм у опеншифта?"
- "ну cri-o вроде"
Ага, проверяли-то мы по-разному.
Иду к админам, тихонечко спрашиваю:
- "а случаем нет ли какого балансёра перед реджистри?
- "ну как нет, конечно же есть, у нас по регламенту должен быть балансёр"
Бегу в github, качаю нужные бинари крио, канико, докера, подмана и так далее.
Запускаю пулл с каждой из них, в фоне гоню
У всех разный🐒 . Сука.
Снова бегу на поклон к админам, снова общение "а что за конфиг балансёра, дайте плиз часть с фильтрацией по юзер агенту".
Дают конфиг, вижу регулярку для докера, браузеров и контейнерд(точный список не помню).
Пишу новый кусок конфига для всех типов инструментов для работы с имаджами и контейнерами(чтобы другие преподаватели или участники не споткнулись снова об это), отправляю админам.
Они применяют, я проверяю со всех агентов - всё работает.
Пишу второму преподавателю "я починил всё, он проверяет - всё ок".
Радостно урча продолжаем подготовку стенда и материалов для студентов..
Зачем нужен был балансёр перед реджистри внутри закрытой корпоративной сети, с фильтрацией по юзер агенту, я так и не узнал, сперва забыл спросить, а потом и вовсе тот админ покинул компанию, а спустя год и я ушёл.🤷🏽♂️
Ради лишнего гроша участвуешь и не в такой активности компании😭 .
В далёком уже 2020-2021 я пилил обучающие онлайн видео для компании, где работал.
Ну типа внутренние онлайн видео встречи "что такое кубернетес/опеншифт" на минималках для ВНЕШНЕЙ компании-партнёра из другой страны. От моей компании передача знаний другой компании-партнёру.
Ничего интересного там не было, общий концепт куба, общие уровни абстракции и так далее.
Помимо этого были куски про CICD и так далее от коллег по компании.
В общем "DevOps онлайн уроки на минималках", галопам по
Одна из частей уроков была подготовка стенда во внутренней сети компании для студентов, чтобы они вживую всё это потыкали и сделали ДЗ.
Этим занимались системные администраторы(крутые ребята, между прочим!) внутри компании.
Установили GitLab, OpenShift, TeamCity, Nexus OSS etc.
Мы, "преподаватели", лишь дали указания, что нам надо, количество нод, версии и всё.
Когда админы всё подготовили, нам дали лишь эндпойнты и креды.
Нам лишь надо было подготовить домашки и всё проверить самостоятельно.
Без проблемных историй не обошлось.
Прибегает ко мне второй преподаватель(часть обучения по контейнеризации), говорит стенд не работает, не понятно почему.
Пилит локально имадж, пушит в реджистри - всё ок.
Делает деплоймент в опеншифте, а он не может пулить (я честно не помню точный текст ошибки, да и байка это, зачем точности тут).
Проверяю - да, пуллинга нет.
Пишу админам - проверьте сетку между нодами кубера и реджистри - пишут всё ок, сеть ок.
Но у нас всё ещё не работает. Спрашиваю у них за файрвол и прочее - всё ок, говорят они.
Сидим, оба "преподавателя" и хлопаем глазами
*, как сельские дурачкиПризнаться над своей некомпетентностью стыдно. Даже самому себе.
Потом, меня, внезапно, осеняет. Говорю:
- "а как ты проверял от себя локально? Какие команды вводил?"
- "ну докер билд, докер пуш, докер пулл для проверки"
- "а какой рантайм у опеншифта?"
- "ну cri-o вроде"
Ага, проверяли-то мы по-разному.
Иду к админам, тихонечко спрашиваю:
- "а случаем нет ли какого балансёра перед реджистри?
- "ну как нет, конечно же есть, у нас по регламенту должен быть балансёр"
Бегу в github, качаю нужные бинари крио, канико, докера, подмана и так далее.
Запускаю пулл с каждой из них, в фоне гоню
tcpdump.У всех разный
user-agent Снова бегу на поклон к админам, снова общение "а что за конфиг балансёра, дайте плиз часть с фильтрацией по юзер агенту".
Дают конфиг, вижу регулярку для докера, браузеров и контейнерд(точный список не помню).
Пишу новый кусок конфига для всех типов инструментов для работы с имаджами и контейнерами(чтобы другие преподаватели или участники не споткнулись снова об это), отправляю админам.
Они применяют, я проверяю со всех агентов - всё работает.
Пишу второму преподавателю "я починил всё, он проверяет - всё ок".
Радостно урча продолжаем подготовку стенда и материалов для студентов..
Зачем нужен был балансёр перед реджистри внутри закрытой корпоративной сети, с фильтрацией по юзер агенту, я так и не узнал, сперва забыл спросить, а потом и вовсе тот админ покинул компанию, а спустя год и я ушёл.🤷🏽♂️
* да, вот такие "преподаватели" порой участвуют в преподавании.Ради лишнего гроша участвуешь и не в такой активности компании
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13👍1
#troubleshooting #aws #ssh #retool #paranoia #linux
Есть такая штука, называется
Какая-то платформа для менеджеров, я ей не пользовался никогда в бизнес уровне.
В UI интерфейсе мышкой подключаются
Это всё, что надо знать для начала, идём дальше.
В основном
Первый случай я не знаю для кого, у меня пока не было опыта публичных БД, второй способ мне не нравится, да и не пройти с ним SOC2 аудит, так что у нас только третий вариант - через ssh tunnel.
У них есть вполне годный гайд https://docs.retool.com/data-sources/guides/connections/ssh-tunnels, который подойдёт для 99% случаев.
Создаётся пользователь на бастион хосте(например через
При подключении ресурса вы в UI указываете ваш bastion хост, порт и прожимаете test connection.
Если всё ок- ошибки нет. Не ок - ошибка.
Ошибка чаще всего дурацкая, потому что открывается какой-то аналог developer tool и показывает длинный стактрейс.
С
В то время в качестве бастион хоста была убунту 18 вроде и мне пришлось промучить весь стакоферфлоу, чтобы найти решение для себя при ошибке, мне не хватало
Ровно после этого в официальной документации и появился этот совет, если коннекта нет.
Написал им в поддержку, чтобы поправили мануал для глупеньких я.
Тогда подключили какие-то бд, я сидел дальше ковырялся с конфигами, безопасностью, со временем обложил всё секьюрити группами типа
Потом добавились секюрити группы по MySQL/PostgreSQL типа
Так же сразу сделал отдельного пользователя в БД с чётко обрезанными правами.
Делал что-то ещё, и в целом был удовлетворён, что тварь какая-то ходит в мои сети.
Прошло много лет.
Ко мне приходят ребята инженеры, говорят хотят добавить новую БД для retool.
Уже подключена монга, mysql и всякое, а теперь надо и PostgreSQL.
Ок, говорю, ну там всё уже настроено - все ssh ключи, секьюрити группы и прочее - всё должно работать - другие то ресурсы(БД) работает до сих пор.
Берите креды и сами настраиваете, мы же договорились, что не должно быть боттлнека -девопса.
Они высылают скрин, что ошибка подключения. Я само собой не верю (бл, когда я научусь думать, что другие люди не глупее меня🐒 , баран самоуверенный).
Иду сам в retool, копирую все креды, создаю ресурс, но у меня тоже ошибка.
Извиняюсь перед ребятами, пилю тикет, начинаю разбираться.😭
Есть такая штука, называется
retool https://retool.com/Какая-то платформа для менеджеров, я ей не пользовался никогда в бизнес уровне.
В UI интерфейсе мышкой подключаются
resource и на их базе могут строятся какие-то таблички, панели и прочая не интересная мне информация для менеджеров и сейлзов(наверное).Resources чаще всего это база данных. Например MySQL или PostgreSQL. У retool тысячи их для любых интеграций.Это всё, что надо знать для начала, идём дальше.
В основном
Retool из интернета подключается к вашим ресурсам либо напрямую по hostname, либо к AWS через IAM credentials, либо через SSH bastion host.Первый случай я не знаю для кого, у меня пока не было опыта публичных БД, второй способ мне не нравится, да и не пройти с ним SOC2 аудит, так что у нас только третий вариант - через ssh tunnel.
У них есть вполне годный гайд https://docs.retool.com/data-sources/guides/connections/ssh-tunnels, который подойдёт для 99% случаев.
Создаётся пользователь на бастион хосте(например через
ansible или руками), добавляется их ssh public key, раскидываются права - всё готово. В общем всё по инструкции.При подключении ресурса вы в UI указываете ваш bastion хост, порт и прожимаете test connection.
Если всё ок- ошибки нет. Не ок - ошибка.
Ошибка чаще всего дурацкая, потому что открывается какой-то аналог developer tool и показывает длинный стактрейс.
С
retool я уже работал, подключал на проект много лет назад. В то время в качестве бастион хоста была убунту 18 вроде и мне пришлось промучить весь стакоферфлоу, чтобы найти решение для себя при ошибке, мне не хватало
PubkeyAcceptedKeyTypes +ssh-rsa
Ровно после этого в официальной документации и появился этот совет, если коннекта нет.
Написал им в поддержку, чтобы поправили мануал для глупеньких я.
Тогда подключили какие-то бд, я сидел дальше ковырялся с конфигами, безопасностью, со временем обложил всё секьюрити группами типа
resource "aws_security_group" "bastion" {
...
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
# https://docs.retool.com/data-sources/reference/ip-allowlist-cloud-orgs
# retool ip ranges only
# tfsec:ignore:aws-ec2-no-public-ingress-sgr
cidr_blocks = [
"35.90.103.132/30",
"44.208.168.68/30",
"3.77.79.248/30"
]
description = "SSH access from allowed IP ranges"
}
...Потом добавились секюрити группы по MySQL/PostgreSQL типа
resource "aws_security_group_rule" "this" {
type = "ingress"
from_port = 5432
to_port = 5432
protocol = "tcp"
cidr_blocks = ["*********"]
security_group_id = aws_security_group.rds.id
description = "Allow PostgreSQL access from ***** VPC"
}Так же сразу сделал отдельного пользователя в БД с чётко обрезанными правами.
Делал что-то ещё, и в целом был удовлетворён, что тварь какая-то ходит в мои сети.
Прошло много лет.
Ко мне приходят ребята инженеры, говорят хотят добавить новую БД для retool.
Уже подключена монга, mysql и всякое, а теперь надо и PostgreSQL.
Ок, говорю, ну там всё уже настроено - все ssh ключи, секьюрити группы и прочее - всё должно работать - другие то ресурсы(БД) работает до сих пор.
Берите креды и сами настраиваете, мы же договорились, что не должно быть боттлнека -девопса.
Они высылают скрин, что ошибка подключения. Я само собой не верю (бл, когда я научусь думать, что другие люди не глупее меня
Иду сам в retool, копирую все креды, создаю ресурс, но у меня тоже ошибка.
Извиняюсь перед ребятами, пилю тикет, начинаю разбираться.
Please open Telegram to view this post
VIEW IN TELEGRAM
😱3
#troubleshooting #aws #ssh #retool #paranoia #linux
Ок, что же говорит ошибка. Текст типа
и дальше огромная простыня трейса.
А ничего она не говорит, и так понятно, ясно понятно, нет подключения.
Прохожу снова по инструкции - всё ок.
Проверяю не менялся ли паблик ключ? Не менялся.
Не менялся ли пул публичных адресов? Не менялся.
Блин, ну я же не дурак.
Добавляю руками свой IP на секьюрити группу, подключаюсь на бастион хост и оттуда делаю телнет и подключение через cli к PostgreSQL.
Сетевая связность есть, коннект.
Проверяю ещё раз все секьюрити группы, поиск по коммитам, всё отлично.
Так, стоп, а предыдущие то ресурсы работают?
Захожу в
Чешу репу, гуглю решения, закидываю в 3 нейронки - решения нет.
Общие предположения, да и только.
В общем в траблшутинге и логах я просидел долго.
Чтобы не было стыдно, не буду говорить сколько, но много.
В итоге я просто начал смотреть все журналы, все конфиги и даже трейсы, мне было очень интересно.
Очевидно же, что у меня что-то не так, иначе бы ранее добавленные ресурсы не работали.
Спустя время дошёл до конца файла
А там паранойя, ну прям рили паранойя.
Я даже сам забыл про эту паранойю!
В общем добавляю очевидное
Перезапускаю
и Voilà! - коннект от
Описываюсь ребятам, они подтверждают, закрываю задачу.
Какая же мораль? Как обычно:
- не думай, что остальные глупее тебя, если пишут ошибка есть - значит она есть!
- вспоминай о своих параноидальных привычках, прежде, чем тратить время
- держи конфиг sshd в IaC (
* адреса endpoints к БД само собой должны быть полными и длинными, короткие URL лишь для примера
Ок, что же говорит ошибка. Текст типа
Test connection failed (120.327s):(SSH) Channel open failure: open failed
{query: "Connect Request", error: Object}
query: "Connect Request"
error: Object
message: "(SSH) Channel open failure: open failed"
data: Object
reason: 1
name: "Error"
message: "(SSH) Channel open failure: open failed"
и дальше огромная простыня трейса.
А ничего она не говорит, и так понятно, ясно понятно, нет подключения.
Прохожу снова по инструкции - всё ок.
Проверяю не менялся ли паблик ключ? Не менялся.
Не менялся ли пул публичных адресов? Не менялся.
Блин, ну я же не дурак.
Добавляю руками свой IP на секьюрити группу, подключаюсь на бастион хост и оттуда делаю телнет и подключение через cli к PostgreSQL.
Сетевая связность есть, коннект.
Проверяю ещё раз все секьюрити группы, поиск по коммитам, всё отлично.
Так, стоп, а предыдущие то ресурсы работают?
Захожу в
retool, в давно созданные ресурсы - тест проходит ок.Чешу репу, гуглю решения, закидываю в 3 нейронки - решения нет.
Общие предположения, да и только.
В общем в траблшутинге и логах я просидел долго.
Чтобы не было стыдно, не буду говорить сколько, но много.
В итоге я просто начал смотреть все журналы, все конфиги и даже трейсы, мне было очень интересно.
Очевидно же, что у меня что-то не так, иначе бы ранее добавленные ресурсы не работали.
Спустя время дошёл до конца файла
/etc/ssh/sshd_config перебирая по одному все включённые параметры, а там.... а там парам-пам-пам!А там паранойя, ну прям рили паранойя.
# bastion host 1.2.3.4
cat /etc/ssh/sshd_config |grep -v "^#"
...
Match User retool
PermitTTY no
AllowTcpForwarding yes
PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017
ForceCommand /bin/echo "Shell disabled!"
Я даже сам забыл про эту паранойю!
В общем добавляю очевидное
...
PermitOpen mysql.amazonaws.com:3306 docdb.amazonaws.com:27017 postgresql.amazonaws.com:5432
...
Перезапускаю
sudo systemctl restart ssh
и Voilà! - коннект от
retool есть.Описываюсь ребятам, они подтверждают, закрываю задачу.
Какая же мораль? Как обычно:
- не думай, что остальные глупее тебя, если пишут ошибка есть - значит она есть!
- вспоминай о своих параноидальных привычках, прежде, чем тратить время
- держи конфиг sshd в IaC (
ansible например), а не руками заполняй, баран. Поиском по iac я быстро увидел бы причину* адреса endpoints к БД само собой должны быть полными и длинными, короткие URL лишь для примера
2🔥10
#troubleshooting #billing #CostOptimization #newrelic
Внезапно вырос ценник на
Заметили не сразу, не было настроены алерты по биллингу.
Увидели лишь в начале месяца, при выставлении счёта.
Я не сильно тогда был знаком с
Поковырявшись в интерфейсе и немного документации, обнаружил, что деньги начали списываться в раздел логирования.
А ведь это странно, все логи у нас пишутся в ELK стек в самом кубе, зачем ещё и в
Первым делом смотрю в ньюрелике кто именно пишет логи - ага, одно единственное приложение.
Иду в git, захожу в раздел PR, вижу там миллиард PR, закрываю, ибо даже с поиском ничего не найти.
Клонирую репозиторий, смотрю локально.
Ага, у нас агент newrelic ставится через Dockerfile
Дальше ковыряюсь в конфигах самого приложения, но там ничего интересного.
Нет в явном виде "логирование енаблед тру" или подобного. Странно.
Ладно, ну поехали, смотрим через git кто когда вносил изменения в докерфайлэ, всё равно другой зацепки нет.
И буквально через несколько коммитов вижу зацепку - коллега разработчик обновил версию
Само собой нашёл и его PR и того, кто его аппрувил.
Но была обновлена только версия, больше ничего не менялось.
Херня какая.
Ладно, иду в POD, смотрю конфиг, а что внутри
и поиском вижу там нечто типа
Пилю себе ветку, в этой ветке делаю даунгрейд до старой версии
Да бл.
Бегу в документацию и нахожу
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/
От суки, ладно, пилю быстрофикс (не удивлюсь, если он до сих пор там в докерфайле, лол).
Качу PR, аппрув, мерж, логи перестали идти в newrelic, прайс не растёт.
Ну а дальше как обычно: оповещение коллегам, ата-та так не делайте плиз, читайте доки перед апдейтом(да ладно, кому я вру, я бы тоже не читал), вот рут коз, вот фикс, вот ссылки, вот пруфы.
Все виновато покивали и сделали вид, что запомнили и не повторят ошибок. Да.
Потеря денег всего $460 за пару недель.
Идём работать дальше.
Внезапно вырос ценник на
newrelic.Заметили не сразу, не было настроены алерты по биллингу.
Увидели лишь в начале месяца, при выставлении счёта.
Я не сильно тогда был знаком с
newrelic, этой штукой обычно пользовались коллеги-разработчики, я больше по инфре и стеку с VM/Prometheus/Grafana, но деньги есть деньги, надо разбираться.Поковырявшись в интерфейсе и немного документации, обнаружил, что деньги начали списываться в раздел логирования.
А ведь это странно, все логи у нас пишутся в ELK стек в самом кубе, зачем ещё и в
newrelic писать, а там за каждый чих деньги просят.Первым делом смотрю в ньюрелике кто именно пишет логи - ага, одно единственное приложение.
Иду в git, захожу в раздел PR, вижу там миллиард PR, закрываю, ибо даже с поиском ничего не найти.
Клонирую репозиторий, смотрю локально.
Ага, у нас агент newrelic ставится через Dockerfile
ENV NEWRELIC_VERSION 11.6.0.19
...
ADD https://download.newrelic.com/php_agent/archive/${NEWRELIC_VERSION}/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz /tmp/
RUN export NR_INSTALL_USE_CP_NOT_LN=1 NR_INSTALL_SILENT=1 \
&& tar -xf /tmp/newrelic-php5-${NEWRELIC_VERSION}-linux.tar.gz -C /tmp \
&& /tmp/newrelic-php5-*/newrelic-install install \
&& rm -rf /tmp/*
...
Дальше ковыряюсь в конфигах самого приложения, но там ничего интересного.
Нет в явном виде "логирование енаблед тру" или подобного. Странно.
Ладно, ну поехали, смотрим через git кто когда вносил изменения в докерфайлэ, всё равно другой зацепки нет.
git log Dockerfile
И буквально через несколько коммитов вижу зацепку - коллега разработчик обновил версию
newrelic.Само собой нашёл и его PR и того, кто его аппрувил.
Но была обновлена только версия, больше ничего не менялось.
Херня какая.
Ладно, иду в POD, смотрю конфиг, а что внутри
cat /usr/local/etc/php/conf.d/newrelic.ini
и поиском вижу там нечто типа
newrelic.application_logging.enabled = true
Пилю себе ветку, в этой ветке делаю даунгрейд до старой версии
newrelic, собираю имадж, смотрю в нём конфигnewrelic.application_logging.enabled = false
Да бл.
Бегу в документацию и нахожу
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/
PHP agent version 10.1.0 lets you forward your PHP logs with APM logs in context. As of version 10.3.0, the logging metrics and agent log forwarding features are enabled by default. The value newrelic.application_logging.enabled controls whether or not the logs in context feature is active or inactive.
От суки, ладно, пилю быстрофикс (не удивлюсь, если он до сих пор там в докерфайле, лол).
RUN sed "s/^.*;newrelic.application_logging.enabled.*/newrelic.application_logging.enabled = false/" \
-i /usr/local/etc/php/conf.d/newrelic.ini
Качу PR, аппрув, мерж, логи перестали идти в newrelic, прайс не растёт.
Ну а дальше как обычно: оповещение коллегам, ата-та так не делайте плиз, читайте доки перед апдейтом(да ладно, кому я вру, я бы тоже не читал), вот рут коз, вот фикс, вот ссылки, вот пруфы.
Все виновато покивали и сделали вид, что запомнили и не повторят ошибок. Да.
Потеря денег всего $460 за пару недель.
Идём работать дальше.
5👍19❤1
Make. Build. Break. Reflect.
#пятница #байки #troubleshooting Задолго до работы в айти я был простым советским инженером спутниковой связи. Тарелки, антенны, модемы, кабели, бесконечные командировки. В то время случалось масса странных историй. Мы разрабатывали спутниковое оборудование…
#пятница #байки #troubleshooting
Ещё один случай, более банальный, но от того не менее занятный.
К нам обратились: "оборудование барахлит, раньше работало, потом стало похуже, а сейчас почти совсем не работает, сейчас стало совсем плохо".
Мы как обычно: отправили новый модем - не помогло, попросили заменить кабельную трассу - не помогло. Ясно: опять локальная херня, надо ехать, отправляют молодого.
Приезжаю. Место знакомое. Смотрю на антенну: стоит та же, что и пять лет назад. Только вот когда её ставили - перед ней было чистое поле. А теперь в нескольких метрах перед приёмником выросло почти дерево.
Сначала были слабые ростки, ветер шатал - появлялись помехи на канале, потом выросли кустики - помех стало чуть больше при ветре, а потом почти полноценный ствол с кроной. И он, как назло, при ветре и шатании кроны в самый азимут упирается. Догадаться, что спутниковая антенна должна видеть спутник напрямую, никто не удосужился. Стоит же железка - пусть работает сама по себе. Раньше же всегда работало. Они то сами ничего не меняли, да.
Я посмотрел на это, вздохнул, показал начальнику пальцем на дерево-куст и сказал: "вот ваш сбой, подпишите, пожалуйста, Акт выполненных работ".
Взгляд его не предвещал ничего хорошего его сотрудникам после моего уезда.
Ну, дальше по классике: спилили дерево, помехи ушли, сигнал вернулся, народ снова счастлив.
С тех пор мы при удалённой проверке просили сделать фото с телефона "а чего там сейчас перед тарелкой".
Иногда проблема не в людях, железках и кабелях, а в природе, которая растёт где хочет.
Без разрешения начальства и согласования с отделом связи.
Наверное, считает себя самым главным интегратором на объекте.
Ещё один случай, более банальный, но от того не менее занятный.
К нам обратились: "оборудование барахлит, раньше работало, потом стало похуже, а сейчас почти совсем не работает, сейчас стало совсем плохо".
Мы как обычно: отправили новый модем - не помогло, попросили заменить кабельную трассу - не помогло. Ясно: опять локальная херня, надо ехать, отправляют молодого.
Приезжаю. Место знакомое. Смотрю на антенну: стоит та же, что и пять лет назад. Только вот когда её ставили - перед ней было чистое поле. А теперь в нескольких метрах перед приёмником выросло почти дерево.
Сначала были слабые ростки, ветер шатал - появлялись помехи на канале, потом выросли кустики - помех стало чуть больше при ветре, а потом почти полноценный ствол с кроной. И он, как назло, при ветре и шатании кроны в самый азимут упирается. Догадаться, что спутниковая антенна должна видеть спутник напрямую, никто не удосужился. Стоит же железка - пусть работает сама по себе. Раньше же всегда работало. Они то сами ничего не меняли, да.
Я посмотрел на это, вздохнул, показал начальнику пальцем на дерево-куст и сказал: "вот ваш сбой, подпишите, пожалуйста, Акт выполненных работ".
Взгляд его не предвещал ничего хорошего его сотрудникам после моего уезда.
Ну, дальше по классике: спилили дерево, помехи ушли, сигнал вернулся, народ снова счастлив.
С тех пор мы при удалённой проверке просили сделать фото с телефона "а чего там сейчас перед тарелкой".
Иногда проблема не в людях, железках и кабелях, а в природе, которая растёт где хочет.
Без разрешения начальства и согласования с отделом связи.
Наверное, считает себя самым главным интегратором на объекте.
2😁31
#grafana
Простая заметка исключительно для начинающих инженеров, только приступивших к работе с графаной.
Все опытные инженеры и так знают эту капитан-очевидную информацию. Опытным можно скипнуть.
Где взять дашборды Grafana в 2025, как и с чего начать с нуля.
1) Скачать любой
- просто установить в миникуб/кубер, зайти в графану и откуда слить интересующие дашборды
- удалить
Если не хочется установить, то просто слить сразу директории и файлы. Пример:
Все дашборды лежат в
Внутри YAML лежит JSON.
Минус варианта:
надо будет ещё и
2) Официальные и community репозитории:
- https://grafana.com/grafana/dashboards
- https://play.grafana.org/dashboards (всякие demo, поиском искать по ключевым словам)
- https://grafana.com/orgs/victoriametrics/dashboards
- https://github.com/monitoring-mixins/website/tree/master/assets
- https://github.com/dotdc/grafana-dashboards-kubernetes
- https://github.com/voidquark/grafana-dashboards
3) Специфик репозитории. Само собой их больше, тут как пример.
- https://github.com/tarantool/grafana-dashboard
- https://github.com/cloudnative-pg/grafana-dashboards
- https://github.com/percona/grafana-dashboards
- https://github.com/temporalio/dashboards
4) Просто по тегам гитхаба (обычно по звёздам сортировать и брать нужное)
- https://github.com/topics/grafana-dashboards
5) GitHub поиск:
- Поиск по метрике (например,
- Фильтрация по "
- Сортировка по звёздам, дате, популярности
- Вытаскивать нужные
Пример: https://github.com/search?q=rate%28nginx_ingress_controller_requests+language%3AJSON&type=code&l=JSON
6) Для новых/непопулярных проектов можно делать так.
Сделать port-forward на сервис, скопировать все метрики(обычно по пути
Бонус-инфа:
7) Необычный проект для синка clickops/IaC по бордам
- https://github.com/grafana/grafana-git-sync-demo
Простая заметка исключительно для начинающих инженеров, только приступивших к работе с графаной.
Все опытные инженеры и так знают эту капитан-очевидную информацию. Опытным можно скипнуть.
Где взять дашборды Grafana в 2025, как и с чего начать с нуля.
1) Скачать любой
stack helm chartaenix, victoria metrics, prometheus- просто установить в миникуб/кубер, зайти в графану и откуда слить интересующие дашборды
- удалить
stackЕсли не хочется установить, то просто слить сразу директории и файлы. Пример:
helm pull oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack --untar
Все дашборды лежат в
kube-prometheus-stack/templates/grafana/dashboards-1.14
├── alertmanager-overview.yaml
├── apiserver.yaml
├── cluster-total.yaml
├── controller-manager.yaml
├── etcd.yaml
...
Внутри YAML лежит JSON.
Минус варианта:
надо будет ещё и
records за собой утащить - большая часть дашбордов используют не стандартные метрики.2) Официальные и community репозитории:
- https://grafana.com/grafana/dashboards
- https://play.grafana.org/dashboards (всякие demo, поиском искать по ключевым словам)
- https://grafana.com/orgs/victoriametrics/dashboards
- https://github.com/monitoring-mixins/website/tree/master/assets
- https://github.com/dotdc/grafana-dashboards-kubernetes
- https://github.com/voidquark/grafana-dashboards
3) Специфик репозитории. Само собой их больше, тут как пример.
- https://github.com/tarantool/grafana-dashboard
- https://github.com/cloudnative-pg/grafana-dashboards
- https://github.com/percona/grafana-dashboards
- https://github.com/temporalio/dashboards
4) Просто по тегам гитхаба (обычно по звёздам сортировать и брать нужное)
- https://github.com/topics/grafana-dashboards
5) GitHub поиск:
- Поиск по метрике (например,
nginx_ingress_controller_requests, node_load5, trino_failuredetector_HeartbeatFailureDetector_ActiveCount etc.)- Фильтрация по "
dashboard" и "json"- Сортировка по звёздам, дате, популярности
- Вытаскивать нужные
.json и импорт к себеПример: https://github.com/search?q=rate%28nginx_ingress_controller_requests+language%3AJSON&type=code&l=JSON
6) Для новых/непопулярных проектов можно делать так.
Сделать port-forward на сервис, скопировать все метрики(обычно по пути
/metrics), вставить в любую нейронку, попросить нечто типа "вот все метрики по %продуктнейм%, сделай мне общую графана борду, типовые сценарии использования, дальше поправлю сам".Бонус-инфа:
7) Необычный проект для синка clickops/IaC по бордам
- https://github.com/grafana/grafana-git-sync-demo
🔥23❤3⚡1✍1👍1🤡1🤝1
If you upgraded to macOS Tahoe and it feels super slow, you can disable transparency by going to System Preferences > Accessibility > Display and checking "Reduce transparency"
My mac had been terrible since I upgraded, but after doing this it improved a lot.
Why did I even update the fckng OS?😭
My mac had been terrible since I upgraded, but after doing this it improved a lot.
Why did I even update the fckng OS?
Please open Telegram to view this post
VIEW IN TELEGRAM
1😁6💯6