Описание проекта
Сейчас мы фактически слепы к тому, что происходит на продакшене. Логи разбросаны по десятку серверов, каждое приложение пишет в свои файлы и в своём формате, и когда что-то ломается, мы заходим по SSH и вручную грепаем гигабайты текста. Обычно о проблеме мы узнаём уже после того, как о ней сообщил клиент. Хотим решить это нормально: построить централизованный стек логирования и observability, который собирает логи и метрики с каждого сервера и каждого сервиса в одно место с поиском, чтобы вся команда видела картину, не заходя на сами машины.
Целевая архитектура — кластер ELK или OpenSearch для логов плюс Grafana для метрик и визуализации. От исполнителя ждём разворачивания сборщиков логов на наших хостах, нормализации и разбора входящих потоков в структурированные поля и проектирования дашбордов, понятных и инженерам, и руководству. Поверх этого нужен алертинг: уведомлять, когда растёт доля ошибок, когда задержка ответа переходит порог, когда сервис перестаёт слать данные или заканчивается место на диске и память. Оповещения должны приходить в те каналы, которыми мы уже пользуемся, с адекватными порогами, чтобы не тонуть в шуме.
Хранение и его стоимость для нас важны. Просим настроить жизненный цикл индексов и ротацию так, чтобы свежие данные оставались горячими и доступными для поиска, а старые логи по расписанию уходили в архив или удалялись. Опишите архитектуру, правила парсинга и порядок подключения нового сервиса к конвейеру, чтобы наша команда могла дальше поддерживать и расширять систему сама. Если вы уже вели такой стек в продакшене, расскажите, как рассчитали бы его под наши объёмы.
— Сбор логов с Linux-серверов и контейнеризированных приложений
— Структурный разбор, индексация и политика хранения
— Дашборды Grafana по ошибкам, задержкам и ресурсам
— Алерты на всплески ошибок, задержки и молчащие сервисы
Целевая архитектура — кластер ELK или OpenSearch для логов плюс Grafana для метрик и визуализации. От исполнителя ждём разворачивания сборщиков логов на наших хостах, нормализации и разбора входящих потоков в структурированные поля и проектирования дашбордов, понятных и инженерам, и руководству. Поверх этого нужен алертинг: уведомлять, когда растёт доля ошибок, когда задержка ответа переходит порог, когда сервис перестаёт слать данные или заканчивается место на диске и память. Оповещения должны приходить в те каналы, которыми мы уже пользуемся, с адекватными порогами, чтобы не тонуть в шуме.
Хранение и его стоимость для нас важны. Просим настроить жизненный цикл индексов и ротацию так, чтобы свежие данные оставались горячими и доступными для поиска, а старые логи по расписанию уходили в архив или удалялись. Опишите архитектуру, правила парсинга и порядок подключения нового сервиса к конвейеру, чтобы наша команда могла дальше поддерживать и расширять систему сама. Если вы уже вели такой стек в продакшене, расскажите, как рассчитали бы его под наши объёмы.
— Сбор логов с Linux-серверов и контейнеризированных приложений
— Структурный разбор, индексация и политика хранения
— Дашборды Grafana по ошибкам, задержкам и ресурсам
— Алерты на всплески ошибок, задержки и молчащие сервисы
Администрирование Наличные, Банковский перевод
