Stail: по следам Jetty Continuations

stail-logoКто из нас не пользовался прекрасной утилитой tail, способной выводить несколько последних строк из файла для мониторинга состояния своего сервера или приложения. Но я, как человек, вынужденный постоянно просматривать множество логов, устаю от необходимости заходить на сервер по ssh и набивать длиннющую команду tail -f /чотатам.log. Идея автоматизировать этот процесс появилась как фриланс заказ. Оказалось, что существуют компании, политики безопасности которых запрещают доступ даже (sic!) на просмотр логов на сервере. Задача была проста: написать standalone веб-сервер, выполняющий функции tail. Будучи запущенным, веб-сервер должен был щедро раздавать содержимое логов. Прикинув варианты, я пришел к выводу, что «такая корова нужна самому». Конечно, я осознавал, что в сети, возможно, существует тысяча плюс один аналог, но черт возьми! Я же программист, я наконец-то смогу применить все эти новомодные технологии в нужном продукте.

Технологии и средства:

  • Maven — инфраструктура проекта, осуществляет загрузку зависимостей и сборку исполняемого jar-файла.
  • Jetty Standalone WebServer — основа, веб-сервер, включенный в исполняемый jar-файл. Хорошо документирован, клиентский код сервера не превышает 15 строчек.
  • Jetty Continuations — фирменная штучка jetty, позволяет элементарно организовать long_polling. Файл логов может обновляться весьма редко, а значит без этой технологии не обойтись, не хочу множить ajax-запросы там, где это не надо.
  • Java scripting API — конфигурирование stail должно быть максимально простым, поэтому конфигурационный файл решено было оформить в виде валидного .js кода. А мощное API позволит получить к ней доступ ценой в пару строчек кода.
  • easyXDM  — средство для безболезненной реализации кросс-сайтового ajax. stail состоит из двух частей: фронт-энд (html & js) и  бэк-энд (сервер, обрабатывающий ajax-запросы фронт-энда).
  • JUnit  — спас проект от развала, благодаря набору тестов удалось поменять идеологию проекта с неправильной на правильную без серьезных потерь во времени.

Пишем правильно:

  1. Писать свою реализацию tail — глупо. Даже если я буду корпеть над кодом несколько недель, моя реализация будет не так хороша как та, что идет в комплекте с любой «хорошей» ОС. А значит, нужно запускать tail как отдельный процесс и перенаправлять его вывод на наш фронт-энд. И не только tail, благодаря такой идеологии пользователь сам будет определять что ему нужно запустить, а мы будем перенаправлять вывод консоли на фронт-энд. Просто и понятно.
  2. Вначале пишем тесты, затем код, реализующий эти тесты. Пишем движок.
  3. Используем ExecutorService для запуска процессов — не плодим потоки, используем cached pool.
  4. Ни одна ошибка не должна пропасть — регистрируем все отчеты об ошибках и желательно там, где администратор их ожидает увидеть.
  5. Думаем о безопасности, дабы наши логи не вытащили злоумышленники кросс-сайтовыми ajax-запросами; предусматриваем опцию контроля доверенных доменов.
  6. Разделение на фронт-энд и бэк-энд подразумевает, что они запускаются отдельно, на разных серверах. Но пользователь не должен мучаться с запуском отдельно фронт-энда и бэк-энда. Предусматриваем опцию конфигурации на интеграцию пользовательского фронт-энда в бек-энд.
  7. Документируем, тестируем.

Stail-1.1

Разворачиваем на Ubuntu, для других систем все полностью аналогично, только нужно указать существующие лог-файлы.

1. Скачиваем и распаковываем релизный архив или исходники.

$ mkdir stail
$ cd stail
$ wget http://stail.googlecode.com/files/stail-1.1.zip
$ unzip stail-1.1.zip

2. Правим конфигурацию (краткое описание всех свойств конфигурации указано в readme)

$ emacs -nw config.js

Конфигурация по умолчанию примерно такая:

var server = {
   port: 8080,
   frontend: "front-end"
};

var tails =
[
   {command: "tail -f -n 1000 /var/log/dmesg", size: 1000, alias: "dmesg"},
   {command: "tail -f /var/log/syslog", size: 800, alias: "syslog"},
   {command: "tail -f /var/log/udev"}
];

var trustedOrigins = [(/.*/)];

server.port — порт сервера.

server.frontend — та самая опция, которая указывает серверу, что папка «front-end» должна быть доступна через http://domain:port/front-end/

tails — список команд, вывод которых будет доступен через фронт-энд.
trustedOrigins — регулярное выражение, определяет доверенные домены. Указано — любые домены.

3. Убедимся, что фронт-энд настроен на наш сервер

$ emacs -nw front-end/index.html
Ищем и правим, если нужно, переменную server.
var server = "http://localhost:8080";

4. Запускаем:

$ java -jar stail.jar config.js

5. Наслаждаемся, http://localhost:8080/front-end/index.html.


stail

 

Примечание: index.html писать обязательно, сервер строго отображает директорию в веб. Так же информацию по серверу можно почитать, зайдя по адресу http://localhost:8080/info.

Что дальше:

  • Перевод документации на англиский
  • Заполнение странички проекта информацией и примерами

Если кого-либо интересуют подробности реализации, обращайтесь 🙂

Реклама

One thought on “Stail: по следам Jetty Continuations

  1. А я только хотел реализовывать что-то подобное, только на си, и случайно набрел на ваш ресурс. Через пару дней протестирую, но в любом случае вы делаете полезное дело! Cпасибо!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s