Логи на сотне серверов: в чём проблема

30 июня в 22:40 по Москве у «Гонца» перестали проходить оплаты. Клиенты нажимали «оплатить», ждали полминуты и видели ошибку. Служба поддержки получила сотню жалоб за двадцать минут. Дежурный разработчик открыл ноутбук, и тут началось самое интересное: а где искать?

Эта часть раздела про то, как сделать так, чтобы ответ на этот вопрос находился за минуту. Начнём с того, почему он не находится сам.

Как выглядит один сервер

Когда у проекта один сервер, всё просто. Приложение пишет логи в файл /var/log/app.log, а ошибку ищут командой grep:

ssh app-1
grep "ERROR" /var/log/app.log | tail -20

Это работает, пока серверов один-два.

Как выглядит «Гонец»

У «Гонца» сейчас десяток серверов: балансировщики nginx, сервисы заказов, платежей и маршрутизации, каждый в нескольких экземплярах в контейнерах. Запрос на оплату проходит через nginx, сервис заказов и сервис платежей, и каждый пишет о нём свою строку на своём сервере. Чтобы понять, что случилось с одной оплатой, дежурному надо:

1. Знать, куда идти. На каком из пяти экземпляров сервиса платежей был именно этот запрос? Балансировщик раскидывает их случайно.
2. Зайти на каждый сервер. Десять ssh-сессий, десять grep. В инцидент, когда счёт идёт на минуты.
3. Сопоставить время. nginx пишет время по Москве, сервисы в UTC, один старый сервис в своём формате.
4. Сопоставить запросы. Как понять, что строка в логе nginx и строка в логе платежей про один и тот же запрос?
5. Найти логи вообще. Контейнер, который упал в 22:41, перезапустился, и его логи пропали вместе со старым контейнером.

А ещё логи растут: сотни мегабайт в день на сервер. Через неделю диск заполнен, и кто-то настраивает удаление старых файлов. Логи трёхнедельной давности, которые понадобились для разбора жалобы, уже удалены.