AndrewLucky
New member
Год назад нас было пятеро: два бэкендера, фронтендер, мобильный разработчик и я — одновременно тимлид, DevOps и «тот, кто помнит, где лежат дашборды». Наблюдаемость тогда выглядела так: кто-то писал в чат «упало», мы шли на прод, грепали логи по ssh и надеялись на удачу. После двух ночных инцидентов подряд я сел и собрал минимальный стек, который живёт до сих пор и не требует отдельного человека на поддержку. Делюсь тем, что реально прижилось, и тем, что мы безжалостно выкинули.
Начал я с логов, потому что с них начинается любой разбор. Мы договорились писать в stdout структурный JSON: уровень, имя сервиса, окружение, идентификатор трейса и текст отдельным полем. Логи уходят сборщиком в Loki, искать по ним можно за секунды, а не за десять минут. Главное правило, которое спасло наш бюджет: логам не место для «всего подряд». Дебаг на проде мы вырезали, оставили события с понятной ценностью и заменили часть строк метриками. Хранение подешевело почти втрое, а полезность выросла — теперь по логам действительно видно историю инцидента.
Дальше метрики. Тут я сознательно не стал строить «полную картину мира» и взял четыре сигнала: задержка, трафик, ошибки, насыщенность. Prometheus плюс Grafana закрывают наши потребности с запасом. На каждый сервис — один короткий дашборд, где видно состояние за последний час, а не сотни панелей на всякий случай. Отдельная боль — нейминг. Мы потратили пару вечеров на единый словарь названий метрик и меток, и это окупилось: новые дашборды собираются из готовых кубиков, а не изобретаются заново каждым разработчиком.
Трейсы были третьим этапом и, честно говоря, самым недооценённым. Мы подключили OpenTelemetry, настроили сэмплирование, чтобы не собирать весь поток, и получили то, за что я готов простить инструменту любые сложности: видно путь запроса между сервисами. Когда пользователь говорит «медленно», мы больше не спорим, чей сервис виноват, а открываем трейс и смотрим, где запрос застрял. Для команды из пяти человек это буквально экономия нескольких часов в неделю.
Самое ценное случилось, когда три части склеились. В логах появился идентификатор трейса, из метрик стали открываться конкретные примеры событий, а алерты теперь приходят в рабочий чат с готовым контекстом: что сломалось, с какого времени и где смотреть. Дежурный больше не бегает по пяти вкладкам и не собирает пазл вручную. Мы специально держим алерты только на симптомы, которые чувствует пользователь, а не на каждый скачок диска: иначе команда привыкает игнорировать уведомления, и это опаснее отсутствия мониторинга.
Теперь про то, чего мы избежали. Не поднимали собственный кластер Elasticsearch, не вешали APM-агенты на всё живое, не завели полноценные SLO с квартальными ритуалами и защитой бюджетов ошибок. Для пяти человек это оверинжиниринг: инструмент начинает требовать больше внимания, чем сам продукт. Мы также не стали ставить дежурство на каждое срабатывание — сначала довели шум до разумного уровня и только потом договорились о ротации. Правило простое: сначала дешёвое решение, потом усложнение, если оно доказало необходимость.
Что советую тем, кто только начинает с командой такого размера. Начните с логов — без них вы не поймёте даже, что именно случилось. Сразу договоритесь о формате записи и о том, что считать ошибкой. Метрики добавляйте набором, а не россыпью, и держите один дашборд на сервис. Трейсы подключайте, когда сервисов стало больше двух, раньше они просто не окупаются. Раз в месяц устраивайте получасовое ретро по инцидентам и вычищайте лишние алерты и панели — это самая полезная гигиена, которую я знаю. И не пытайтесь купить зрелость: её всё равно придётся вырастить самим.
Через год нас по-прежнему пятеро, а разбор инцидента занимает минуты вместо часов. Инструменты — это лишь половина дела, вторая половина — договорённости внутри команды. А как у вас? Каким минимальным набором вы обходитесь и есть ли среди ваших приёмов тот, что однажды реально спас вам ночь? Расскажите, я всегда рад подсмотреть хорошую идею у коллег.
Начал я с логов, потому что с них начинается любой разбор. Мы договорились писать в stdout структурный JSON: уровень, имя сервиса, окружение, идентификатор трейса и текст отдельным полем. Логи уходят сборщиком в Loki, искать по ним можно за секунды, а не за десять минут. Главное правило, которое спасло наш бюджет: логам не место для «всего подряд». Дебаг на проде мы вырезали, оставили события с понятной ценностью и заменили часть строк метриками. Хранение подешевело почти втрое, а полезность выросла — теперь по логам действительно видно историю инцидента.
Дальше метрики. Тут я сознательно не стал строить «полную картину мира» и взял четыре сигнала: задержка, трафик, ошибки, насыщенность. Prometheus плюс Grafana закрывают наши потребности с запасом. На каждый сервис — один короткий дашборд, где видно состояние за последний час, а не сотни панелей на всякий случай. Отдельная боль — нейминг. Мы потратили пару вечеров на единый словарь названий метрик и меток, и это окупилось: новые дашборды собираются из готовых кубиков, а не изобретаются заново каждым разработчиком.
Трейсы были третьим этапом и, честно говоря, самым недооценённым. Мы подключили OpenTelemetry, настроили сэмплирование, чтобы не собирать весь поток, и получили то, за что я готов простить инструменту любые сложности: видно путь запроса между сервисами. Когда пользователь говорит «медленно», мы больше не спорим, чей сервис виноват, а открываем трейс и смотрим, где запрос застрял. Для команды из пяти человек это буквально экономия нескольких часов в неделю.
Самое ценное случилось, когда три части склеились. В логах появился идентификатор трейса, из метрик стали открываться конкретные примеры событий, а алерты теперь приходят в рабочий чат с готовым контекстом: что сломалось, с какого времени и где смотреть. Дежурный больше не бегает по пяти вкладкам и не собирает пазл вручную. Мы специально держим алерты только на симптомы, которые чувствует пользователь, а не на каждый скачок диска: иначе команда привыкает игнорировать уведомления, и это опаснее отсутствия мониторинга.
Теперь про то, чего мы избежали. Не поднимали собственный кластер Elasticsearch, не вешали APM-агенты на всё живое, не завели полноценные SLO с квартальными ритуалами и защитой бюджетов ошибок. Для пяти человек это оверинжиниринг: инструмент начинает требовать больше внимания, чем сам продукт. Мы также не стали ставить дежурство на каждое срабатывание — сначала довели шум до разумного уровня и только потом договорились о ротации. Правило простое: сначала дешёвое решение, потом усложнение, если оно доказало необходимость.
Что советую тем, кто только начинает с командой такого размера. Начните с логов — без них вы не поймёте даже, что именно случилось. Сразу договоритесь о формате записи и о том, что считать ошибкой. Метрики добавляйте набором, а не россыпью, и держите один дашборд на сервис. Трейсы подключайте, когда сервисов стало больше двух, раньше они просто не окупаются. Раз в месяц устраивайте получасовое ретро по инцидентам и вычищайте лишние алерты и панели — это самая полезная гигиена, которую я знаю. И не пытайтесь купить зрелость: её всё равно придётся вырастить самим.
Через год нас по-прежнему пятеро, а разбор инцидента занимает минуты вместо часов. Инструменты — это лишь половина дела, вторая половина — договорённости внутри команды. А как у вас? Каким минимальным набором вы обходитесь и есть ли среди ваших приёмов тот, что однажды реально спас вам ночь? Расскажите, я всегда рад подсмотреть хорошую идею у коллег.