Между tail и ELK: пытаюсь собрать логи с нескольких серверов одной командой

Я студент и соло‑разработчик, который только начинает заходить в devops‑тематику. Сам я не админ и не держу в проде десяток серверов, поэтому решил не выдумывать «боли» из головы, а посмотреть, на что реально жалуются люди в статьях и форумах.

Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»

После этого я решил собрать небольшой прототип LogRanger — CLI‑утилиты, которая по SSH забирает логи с нескольких серверов и открывает их в lnav одной командой. Ниже коротко расскажу, какую проблему хочу закрыть и что именно делаю.

Проблема в двух картинках: ssh → tail/grep → беготня по серверам

Типичный сценарий, который я увидел в обсуждениях, выглядит так:

• есть несколько Linux‑серверов (web‑ноды, app, база);

• происходит инцидент — ошибки 5xx, падает деплой или ведёт себя странно сервис;

• чтобы понять, что произошло, админ открывает несколько ssh‑окон и запускает на каждой машине свой tail -f или grep по логам.

Каждый раз приходится:

• помнить, где лежат нужные логи на каждой ноде;

• держать в голове фильтры и временные диапазоны;

• перезапускать команды после ротации логов;

• копировать куски логов к себе, чтобы сравнить их между серверами.

Да, у этой боли есть решения: syslog‑ng, ELK, Graylog и другие системы централизованного логирования. Но поднятие и обслуживание такого стека ради нескольких сервисов и десятка машин для многих выглядит избыточно: нужно настраивать syslog на всех серверах, держать отдельный лог‑сервер, думать про отказоустойчивость и т.д. В итоге многие продолжают жить в связке ssh + tail/grep + самописные костыли.

Идея LogRanger: тонкая обёртка поверх SSH и lnav

Я не хочу делать ещё один «мини‑ELK» или переписывать лог‑viewer. Вместо этого LogRanger задуман как небольшая CLI‑обёртка вокруг того, что уже есть:

LogRanger по SSH собирает логи с нескольких серверов, раскладывает их по понятной структуре и запускает lnav с нужными пресетами.

Базовая идея такая:

1. Вы описываете окружения и сервисы в конфиге logranger.yml:

   • какие есть окружения (staging, prod),

   • какие хосты к ним относятся,

   • какие файлы считать логами nginx, приложения, базы и т.п.

2. При инциденте вы вместо «ручного» ssh‑ритуала делаете:

# Собрать логи nginx с прод-серверов за последние 30 минут
logranger collect --env prod --service nginx --since 30m
# Открыть их в lnav с готовым пресетом
logranger view --env prod --service nginx
# Собрать логи nginx с прод-серверов за последние 30 минут 
logranger collect --env prod --service nginx --since 30m  
# Открыть их в lnav с готовым пресетом 
logranger view --env prod --service nginx 

Внутри collect подключается по SSH к нужным хостам, забирает логи в локальную директорию вроде/tmp/logranger/prod/nginx/<host>/…, а view запускает lnav на этих файлах с заранее подготовленными форматами/фильтрами под nginx (или другой сервис).

Важный момент: LogRanger не лезет в вашу инфраструктуру — он работает поверх уже настроенного SSH и готовых лог‑файлов. Никаких агентов и изменений syslog, только CLI.

Несколько сценариев, под которые я это делаю

1. Ночной алерт на проде

• Мониторинг прислал алерт 5xx.

• У вас 3 web‑ноды за балансировщиком.

Сейчас это часто:

• ssh на web‑01 → tail/grep;

• ssh на web‑02 → tail/grep;

• ssh на web‑03 → tail/grep;

• копипаста фрагментов в локальный файл, чтобы сравнивать.

Цель LogRanger:

bashlogranger collect --env prod --service nginx --since 30m
logranger view --env prod --service nginx
logranger collect --env prod --service nginx --since 30m logranger view --env prod --service nginx

И дальше уже работа в lnav: фильтры, поиск по времени, быстрый просмотр ошибок на общем таймлайне.

2. Падение деплоя на staging

• После выката новый релиз падает на staging.

• Нужно быстро посмотреть логи приложения и базы.

Сценарий:

bashlogranger collect --env staging --service app --since 15m
logranger view --env staging --service app
logranger collect --env staging --service app --since 15m logranger view --env staging --service app

Это эксперимент, а не релиз

Отмечу сразу: сейчас LogRanger в стадии прототипа.

Уже есть:

• базовая идея и архитектура;

• черновой CLI‑каркас;

• первые команды для локального сбора логов и запуска lnav;

• лендинг, через который я валидирую интерес.

Пока нет:

• красивого UX вокруг ошибок и всех edge‑кейсов;

• набора готовых пресетов под разные стеки (кроме самых базовых);

• упаковки в удобные бинарники под разные системы.

Я не воспринимаю это как «готовый продукт». Это учебный и предпринимательский эксперимент: можно ли, опираясь на жалобы из публичных обсуждений, сделать маленький инструмент, который кому‑то реально сэкономит время.

Что я хочу проверить этим постом

Для себя я формулирую это как проверку трёх гипотез:

1. Болит ли у вас вообще сценарий «несколько серверов → ручной сбор логов по SSH → попытка собрать картину»?

2. Кажется ли вам полезной идея: «собрал логи по SSH одной командой → открыл их в удобном viewer’е со сшитым таймлайном»?

Если вам откликается боль — можно помочь протестировать идею

В рамках этого эксперимента я сделал небольшой лендинг с описанием LogRanger и формой для раннего доступа.

Если вам знакома описанная рутина и вы хотели бы потыкать инструмент вживую:

• перейдите на лендинг (ссылку оставлю ниже);

• оставьте email для участия в тестировании;

• когда прототип будет готов, я пришлю бинарь и короткую инструкцию.

Взамен я попрошу только одно: честный фидбек. Что удобно, чего не хватает, и увидели ли вы вообще экономию времени по сравнению с вашим текущим ssh‑ритуалом.

P.S. Этот пост не про «готовое решение», а про учебный эксперимент. Если вы практикующий devops — мне скорее нужен ваш взгляд со стороны, чем аплодисменты.
Если вы считаете, что такая утилита не нужна или идея провальная — будет круто, если вы расскажите почему. Я хочу научиться видеть такие вещи заранее и не тащить в разработку то, что никому не помогает.

Лендинг доступен по ссылке logranger.vercel.app ^[1]