Централізований збір логів і observability для наших серверів

Зараз ми по суті сліпі до того, що відбувається на продакшені. Логи розкидані по десятку серверів, кожен додаток пишає в свої файли і у своєму форматі, і коли щось ламається, ми заходимо по SSH і вручну грепимо гігабайти тексту. Зазвичай про проблему ми дізнаємось вже після того, як про неї сповістив клієнт. Хочемо вирішити це нормально: побудувати централізований стек логування і observability, який збирає логи і метрики з кожного сервера і кожного сервісу в одне місце з пошуком, щоб уся команда бачила картину, не заходячи на самі машини.

Цільова архітектура — кластер ELK або OpenSearch для логів плюс Grafana для метрик і візуалізації. Від виконавця чекаємо розгортання збирачів логів на наших хостах, нормалізації і розбору вхідних потоків у структуровані поля і проектування дашбордів, зрозумілих і інженерам, і керівництву. Поверх цього потрібен алертинг: сповіщати, коли зростає частка помилок, коли затримка відповіді переходить поріг, коли сервіс перестає надсилати дані або закінчується місце на диску і пам'ять. Сповіщення мають надходити в ті канали, якими ми вже користуємось, з адекватними порогами, щоб не тонути в шумі.

Сховище і його вартість для нас важливі. Просимо налаштувати життєвий цикл індексів і ротацію так, щоб свіжі дані залишалися гарячими і доступними для пошуку, а старі логи за розписанням йшли в архів або видалялись. Опишіть архітектуру, правила парсингу і порядок підключення нового сервісу до конвеєру, щоб наша команда могла далі підтримувати і розширювати систему сама. Якщо ви вже вели такий стек в продакшені, розкажіть, як би ви розрахували його під наші обсяги.

— Збір логів з Linux-серверів і контейнеризованих додатків
— Структурний розбір, індексація і політика зберігання
— Дашборди Grafana по помилкам, затримкам і ресурсам
— Алерти на сплески помилок, затримки і мовчазні сервіси