Я студент и соло‑разработчик, который только начинает заходить в 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