Реальность 2025:
- удалил 3 игры из Стима, которые занимали много места на двух-терабайтном диске, чтобы установить модели типа https://ollama.com/library/deepseek-r1, потому как все паблик AI сервисы(чатгпт,дипсик,копайлот,клаудия) достаточно серьёзно часто тормозят/висят(даже с PRO), а мне работать надо и нейронки помогают писать юнит тесты.🚬
Пока сижу локально гоняю модельки, терпимо.

* у вас может и не получиться скачать, сам качал долго, постоянно EOF😭

Есть база данных AWS RDS(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

Просто мои собственные мысли.
Не наброс, просто мысли.

В начале 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.
Если и это вас не заинтересует, ну значит и я вам не подхожу и вы мне. Пора менять стратегию.

Быть может я вскоре и переобуюсь, но на данный момент план пока такой.

* Вышесказанное касается только меня и может не совпадать с мнением кого-либо, как и не быть единственной истиной.
Это нормально.

Airflow. Алёртинг.

К сожалению я так и не нашёл нормального эспортёра для метрик.
Пробовал около 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 не умеет в хранение этого в переменных).
- пилим GitLab PAT токен service account bot для доступа к git
- в новом гит репозитории создаём файл

/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.py

ORC_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 и почта мне неудобна.
Однако этот способ алёртинга пока единственно мне известный способ выводить точную и Детальную(!) информацию.

#alertmanager #troubleshooting

Сижу никого не трогаю.
Прилетает алёрт - превышение IOPS для MongoDB в K8s кластере.
Алёрт и метрики я писал сам, стало интересно, а чо прям можно упереться в максимум премиум ссд, вы там, бл, майните что-ли?
(на самом деле ссыканул, думал моя арифметика сбоит и алёрт фейк говно).

Не, прям по метрикам графаны - IOPS PV высокий.
Захожу в другие графики - read/write на PVC прям высокий.
То есть и IOPS и read/write был на нуле почти, а теперь в сотни тысячи раз выше.

Посмотрел по последним релизам - да, сутки назад был релиз и после этого начало гореть.
Пишу qa, pm - спрашиваю ожидаемая нагрузка, они говорят что нет. Да и вообще релиз прошёл, там нет ничего, ты чо.
Все вертят головой, говорят это я дурачок,у них всё ок.

* Сделаем ремарку и я уточню, что про монгодб я знаю лишь общее описание что это и всё.
Ну практического опыта у меня нет. Могу установить, могу дать креды и закрыть сеткой приватной и.. и пожалуй всё.
В общем начал я читать про базы данных, коллекции, операции, нагрузку.
Потом начал читать про репликацию в кластере, может это остаток репликации после апдейта.
Короче алёрт горит, а я всё читаю и читаю.
В итоге при помощи документации и великолепнейшего и любимого мной теперь DataGrip подключаюсь к базе(креды взял в секрете кубера, а порт прокинул через портфорвард, экстернал ендпойнта не было).
Посмотрел на базы, на коллекции, поигрался с запросами. Поспрашивал про типичные команды у нейронок.
В общем выяснил то, что
- размер с индексами 1.5гигабайта
- в новой версии софта у нас есть запросы с collscan

То есть делается обычный запрос - у нас перечитывается ВСЯ коллекция в 1.5Gb, делается обычный запрос - у нас перечитывается ВСЯ коллекция в 1.5Gb и так по циклу.
Сумасшедшее ридрайд насилие над стораджем.
Выяснил я это всё сам, не имея раньше дел с монгой в кишках.

Пишу девелоперам про свои находки, они уходят в запой на паузу и возвращаются через сутки🤣с ответом:
"в коллекции XXXX есть поля _id и accountId, которые суть одно и то же, но по accountId нет индекса. у нас появился запрос, который использует второе поле, поэтому сканится вся коллекция".😢

Пилят фикс, и в следующем релиза это катнём.
И да, пока приложение насилует диск монги.

Какие выводы? А они прям капитаночевидные👍:
- если у вас есть сервера, которые вы разворачиваете, хотя бы почитайте базовые команды для траблшутинга и сохраните в блокнотик. в случае инцидента не надо тратить время на чтение "что за говно у нас тут и как/куда тут смотреть чо"
- алёрты нужны не только на IOPS (спасибо мне, сладкому), но и на высокий/аномальный read/write. Надо будет закинуть в беклог
- какое счастье, что у нас не SAAS Mongo, иначе нам сожрало бы весь бюджет на ближайшие 50000 лет, выкатив прайс на $100.000 за эти сутки
- разработчики мудаки айти проклято, подстава откуда не ожидаешь
- azure врунькают, у них IOPS выше их трешхолдов

"хей Алекс, у нас закончилась демо версия Backup radar, теперь они хотят денег. Сможешь сделать аналог на AWS? Но денег и часов на задачу на один час. Нам просто надо ежедневно получать уведомления, что у нас успешно создаются бекапы. Сами снепшоты/бекапы создаются".

Ну один час, так один час.
EventBridge в чистом виде неудобен, я дольше буду читать про типы сорсов и полей, занимаясь фильтрацией.

1) Используем популярный модуль ИЛИ пилим те же ресурсы в чистом терраформе.
Выбор каждого.
- пример с модулем

module "aws-backup-notifications" {
  source                   = "terraform-aws-modules/notify-slack/aws"
  version                  = "6.5.1"
  sns_topic_name           = "aws-backup-notifications"
  recreate_missing_package = false
  slack_webhook_url        = data.sops_file.sops_file.data.slack-webhook-aws-backup-notifications.url"]
  slack_channel            = "aws-backup-daily-notifications"
  lambda_function_name     = "aws-backup-notifications"
  slack_username           = "AWS Health Event"
}

- пример без модуля будет нечто типа того (в попытке обезличить мог чушь написать, но на то он и пример).
https://gist.github.com/kruchkov-alexandr/e9139d60658175a5a91c186bd7e0f6b3

Ок теперь у нас есть лямбда, роли, пермишны, SNS топик.
При отправке мессаджа в SNS лямбда отправляет сообщение с метаданными в Slack.

2) Теперь нам надо научиться подписываться на события:

# RDS and DocumentDB cluster snapshot events

resource "aws_db_event_subscription" "db_snapshot_events" {
  name             = "aws-backup-notifications"
  sns_topic        = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
  source_type      = "db-cluster-snapshot"
  event_categories = []
  source_ids       = []
  enabled          = true
}

Если нам надо ещё и по Redis, то в существующих ресурсах добавить

resource "aws_elasticache_replication_group" "this" {
...
  notification_topic_arn = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
...
}

Ок, делаем вручную снепшот, видим мессаджи в Slack - задача выполнена.

4) Так, сообщение от Redis(ElastiCache) короткое и удобно читать в слаке, а вот через лямбду некрасивое и много лишней метаданных, давайте порежем лямбду...

oh wait, а час и закончился, сдаём как есть🤣.

Кому хочется красоты и лаконичности, тот знает прайс.

5) Не забываем напомнить заказчику не мьютить сразу новый слак канал #aws-backup-daily-notifications 😁

#aws

* для этой задачи для этих условий
Плюсы с модулем:
- 18 строчек кода
Минусы с модулем:
- мессадж гигантский, занимает половину экрана

Плюсы без модуля:
- можно сделать лямбду с минимальным мессаджем в слак
Минусы без модуля:
- ну в час не успеть
- много кода, либо пилить свой модуль

Не забывайте, что тут данная подписка на снепшоты кластера, на снепшоты инстансов это не распространяется.

Зачем замазывал event id я не знаю🤣

#aws

Опять observability.

Признаюсь, за весь свой опыт работы с алёртингом я больше тратил время не на технические задачи.
Сделать сбор метрик, отсеять лишние, повесить алёрты и создать каналы слака/телеграма, забив их людьми и повесив дежурство это на самом деле не сложно.
Не сложно и напилить борды в графане и сделать линк до инцидента в самом алёрте.
Технические задачи решаются легче всего.

Самое сложное сперва было
- разобраться с severity levels
- сделать порядок (флоу?rule?) куда чего и как будет идти
- понять кто за что ответственен

Вот допустим мы говорим строго про инженеров платформы/инфраструктуры.
Чего мы хотим видеть в северити:
- info - информативные сообщения, которые скорее всего будут добавлены в канал оповещения с mute и лезть мы туда будем постфактум "а чо было". Например что джоба в кубере выполнялась больше 25 минут.
- warning - предупреждения, что скоро будет не ок. Например 80% заполнения диска на критикал инфре. Пока не проблема, но может стать проблемой в будущем.
- critical - ну тут понятно. Кластер упал, место закончилось, бизнес аппликейшн последние 3 минуты выдает 502 ошибки и всё легло.
Никаких вопросов тут не вызывало никогда у меня, ни развесить северити, ни определиться с каналом оповещения.

А что делать со сторонними сервисами?
Мы так много говорим про девопс, но не можем самим себе ответить на простые вопросы.
Например ArgoCD.
Куда отправлять алёрты такого плана?

argocd_app_info{health_status!="Healthy"} != 0
argocd_app_info{sync_status!="Synced"} != 0

Девелоперам? Инженерам инфры? А если не прод, а demo/UAT кластер?
Нужно ли это смотреть девопсам?
В общий канал про прод критикал инциденты или отдельный для арго?
Если для арго, то один общий на все енвы или под каждый стенд/енв/проект?

Ладно, допустим арго не самая сложная штука.
Мы мониторим Azure Enterprise application (+service principle credentials expire).
Вот в аппликейшн не заходили полгода. Куда писать, чтобы удалить эту неиспользуемую? Это ворнинг или инфо?
Если креды протухнут скоро кому писать? Опсы и девопсы вообще не в курсе что это за креды и где они могут использоваться.

Airflow. Упал DAG.
опять кому писать? о чем?
То, что там нет метода это не важно опсам, но нужно QA.
А если DAG упал, потому что на нодах, где запускаются воркеры нет ресурсов, то это уже инфровая часть.
Как их разделять если там нет привычного label фильтрации.
Нужно ли знать о том, что в проде упал даг или это простая фигня не важная?

Усложняем задачи.
У нас есть базы данных и deadlock. Кому писать?
А дедлок по факту свершения или есть их +5 за последние 5 минут?
Это критикал или ворнинг?

Ладно, trino. На UAT долго повис запрос и сожрал всю память, а остальные 56 запросов висят в очереди час.
(кстати это аффектит и Airflow и всё ETL)
Кому об этом писать и как?


Наверное пора прийти к какому-то шаблону для тех, кто приходит с новым алёртом.
Думаю о варианте типа:
- автор алёрта(команда/человек)
- expr/metric+threashold
- какой severity алёрта
- в какой канал уведомлять(почта/слак/телеграм/голуби)
- правило, если каналов несколько
Нет этой информации - нет и алёрта.
Эх, мечты мечты, придут ко мне срочно и всё равно и без заявки и без ответственного лупану алёрт в общий канал.🤣

То есть большую часть занимают размышление и правильный флоу, чем написание кода и конфигов.

Основная же стратегия пока примерно такая:
- у каждого алёрта есть обязательный severity, который назначается при создании алёрта
например

- alert: JobFailed
  expr: kube_job_status_failed{} > 0
  labels:
    severity: info

- на всех метриках мы используем лейбл cluster(если он есть), либо обогащаем этим лейблом, если это не в кубере(например виртуальная машина)
- а затем через rules мы роутим в нужные каналы уведомлений согласно типа алёрта/кластера/имени алёрта/аутедж и так далее
- пример отобразил на графике

Это не финальный результат, наверняка буду менять не единожды, но это уже работает и большинство коллег устраивает.

#observability #alertmanager

"хей, у нас что-то с сервисом на проде, сможешь потраблшутить? Потом обсудим бюджет и оплату часов, сейчас надо понять что не так у нас. Что-то с SQS, очереди растут"

Ну пока супруга не видит, что работаю в выходные, пойду гляну🤣

Первым делом вижу, что всё так, очередь растёт и никто не читает.
https://1drv.ms/i/s!AhrWCTJApEtgjL9P66anxphCc0XgYA?e=Ie8O1F
Идём по конфигам смотреть кто должен читать очередь.
Ага, POD с именем webhook-*.
Смотрим сколько их

>k get pods | grep webhook | wc -l
50

Ок, а сколько у нас в HPA/KEDA

>ky hpa webhook |grep -A1 -i maxre
  maxReplicas: 50

Ага, упёрлись в максимум. А чо у нас триггер? Раз тут HPA, а не KEDA, то значит ресурсы, а не количество мессаджей.

>ky hpawebhook | grep -A6 -i metrics
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 85
        type: Utilization

В любом случае не важно что триггер - реплик итак уже 50. Всё, максимум.

Ок, что делает данный сервис, смотрим по коду:
- поллит sqs очередь, процессит и отправляет в RDS какие-то апдейты
Судя по значению в переменной ендпойнта - подключение идёт через RDS proxy (фу, опять он), это видно по названию.
Смотрим настройки RDS max connection - default по типу инстанс тайпу.
Смотрит настройки прокси, ничего необычного.

resource "aws_db_proxy_default_target_group" "this" {
  db_proxy_name = aws_db_proxy.rds_proxy.name
  connection_pool_config {
    connection_borrow_timeout    = 120
    max_connections_percent      = 80
    max_idle_connections_percent = 20
  }
}

Хм. смотрим нагрузку БД - всё ок.
https://1drv.ms/i/s!AhrWCTJApEtgjL9RXf8WRAW5oWUVyA?e=imAk16
Ничего сверхъестественного.

Первая мысль - а давай лупану hpa max replicas 100 вместо 50!! 🦍
Ну конечно же эту мысль сразу отбросил, так как х2 увеличение клиентов может банально положить базу. Там же какие инсёрты есть.
Да и странно это вообще выглядит - 50 подов не могу обработать какое-то вшивое количество сообщений(на момент траблутинга всего 151.000)?
Там не рокетсайнс, просто процессинг мессаджа и всё, алё.

Ок, давайте смотреть что на прокси.
https://1drv.ms/i/s!AhrWCTJApEtgjL9TS18jflKYNPp8_w?e=58iUjv
А там чётко всё.

Так давай пойдём считать настройки laravel horizon:
- тайауты айдл
- количество воркеров
- количество подов
- какой поллинг тайм
и так далее, в коде и настройках самого сервиса и гите.

Тут крик супруги ТЫ ТАМ ЧО ОПЯТЬ РАБОТАЕШЬ ЧТО-ЛИ????

Тактически перекатываюсь в другой экран windows ДА Я ТУТ ПАШКОВСКОГО СМОТРЮ, У НЕГО ВТОРОЙ ВЫПУСК ИЗ КУБЫ)))НУ ТЫ ЧО))
и начинаю думать судорожнее, да что не так то, давай без арифметики.
А может быть такое, что 50 подов со своими воркерами тупо заняли весь пул(на них выделенный) и им просто не хватает?
Ну тогда быстро решений несколько:
- увеличить количество max_connections_percent
- уменьшить connection_borrow_timeout
- увеличить количество maxreplicas HPA (но это теоретически может положить базу)
- семь бед один ресет

Перекатываюсь обратно и быстро грохаю все поды, а чо вы мне сделаете

>k delete pod -l=app=webhook

И та-дам!
Видим, что сбросив пулл на прокси мы практически мгновенно начинаем вычитывать очередь.
https://1drv.ms/i/s!AhrWCTJApEtgjL9Vyy6q2lsEK_AQwA?e=65qTxE
https://1drv.ms/i/s!AhrWCTJApEtgjL9X7WSdHh45PrU2-g?e=DGjEHi

Итог:
- а чего было не знаю, надо в арифметику в будние дни смотреть, наверняка в воркерах ошибка и там на условные 10 читки идёт 5 коннекшнов и оно просто херово сконфигурено
- иногда рестарт ок, если не персистент дата
- меня так и не спалили, что работал 🤣
- вообще надо бы проверить сколько max k8s clusters - чтобы не упёрлись в пределы
- вообще все sqs-related PODs надо перетащить на KEDA + trigger
О примерном конфиге я писал в другом чате https://xn--r1a.website/kubernetes_ru/875330

Трекаешь 2 часа😂
Можно идти дальше Пашковского смотреть.

#aws #troubleshooting #одинденьизжизни

Мои подписчики часто спрашивают меня
Господи, надеюсь я никогда не буду нести чушь инфоцыганщины🤣

Иногда я буду писать про свою продуктивность.
Это могут быть технические советы уровня junior после курсов, а могут быть крайне высокоуровневые штуки, которые могут не пригодится никому ещё долгое время. Если вы всё знаете и умеете, то просто скипайте.

Начнём с самого простого. Настройка рабочего места.
Я часто могу пересаживаться с рабочего Windows стационарного ПК на surface планшет и потом и вовсе на макбук.
Мне надо иметь всегда идентичное рабочее место и утилиты, как минимум консольные, и алиасы.

У меня через MS OneDrive (подписка MS office 365 family, ныне AI MS AI COPILOT AI 365 AI🤣) идет синхронизация всех важных мне файлов:
- ~/.bashrc файла
В нём всякие alias, кастомизации prompt и многое важное
- ~/.gitconfig настройки GIT
- ~/.ssh/config настройки SSH (например там у меня сетапы для jumphosts)
- ~/.cargo/config.toml настройки растоёба для RUST
Так же не маловажно отдельно выделю ASDF пакетный менеджер.
- ~/.tool-versions список утилит и их версий
- ~/.asdfrc собственно сам конфиг asdf
- ~/.asdf/plugins/ ТОЛЬКО для кастомных плагинов, у меня их всего 3

Для тех, кто незнаком с пакетными менеджерами, а всё ещё пользуется скачиванием бинарей с гитхаба.
- установил asdf один раз
https://github.com/asdf-vm/asdf/releases
- установил нужные плагины один раз

asdf plugin add golang
asdf plugin add nodejs
asdf plugin add python
asdf plugin add helm
asdf plugin add kubectl
asdf plugin add k9s
asdf plugin add flux
asdf plugin add terraform

- Создаём .tool-versions (один раз, потом иногда обновляем)

golang 1.22.0 1.21.6
nodejs 20.11.0 18.19.0
python 3.12.1 3.11.7
helm 3.14.0 3.13.3
terraform 1.7.2 1.6.6
kubectl 1.29.1 1.28.4
k9s 0.31.7 0.31.6
flux 2.2.3 2.1.2

- установил все тулзы

asdf install

И всё, больше ничего.

В случае же моего синка можно лупануть башизмом на новой тачке нечто типа такого

cut -d' ' -f1 ~/.tool-versions | xargs -I{} asdf plugin add {} && asdf install

Вы только подумайте.
Потерял ПК/заменил ПК/пересел на другое место(тем, кто в офис ходит и там стационар)/переобулся и стал маководом - засинкал файлы(удобным вам способом), ввел пару команд и у вас на вашем ПК:
- все известные вам утилиты известных вам версий установлены
- все привычные алиасы и настройки баша так же доступны
Не надо тратить снова сутки на настройку рабочего места.
Скорость готовности рабочего места зависит лишь от скорости интернета при скачивании пакетов.
Я ещё люблю саму фичу:
- на маке, допустим, обновил helm до 3.8, пересел на винду, а у меня там уже helm3.8, а не старая 3.6.
Невероятно удобно. Идентичная среда везде и всегда, никаких багов.

* все пакеты качаются из официальных репозиториев, никаких левых пакетов!
** файлы с креденшлами НЕ синхронизируются и так делать нельзя
*** альтернативы OneDrive: google drive, icloud, dropbox, yandex.disk
**** все файлы выше это лишь базовый пример, так-то у меня синкается значительно больше вещей.
***** все файлы из WSL2 залинкованы через

ln -s /mnt/c/Users/alex/OneDrive/wsl2/.bashrc ~/.bashrc

Если вы хотите начать, но не знаете с чего начать с asdf, можете смело украсть примеры с гитхаба у людей.
https://github.com/search?q=path%3A**%2F.tool-versions+kubectl&type=code
Полный список плагинов можно найти тут https://github.com/asdf-vm/asdf-plugins

Раньше я ещё синкал keybindings.json settings.json у VScode, но теперь это синкается автоматически через мой аккаунт средствами самого VScode.