Как ищешь причины медленной работы сервиса

Ага, слушай, вот как я обычно разбираюсь, когда сервис начинает тормозить, будто на дровах работает. Подход у меня, как у нормального инженера, — от макрокосма к микрокосму, от общего пиздеца к конкретному косяку. Беру данные мониторинга и логи, и начинаю копать, как крот ебаный.

1. Сначала смотрю на железо и виртуалки (USE-методология).

   • Utilization (Утилизация): Открываю Grafana или облачный мониторинг и смотрю, не жрёт ли процессор, память, диск или сеть дохуя. Ищу, где стрелочки упёрлись в потолок, в 100%. Если CPU на 95% — это уже волнение ебать.
   • Saturation (Насыщение): Тут ищу очереди, где всё встало колом. Смотрю на load average — если он высокий, а CPU прохлаждается, значит, всё ждёт какого-то ввода-вывода, диск, наверное, захлебнулся. Смотрю await в iostat — это как очередь в столовую, если большая, всем пизда.
   • Errors (Ошибки): Быстро гляжу, не сыпятся ли ошибки по сети или диску. Иногда проблема не в том, что медленно, а в том, что половина запросов накрылась медным тазом из-за какого-нибудь кривого коннекта.

2. Потом лезу в само приложение (RED-методология).

   • Rate (Частота): Сколько запросов в секунду летит. Резкий рост — может, его ддосят, а может, просто пользователи активничают.
   • Errors: Сколько запросов кончаются ошибкой. Если их овердохуища — сразу понятно, где искать.
   • Duration (Длительность): Самое вкусное — время ответа. Смотрю на перцентили p50, p95, p99. Если p50 в норме, а p99 зашкаливает — это классика, ёпта! Значит, какая-то часть запросов уходит в запой, обычно из-за какой-то одной медленной зависимости (БД, внешний API, другой микросервис).

3. Ну а если метрики намекнули, где болит, делаю глубокий дайвинг.

   • Распределенная трассировка (Jaeger, Zipkin): Если она есть — просто красота. Сразу видно, какой этап запроса тормозит, будто хуй в пальто. Прямо видно: "ой, а вызов к userservice занимает 2 секунды, вот же манда с ушами!"
   • Логи приложения: Беру и фильтрую логи по времени отклика. Ищу слова типа "slow", "timeout". Смотрю стек-трейсы — они часто показывают, где код пошёл по кривой дорожке.
   • Логи зависимостей: Обязательно смотрю логи базы данных. Там часто лежит ответ — какой-то ебанутый SQL-запрос без индекса сканирует миллионы строк. Логи кэша (Redis) и очередей (Kafka) тоже могут многое рассказать.

4. Конкретный пример, если сервис в Kubernetes. Допустим, поды тормозят. Делаю так:

   # 1. Быстро смотрю, кто ресурсы жрёт
   kubectl top pod -n <namespace>
   # 2. Сразу в логи, ищу всё, что связано со временем или ошибками
   kubectl logs -f <pod-name> --tail=100 | grep -E "(slow|timeout|error|duration)"
   # 3. Если подозрение падает на сеть — проверяю, а жива ли вообще зависимость
   kubectl exec -it <pod-name> -- curl -I --connect-timeout 5 <dependency-service-url>
   # 4. И конечно, лезу в базу. Классика жанра — медленный запрос.
   kubectl exec -it <postgres-pod> -- psql -U user -d db -c "SELECT query, total_time FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;"

   И знаешь, в 90% случаев причина оказывается в чём-то из этого списка: запрос к БД, который хуй с горы притащил, нехватка памяти у контейнера (он свопится, а потом все ждут), дикие сетевые задержки между сервисами, какие-то блокировки в коде или в той же БД, или, если приложение на JVM, — внезапная и жестокая сборка мусора (GC), которая всё останавливает. Главное — идти по шагам, а не метаться, как угорелый.