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

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

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

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

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