Logstash является хорошим сборщиком логов, и хорошо, когда приложение, с которого собираются логи, можно настроить так, чтобы оно слало логи на выбранный порт. Но что делать, если такой возможности нет? Или это вообще не приложение, а некая железка в сети? И умее она слать только на 514 порт?
Конечно можно сделать перенаправление пакетов на уровне iptables. Но, с моей точки зрения, решение не очень элегантное и тяжело контролируемое.
Можно воспользоваться CAP_NET_BIND_SERVICE, однако и это решение имеет минус, связанный с тем, что в нем отсутствует возможность контролировать какие конкретно привелигерованные порты может использовать приложение.
В этой статье я кратко опишу решение, которое понравилось лично мне.
Решил потестировать мультиязычный плагин для jekyll.
На просторах сети нашел приличное количество оных, но для первой пробы решил выбрать jekyll-language-plugin.
Установка плагина подробно описана на wiki проекта.
Однако беглый обзор показал, что реализация данного плагина требует файл с переводами для всего. Если я правильно понял, то пост надо забивать в такой файл, а потом вызывать весь пост как переменную. Возможно я что-то понял не так, но в итоге этот плагин мне не понравился.
Дальнейшее исследование привело меня к jekyll-multiple-languages-plugin. Тут уже в документации описано, что статьи или страницы можно хранить в .md файлах в специпльных “языковых” директориях и импортировать их при помощи % include file %.
Этот вариант понравился мне больше.
Правда радость была не долгой. Плагин отказался работать “из коробки”. Ошибка в коде, отвечающем за определение статики сайта. В итоге при попытке сбилдить сайт получал jekyll 3.6.2 | Error: can't dup NilClass. Добрае люди уже поправили ошибку и сделали PR в github, но разработчики не торопяться его принимать. Печалька, но можно поправить руками.
После патчинга модуля сборка заработала. Создать переводимую страницу (page в терминах jekyll) получилось без особых проблем. Однако для моего блога перевод статей, а точнее его текущее отсутсвие, привело к тому, что после сборки все статьи не сгенерились. После исключения из обработки директории с постами, при помощью директивы exclude_from_localizations в _config.yml удалось собрать сайт с переведенной страницей и не переведенными постами.
Пример двухязычной страницы можно посмотреть тут.
Сталкнулся с необходимостью мониторить метрики собираймые с хостов при помощи telegraf.
Описание задачи
Есть хост с icinga2 занимающийся мониторингом разного и рассылающий алерты соответствующим людям. Так же есть метрики с хостов, собираемые telegraf, хранящиеся в influxdb. Нужно реагировать на метрики и присылать алерты с incinga2.
Реагирование на метрики
Можно насти разные подходы для процуссинга метрик с хоста, но разработчики influxdb имеют специализированный engine для этой задачи. Дополнительно он решает вопрос реагирования на пики между активными проверками. А этот вопрос обязательно возникнет, если выбрать подход опроса influxdb активными проверками со стороны icinga2. Таким образом мы вибираем подход в котором данные с хостов процессятся в kapacitor.
Как и все в IT сайт нуждается в тестировании. Качество и количество тестов зависит от функциональности и значения сайта. Для своего блога я то же решил использовать тесты. Ну а так как все системные администраторы жутко ленивы, то и настроить автоматическую выкладку новых статей на github pages (в моем случае через travis-ci)
html-proofer
Первым инструментом тестирования я выбрал html-proofer. Он позволяет проверять ссылки сайта, правильность оформления изображений а так же работоспособность внутренних и внешних скриптов.
Для работы нужно установить gem или добавить строчку в Gemfile:
Я использую elasticsearch для централизованного хранения логов с серверов. Логов хранится много и каждый новый индекс ест ресурсы на сервере (статью об оптимизации используемых ресурсов для одной ноды можно посмотреть здесь). Однако это решение не спасает при хранении логов за очень большие периоды, в связи с чем я решил рассмотреть вариант хранения старых логов на отдельном сервере.
Т.к. речь идет именно о логах, то шансы изменения данных из прошлого стремятся к нулю. Это позволяет нам не думать о необходимости записи в старые индексы и просто хранить их на сервере (например более дешевом с медленными дисками).
Генеральная идея состоит в том, чтобы добавить дополнительную ноду данных в кластер и распределять индексы (indices) в зависимости от времени их создания.
