Лонгрид "история одного бага".
Часть 2 из 3.
Observability, v3
Было принято решение мониторить поэтапно, каждый элемент инфры отдельно, а не комплексно, как это было ранее.
Например не просто "базу", а "базу поэтапно.
Что приходит на приложении при обращении к прокси, что происходит на RDS proxy, что приходит от прокси до БД, что внутри БД. На всё метрики и новые дашборды. Где не было метрик - писали сами.
Часть в графине, часть в CloudWatch, смотря откуда source был или быстрее/удобнее.
Эээ трейсинг мониторинга?
Первая зацепка попалась впервые за много месяцев, когда появился дашборд RDS proxy и там был замечен спайк.
Честно говоря не представляю, кто первый придумал назвать это спайком, но дальше по всем post mortem данный фигурант назвался спайк. Спайк количество подключений клиента к БД. Вместо частых 300-500 спайки доходили до 40000(в зависимости от типа инстанса и от настроек, их меняли часто во время эксплуатации и траблшутинга)
И.. спайки совпали с временем жалоб "
ЧОТА ТОРМОЗИТ ИНОГДА".Радость, v1.
О чудо, кричала команда, мы нашли причину.
Однако радость быстро омрачилась осознанием того, что никто не знал ээээ а кто собственно создаёт спайки подключений и зачем? Все микросервисы, от монолита, макросервиса монорепы и других микросервисов сидели под одной учёткой на один ендпойнт.
Кастомизейшн, v1
Были созданы отдельные учётные записи для каждого сервиса.
И.. это ничего не дало.
Видно спайк, видно проблему, не видно источника.
Кастомизейшн? v2
Были созданы отдельные RDS proxy endpoint для каждого сервиса отдельно.
https://t.me/makebreakreflect/55
То есть каждый сервис со своими подами(независимо сколько их в скейлинге сейчас) подключается через отдельный эндпойнт RDS proxy, с отдельной учётной записи.
Радость, v2.
О чудо, снова закричала команда.
Радость улетучилась раньше, чем прошло эхо от коллективного крика.
Стало понятно, что нагрузка идет только на один определённый эндпойнт, только от конкретного юзера-приложения.
Команда глянула в код и.. это ничего не дало.
Приложением из монорепозитория.
У него буквально 1-2 параметра энтрипойнта других и немного другой функционал.
Сами параметры запуска этого сервиса 100% на влияют на проблему.
Грубо говоря у одного сервиса задача "слушай вебхуки, пушь в базу", у второго "слушай sqs, пушь в базу", а у третьего "слушай кафку, пушь в базу". Всё остальное одинаковое.
Observability, v4
Ок, команда знает про спайк, про нагрузку от RDS proxy от одного сервиса, но откуда оно?
Создаётся ещё несколько новых dashboard, устанавливается Performance insight от AWS.
Команда видит, что есть нагрузка на read/write IOPS область, снова читаются книги, статьи, снова оптимизация кода и инфры.
https://t.me/makebreakreflect/115