Ночь, бессонница.
Горение.

Читаю комментарии к разным статьям про развитие UI/UX, про размеры приложений на телефон в 1300 мегабайт для чтения pdf файлов без редактирования.
Про максимально ставший абсолютным рекордсменом говна - ноушн. Я словно Нео в драке с мистером Андерсоном отбиваюсь каждый день от новых всплывающих окон с НУ ВОТ ТЕПЕРЬ ТОЧНО НОВАЯ ПОЛЕЗНАЯ ФИЧА ХОТЬ ТЫ И НЕ ПРОСИЛ НА ВОТ СОРТИРУЙ СВОИ СЧЕТА ЗА АПРЕЛЬ ПО НОВОМУ AI В ЗАМЕТКАХ.
Не менее всратый слак - джигурдаллион фичей ежедневно, половина из них умерло до их релиза и, особенно, использования реальными людьми.
Везде AI. Везде pop-up, бесячая джира и конфлюенс каждый день(!) высирает новые окошки с новой абсолютно бесполезной херней.
Мы уже даже привыкли их закрывать, многим реально понасрать что там у вас вышло.
Ноушн, банк клиент, стриминг плеер. Открыл Яндекс музыку - автоматически оформил ипотеку в Перми.
Люди, разработчики, аналитики, корпорации - все они/мы перестали делать ПРОСТО ПРИЛОЖЕНИЕ.
То, ради чего к ним пришли и пользуются/платят.
Не добавляя сторизы в калькулятор, не добавляя предложение о кредите в фотоальбом.
Все наши телефоны от 50 баксов с Али до топов за 3000, умеют на Марс летать и рассчитывать орбиту геостационарных спутников за 0.00001наносекунд, но ослиное приложение по просто вызову такси тормозит так, что я уже пешком дошёл, потому что у нас ЭКОСИСТЕМА СУПЕРАПП.😂
Я реально прекратил пользоваться около 25 приложениями, потому что вместо простого и обещанного функционала оно превратилось в ишачий кал с AI и сторизами от курьеров-случайных-контактов из Узбекистана.
Кое-кто даже перестал выполнять свою изначальную функцию, что печалит.

Бог с ним, с размером, благо у нас больше не дискетки, что произошло с главным - функционалом?

Что не так с индустрией? Почему мы начали делать говно?
Не соглашусь, что мы всегда делали говно, ещё есть приложения, которые всё ещё просто делают свою работу.
Кто виноват? Зумеры айтишники? AI проклятый век? Эффективные менеджеры?
Старые пердуны сишники?
Вкатуны(как я)? Или всё испортили статьи про аджайл и влажные маня фантазии инвесторов?

Кому разбить лицо?

* Возгорание произошло из-за обновления Spotify, он мне на ПК вертикальные сторизы-тизеры-песен-без-способности-прослушать-весь-трек выдал😂. На ПК🤭.
Зачем это дерьмо вообще релизили?

Реальность 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