Cyberflow

Запуск logstash pipeline на привелигерованных портах

Tue, 05 Feb 2019 00:00:00 +0000

Logstash является хорошим сборщиком логов, и хорошо, когда приложение, с которого собираются логи, можно настроить так, чтобы оно слало логи на выбранный порт. Но что делать, если такой возможности нет? Или это вообще не приложение, а некая железка в сети? И умее она слать только на 514 порт?

Конечно можно сделать перенаправление пакетов на уровне iptables. Но, с моей точки зрения, решение не очень элегантное и тяжело контролируемое.

Можно воспользоваться CAP_NET_BIND_SERVICE, однако и это решение имеет минус, связанный с тем, что в нем отсутствует возможность контролировать какие конкретно привелигерованные порты может использовать приложение.

В этой статье я кратко опишу решение, которое понравилось лично мне.

Настройка authbind

Opensource утилита, позволяющая разрешать приложениям использовать привелигированные порты без прав суперпользователя (root).

Утилита доступна в репозиториях debian/ubuntu и устанавливается через sudo apt-get install authbind.

Настраивается утилита достаточно просто: Например, чтобы разрешить приложению, запускаемому под пользователем logstash использовать порт 514, необходимо сделать следующее:

Создать файл в /etc/authbind/byport/
```
sudo touch /etc/authbind/byport/!514
```
Использование “!” при создании файла указывает на протокол UDP.
Дать прова на созданный файл, соответствующему пользователю:
```
sudo chown logstash /etc/authbind/byport/!514
```
Очевидно, что этот шаг указывает какому конкретно пользователю разрешено использовать соответствующий привелигерованный порт.
Дать прова на полное использование файла для пользователя
```
sudo chmod 755 /etc/authbind/byport/!514
```

Настройка logstash

Для того, чтоб logstash получил доступ до привелигерованных портов, необходимо добавить в строку запуска usr/bin/authbind --deep до запуска самого logstash.

Это можно сделать путем редактирования юнита systemd. Должно получиться что-то вроде этого:

[Unit]
Description=logstash

[Service]
Type=simple
User=logstash
Group=logstash
EnvironmentFile=-/etc/default/logstash
ExecStart=/usr/bin/authbind "--deep" "/usr/bin/authbind" "--deep" "/usr/share/logstash/bin/logstash" "--path.settings" "/etc/logstash"
Restart=always
WorkingDirectory=/
Nice=19

[Install]
WantedBy=multi-user.target

Однако хочется заметить, что logstash имеет свой скрипт настройки юнитов systemd. И, мне кажется, что правильнее использовать его, для настройки systemd юнитов. Но, к сожалению, их коробки он таких штук, как обертка для запуска не умеет. Но добавить руками эту функцию не сложно. В фале /usr/share/logstash/bin/system-install надо поправить строчку:

program="$(cd `dirname $0`/..; pwd)/bin/logstash"

и поправить на:

program="/usr/bin/authbind --deep $(cd `dirname $0`/..; pwd)/bin/logstash"

Теперь запустив этот скрипт мы получим новый systemd юнит с authbind.

testing jekyll language plugins

Wed, 13 Dec 2017 16:14:00 +0000

Решил потестировать мультиязычный плагин для 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 удалось собрать сайт с переведенной страницей и не переведенными постами.

Пример двухязычной страницы можно посмотреть тут.

send kapacitor alert to Icinga 2

Fri, 08 Dec 2017 15:28:00 +0000

Сталкнулся с необходимостью мониторить метрики собираймые с хостов при помощи telegraf.

Описание задачи

Есть хост с icinga2 занимающийся мониторингом разного и рассылающий алерты соответствующим людям. Так же есть метрики с хостов, собираемые telegraf, хранящиеся в influxdb. Нужно реагировать на метрики и присылать алерты с incinga2.

Реагирование на метрики

Можно насти разные подходы для процуссинга метрик с хоста, но разработчики influxdb имеют специализированный engine для этой задачи. Дополнительно он решает вопрос реагирования на пики между активными проверками. А этот вопрос обязательно возникнет, если выбрать подход опроса influxdb активными проверками со стороны icinga2. Таким образом мы вибираем подход в котором данные с хостов процессятся в kapacitor.

Настройка kapacitor-а

Kapacitor имеет таски, в которых описывается что и как должно мониторится. Кроме стандартных <>= можно настроить собственную систему Anomaly Detection. Тут я не буду вдаваться во все подробности. Нас интересует только тот момент, что каждая таска имеет в конфигурации блок alert. Там можно настроить передачу события в обработчик алертов. В kapacitor представленно много уже готовых обработчиков, таких как email, HipChat, Slack, Telegram, PagerDuty, etc. но, к сожалению, нет ни одного, способного нативно отправить событие в icinga2. Но разработчики предусмотрели обработчик exec, который может выполнить программу на локальной машине. Его мы и будем использовать.

Так же отмечу, что для моих нужд оказалось проще и практичнее использовать topic. Topic - это объект kapacitor в который разные таски могут присылать свои события и на этот топик подписывается обработчик этого топика, который одинакого опрабатывает все события в этом топике. Другими словами - если у нас есть несколько метрик для мониторинга, скажем Disk, CPU, Memory. Нам достаточно описать таски для всех и отправлять все события в один топик metric_events и подключив всего один обработчик пересылать все события в icinga2.

Пример описания таски с использованием топика:

stream
    |from()
        .measurement('cpu')
        .groupBy(*)
    |alert()
        .warn(lambda: "usage_idle" < 20)
        .crit(lambda: "usage_idle" < 10)
        .topic('metric_events')

Пример описания топика:

kind: exec
options:
  prog: "/path/to/plugin/alert_to_icinga2.py"
  args:
    - "-u"
    - "user"
    - "-P"
    - "password"

Сам же плагин для отправки событий в [icinga2] можно найти по ссылке https://github.com/cyberflow/kapacitor_alert_to_icinga2.git

Тестирование сайта на jekyll и авто-deploy на github pages

Sun, 19 Jun 2016 12:46:00 +0000

Как и все в IT сайт нуждается в тестировании. Качество и количество тестов зависит от функциональности и значения сайта. Для своего блога я то же решил использовать тесты. Ну а так как все системные администраторы жутко ленивы, то и настроить автоматическую выкладку новых статей на github pages (в моем случае через travis-ci)

html-proofer

Первым инструментом тестирования я выбрал html-proofer. Он позволяет проверять ссылки сайта, правильность оформления изображений а так же работоспособность внутренних и внешних скриптов. Для работы нужно установить gem или добавить строчку в Gemfile:

gem 'html-proofer'

Для быстрой ручной проверки можно выполнить следующие команды:

# bundle exec jekyll build
# bundle exec htmlproofer ./_site

Чтобы не проверять генерируемые jekyll кросслинки (например список категорий), можно добавить в шаблоны тэг data-proofer-ignore. ТАким образом можно уменьшить количество проверяемых ссылок:

<a href="http://notareallink" data-proofer-ignore>Not checked.</a>

Добавляем конфиг для travis-ci:

.travis.yml

language: ruby
rvm:
  - 2.1
branches:
  only:
  - source
env:
  global:
  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
gemfile:
  - Gemfile
script:
  - bundle exec jekyll build
  - bundle exec htmlproofer ./_site/

Так же надо добавить строчку в конфиг jekyll:

_config.yml

exclude: [vendor]

exclude: [vendor] - крайне важная строчка, т.к. travis ставит gem в корень проекта в директорию vendor. Если не добавить ее в исключения, jekyll будет пытаться обработать фалы gem-ов.

Тесты можно обернуть в rake таски для удобства.

Автодеплой на github pages

После удачного тестирования можно и залить изменения на сайт. Я использую две ветки в репозитории: source - для хранения исходников постов и потрошков jekyll и, соответственно, master - для самого блога. В итоге задача сводится к генерации сайта средствами jekyll на стороне CI и push в определенную ветку репозитория. Для этого можно использовать rake таски ruby. Вот пример:

Rakefile

#############################################################################
#
# Modified version of jekyllrb Rakefile
# https://github.com/jekyll/jekyll/blob/master/Rakefile
#
#############################################################################

require 'rake'
require 'yaml'

CONFIG = YAML.load(File.read('_config.yml'))
USERNAME = CONFIG['username'] || ENV['GIT_NAME']
REPO = CONFIG['repo'] || "cyberflow.github.com"
DEST = CONFIG['destination'] || '_deploy'

SOURCE_BRANCH = 'source'
DESTINATION_BRANCH = 'master'

def check_destination
  unless Dir.exist? DEST
    sh "git clone https://#{ENV['GIT_NAME']}:#{ENV['GH_TOKEN']}@github.com/#{USERNAME}/#{REPO}.git #{DEST}"
  end
end

namespace :site do
  desc 'Generate the site and push changes to remote origin'
  task :deploy do
    # Detect pull request
    if ENV['TRAVIS_PULL_REQUEST'].to_s.to_i > 0
      puts 'Pull request detected. Not proceeding with deploy.'
      exit
    end

    # Configure git if this is run in Travis CI
    if ENV['TRAVIS']
      puts 'Configure git'
      sh "git config --global user.name '#{USERNAME}'"
      sh "git config --global user.email '#{CONFIG['email']}'"
      sh 'git config --global push.default simple'
    end

    # Make sure destination folder exists as git repo
    check_destination

    # sh "git checkout #{SOURCE_BRANCH}"
    Dir.chdir(DEST) do
      sh "git checkout #{DESTINATION_BRANCH}"
      sh 'rm -rf *'
    end

    # Generate the site
    sh "bundle exec jekyll build -d #{DEST}"

    # Commit and push to github
    sha = `git log`.match(/[a-z0-9]{40}/)[0]
    Dir.chdir(DEST) do
      sh "git status -s"
      sh "git add --all ."
      sh "git commit -m 'Updating to #{USERNAME}/#{REPO}@#{sha}.'"
      sh "git push --quiet origin #{DESTINATION_BRANCH} --force"
      puts "Pushed updated branch #{DESTINATION_BRANCH} to GitHub Pages"
    end
  end
end

и теперь можно добавить деплой после удачного тестирования:

.travis.yml

...
before_install:
  - openssl aes-256-cbc -K $encrypted_d1eeda8dc2f5_key -iv $encrypted_d1eeda8dc2f5_iv -in travis_rsa.enc -out .travis/travis_rsa -d
script:
  - bundle exec jekyll build
  - bundle exec htmlproofer ./_site/
after_success:
  - eval "$(ssh-agent -s)" #start the ssh agent
  - chmod 600 .travis/travis_rsa # this key should have push access
  - ssh-add .travis/travis_rsa
  - bundle exec rake site:deploy

Ниже пояснения к блокам before_install и after_success. Необходимо добавить ключ для travis, чтобы иметь возможность деплоить в репозиторий.

Добавление ключа для деплоя из travis

Для того, чтобы travis смог деплоить наш сайт необходимо проделать еще один шаг. Надо добавить ключ в репозиторий. Для начала сгенерим новый ключ (я не советую использовать уже созданные ключи). Посмотреть как это нужно делать можно тут

# ssh-keygen -t rsa -b 4096 -C "travis"

После этого добавьте сгенеренный ключ в ваш репозиторий в настройках репозитория на github. Теперь надо закриптовать ключ для travis:

$ travis encrypt-file deploy_key
encrypting deploy_key for domenic/travis-encrypt-file-example
storing result as deploy_key.enc
storing secure env variables for decryption

Please add the following to your build script (before_install stage in your .travis.yml, for instance):

    openssl aes-256-cbc -K $encrypted_0a6446eb3ae3_key -iv $encrypted_0a6446eb3ae3_key -in super_secret.txt.enc -out super_secret.txt -d

Pro Tip: You can add it automatically by running with --add.

Make sure to add deploy_key.enc to the git repository.
Make sure not to add deploy_key to the git repository.
Commit all changes to your .travis.yml.

Миграция старых indices elasticsearch на другую ноду

Fri, 03 Jun 2016 12:41:00 +0000

Я использую elasticsearch для централизованного хранения логов с серверов. Логов хранится много и каждый новый индекс ест ресурсы на сервере (статью об оптимизации используемых ресурсов для одной ноды можно посмотреть здесь). Однако это решение не спасает при хранении логов за очень большие периоды, в связи с чем я решил рассмотреть вариант хранения старых логов на отдельном сервере.

Т.к. речь идет именно о логах, то шансы изменения данных из прошлого стремятся к нулю. Это позволяет нам не думать о необходимости записи в старые индексы и просто хранить их на сервере (например более дешевом с медленными дисками). Генеральная идея состоит в том, чтобы добавить дополнительную ноду данных в кластер и распределять индексы (indices) в зависимости от времени их создания.

Настройка кластера

Настройка мастер ноды

Пропуская процесс установки elasticsearch укажу лишь необходимые настройки:

elasticsearch.yml

node.master: true
node.data: true
node.node_type: hot
...
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["10.0.0.2"]

Нода будет иметь тэг hot и хранит индексы для быстрого доступа.

Настройка ноды дынных

elasticsearch.yml

node.master: false
node.data: true
node.node_type: warm
...
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["10.0.0.1"]

Нода будет иметь тэг warm и мы будем перемещать на нее устаревшие indices.

Перемещение

После подготовки нод надо перезапустить elasticsearch.

Убедиться, что ноды теперь в кластере можно командой:

$ curl http://localhost:9200/_cat/nodes

Следующая команда (для elasticsearch-curator < 4.X) поставит аттрибут аллокации для всех индексов старше 7 дней:

$ curator --logfile /var/log/curator.log --loglevel INFO --logformat default --master-only --host localhost --port 9200 allocation --rule node_type=warm indices --time-unit days --older-than 7 --timestring '%Y.%m.%d'

ниже конфиг action.yml для elasticsearch-curator >= 4.X:

---
actions:
  '1':
    action: allocation
    description: Apply shard allocation routing to 'node_type=warm' node
    options:
      key: node_type
      value: warm
      allocation_type: require
      wait_for_completion: False
      continue_if_exception: False
    filters:
    - filtertype: pattern
      kind: prefix
      value: logstash-
    - filtertype: age
      source: creation_date
      direction: older
      unit: days
      unit_count: 7

Теперь можно добавить команду curator-а, описанную выше, в cron сервера и перемещение будет происходить автоматически.

Оптимизация standalone сервера elasticsearch

Thu, 12 May 2016 12:12:00 +0000

При использовании elasticsearch для сбора и анализа логов возникает вопрос оптимизации для одного сервера. Т.к. elasticsearch расчитан для использования в кластере, то большинство настроек “по умолчанию” выставлены так, что один сервер работает не эффективно. В этой заметке я разберу несколько примеров оптимизации elasticsearch для работы на одном сервере.

Shards

Первое что нужно знать, что каждый шард использует пямять и процессор. При использовании elasticsearch и logstash получается, что каждый день logstash создает новый indice, а дефолтные настройки elasticsearch создают 5 шардов в каждом индексе. В итоге с каждым днем кол-во шардов увеличивается вместе с утилизацие памяти и процессора.

Первое что стоит сделать это изменить глобальные настройки elasticsearch так, чтобы кол-во шардов было оптимальное. Если не планируется кластер, то и создавать большое кол-во шардов не имеет смысла. За эту настройку отвечает директива index.number_of_shards. Добавив ее в конфиг можно установить кол-во создаваемых шардов для всех новых индексов. Как мне кажется, при использовании только одного сервера elasticsearch, логично установить этот параметр равным 1.

Replics

Реплики - еще один инструмент кластера elasticsearch, который взаимодействует с шардами. Кол-во реплик указывают сколько “копий” шардов должно храниться на других нодах кластера, что в случае использования одной ноды не актуально. За эту настройку отвечает директива index.number_of_replicas. Если сервер один, то и реплицировать некуда, устанавить этот параметр в 0 - логичное решение.

Однако что делать, если сервер уже работает какое-то время с дефолтными настройками? Можно заметить, что API elasticsearch возвращает следующее:

$ curl -XGET http://localhost:9200/_cat/shards
logstash-2016.05.09 1 p STARTED    1520055  985.3mb 127.0.0.1 logstash1
logstash-2016.05.09 1 r UNASSIGNED
logstash-2016.05.09 3 p STARTED    1520640  985.9mb 127.0.0.1 logstash1
logstash-2016.05.09 3 r UNASSIGNED
logstash-2016.05.09 4 p STARTED    1520955  981.4mb 127.0.0.1 logstash1
logstash-2016.05.09 4 r UNASSIGNED
logstash-2016.05.09 2 p STARTED    1520377    966mb 127.0.0.1 logstash1

где UNASSIGNED - это шарды-реплики, которые ожидают репликации.

Исправить это можно следующим обращением к api:

curl -XPUT "localhost:9200/logstash-2016.05.09/_settings" -d '{
    "index" : {
        "number_of_replicas" : 0
    }
}'

если количество индексов с шардами, ожидающими репликации большое, то можно воспользоваться следующим однострочником:

$ for ind in `curl -XGET http://localhost:9200/_cat/shards | grep UNASSIGNED | awk '{print $1}' | uniq`; do curl -XPUT "localhost:9200/$ind/_settings" -d '{ "index" : { "number_of_replicas" : 0 } }'; done

Grafana/nginx auth proxy httpaswd

Thu, 17 Mar 2016 17:25:00 +0000

Краткое описание настройки Grafana (> 2.0) и nginx с использованием auth basic авторизации через файлы htpasswd.

Необходимые настройки конфига Grafana:

[server]
protocol = http
http_port = 3000
domain = localhost
http_addr = 127.0.0.1
...
[auth.basic]
enabled=false
[users]
allow_sign_up = false
auto_assign_org = true
auto_assign_org_role = Editor
[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
auto_sign_up = true

Настройка nginx:

server {
  listen                <server_ip>:80;

  server_name           <server_hostname>;
  access_log            /var/log/nginx/grafana.access.log;

  location / {
    auth_basic            'Restricted';
    auth_basic_user_file  <path/to/htpasswd_file>;
    proxy_set_header X-WEBAUTH-USER $remote_user;
    proxy_pass http://grafana;
  }
}

После сделать рестарт сервера Grafana и nginx.

Пробрасывание X сессии от пользователя к root

Wed, 09 Sep 2015 15:24:00 +0000

Сталкнулся с необходимостью запуска графической утилиты на удаленном сервере под пользователем root, но доступ для root по ssh закрыт.

В итоге нашел такой workaround:

Заходим на сервер под пользователем прокинув X сессию через ssh:

~$ ssh -X user@hostname

Находим X сессию, потом свитчемся в root:

~$ xauth list
hostname/unix:10  MIT-MAGIC-COOKIE-1  f714ef310193878cae851635b871d840
~$ sudo -s

Добавляем имеющуюся сессию пользователю root

~# xauth add hostname/unix:10  MIT-MAGIC-COOKIE-1 f714ef310193878cae851635b871d840

Все! Можно запускать X приложение под root-ом.

Мониторинг dmesg

Wed, 02 Jul 2014 09:58:00 +0000

Задача

Необходимо организовать централизованный сбор логов, в частности сообщений ядра dmesg и реакции на них со стороны событийного мониторинга (например nagios).

Передача сообщений ядра на сервер логов

Для передачи сообщения ядра можно использовать модуль netconsole. Он позволяет передавать сообщения журнала ядра (dmesg) на удаленный компьютер по сети, без участия пространства пользователя (например, syslogd). Для сбора данных можно использовать, например logstash.

Netconsole может быть встроен в ядро, так и загружен как модуль. Я использую загрузка модуля после загрузки системы, чтобы гарантировать, что сеть уже работает настроена.

# dmesg -n 7
# modprobe netconsole netconsole="6665@10.13.77.99/eth1,6666@10.13.77.1/d4:ae:52:cf:33:96"

Первая команда устанавливает уровень логирования для dmesg. Вторая загружает модуль netconsole с параметрами, где:

6665 - порт отправки сообщений
10.13.77.99 - ip адрес хоста, с которого отправляются сообщения (текущий сервер)
eth1 - интерфейс с которого отправляются сообщения
6666 - порт, на который принимаются сообщения
10.13.77.1 - ip адрес хоста, на который принимаются сообщения
MAC - mac адрес интерфейса, на который принимаются сообщения

Установка logstash не является темой этой статьи, поэтому я буду показывать лишь части конфига необходимые для реализации задачи. Для получения сообщений от netconsole надо указать следующий кусок конфига в блоке input:

input {
    udp {
        type => "netconsole"
        port => "6666"
        host => "10.13.77.1" }
    }

где host - это ip адрес интерфейса на который будут присылаться сообщения ядра.

Теперь все сообщения ядра отправляются в logstash.

Оповещения при критических сообщениях ядра

В моём случае я хочу отслеживать наличие OOM сообщений и рассылать оповещения об этом. Logstash может отправлять письма с оповещениями сам, но мне интересно делать это событийным мониторингом.

В качестве событийного мониторинга я использую shinken. Для реализации оповещения админов, по моему, лучше использовать сервисные чеки is_volatile. Эта опция позволяет отправлять оповещения на каждый статус non-OK даже если он не менялся. Подробнее об этой опции можно почитать на странице документации https://shinken.readthedocs.io.

Чтобы не повторяться в описании каждого сервиса напишем template для volatile сервисов:

define service {
  name                          volatile-service
  check_command                 dummy_ok
  max_check_attempts            1
  check_interval                5
  retry_interval                2
  active_checks_enabled         0
  passive_checks_enabled        1
  check_period                  24x7
  check_freshness               1
  freshness_threshold           300
  flap_detection_enabled        0
  notification_interval         60
  notification_period           24x7
  notification_options          u,c,w
  notifications_enabled         1
  contact_groups                sysadmin
  register                      0
}

В данном описании мы определяем пассивные сервисы, которые будут автоматически сбрасываться в статус ОК через 5 минут после изменения статуса. Так же важно в опции max_check_attempts указать 1, чтобы сервис сразу после первого сообщения переходил в hard-state.

Теперь можно описать сам сервис используя вышеописанный template:

define service {
  hostgroup_name                linux
  service_description           log_event
  servicegroups                 logs
  initial_state                 o
  register                      1
  use                           volatile-service
}

С настройкой событийного мониторинга закончили. Переходим к настройке logstash.

Т.к. все сообщения ядра приходят от IP адреса сервера, который его сгенерил, то первое что я рекомендую сделать это настроить для серверов обратную зону, что позволит упростить и дальнейшую работу с логами и передачу сообщений в shinken. Если обратная зона есть, то можно добавить в блок filter следующий кусок конфига:

filter {
    ...
    dns {
            'action' => "replace"
            'reverse' => ["host"]
            'type' => "netconsole"
        }
    ...
}

Теперь в поле host вместо IP адреса сервера будет подставляться последний уровень домена хоста (т.е. если полный домен myserver.my.domain.example.com, то в поле попадёт только myserver). Это упростит жизнь в будущем.

Далее добавим фильтрацию сообщений, на появления которых хотим получать оповещения. Для примера возьмём строку сообщающую о приходи oom киллера и будем тагать записи такого типа:

    filter {
        ...
        if [message] =~ /.+Out.of.memory.+Kill.process.+/ {
           noop {
                  'add_tag' => ["notify"]
              }
        }
        ...
    }

Осталось научить logstash отправлять сообщения с тэгом notify. Для отправки на сервер Nagios можно использовать уже готовые плагины logstash nagios или nagios_nsca. Я использую shinken и хоть он и совместим с Nagios в большинстве случаев, в этом я предпочёл использовать API shinken. Для отправки сообщений я написал простенький скрипт на bash:

log_event_sender.sh

#!/bin/bash
# WS_Arbiter config
USER=username;
PASS=password;
WS_IP=192.168.0.55;
WS_PORT=7760;

HOST_NAME=$1;
SERVICE=`echo $2 | sed -r -e 's/[[:space:]]/%20/g'`;
RCODE=2;
MESSAGE=`echo $3 | sed -r -e 's/[[:space:]]/%20/g'`;

DATA="time_stamp=$(date +%s)&host_name=$HOST_NAME&service_description=$SERVICE&return_code=$RCODE&output=$MESSAGE";
SEND=$(curl -s -u ${USER}:${PASS} -d $DATA http://${WS_IP}:${WS_PORT}/push_check_result)

Добавляем отправку сообщений с тэгом notify в конфиг logstash:

output {
    exec {
       'tags' => ["notify"]
       'command' => "/usr/local/log_event_sender.sh %{host} log_event '%{message}'"
  }
}

Дальнейшее расширение очевидно. Если нужно добавить оповещение о сообщениях другого типа, то нужно просто отлавливать их в logstash и навешивать тэг notify.

Erchef no_connect Error

Wed, 28 May 2014 09:42:00 +0000

Предпосылки

Столкнулся с тем, что при большом количестве нод в chef-server версий 11.0.4 и 11.0.8 поставленных из omnibus пакетов для Ubuntu, он с большой периодичностью стал отдавать 500 Internal server error нодам при выполнении куска рецепта, который делает поиск по data_bag’ам. При изучении логов выяснилось следующее: В логах nginx’a видно, что запросы на поиск отправляются на бэкэнд erchef’а (ядро chef-server написанное на эрланге) и в ответ получаем 500:

192.168.1.111 - - [27/May/2014:11:45:28 +0000] "GET /search/databag1?q=id:node1&sort=X_CHEF_id_CHEF_X%20asc&start=0&rows=1000 HTTP/1.1" 500 "0.051" 36 "-" "Chef Client/11.6.0 (ruby-1.9.3-p429; ohai-6.18.0; x86_64-linux; +http://opscode.com)" "127.0.0.1:8000" "500" "0.046" "11.6.0" "algorithm=sha1;version=1.0;" "auth1" "2014-05-27T11:45:28Z" "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" 1011

Смотрим далее в логи erchef:

=ERROR REPORT==== 27-May-2014::11:45:28 ===
webmachine error: path="/search/databag1"
{error,
    {error,function_clause,
        [{chef_wm_search,'-make_bulk_get_fun/5-lc$^1/1-2-',
             [{error,no_connections},
             <<"databag1">>],
             [{file,"src/chef_wm_search.erl"},{line,233}]},
         {chef_wm_search,fetch_result_rows,4,
             [{file,"src/chef_wm_search.erl"},{line,351}]},
         {chef_wm_search,make_search_results,5,
             [{file,"src/chef_wm_search.erl"},{line,324}]},
         {chef_wm_search,to_json,2,
             [{file,"src/chef_wm_search.erl"},{line,130}]},
         {webmachine_resource,resource_call,3,
             [{file,"src/webmachine_resource.erl"},{line,166}]},
         {webmachine_resource,do,3,
             [{file,"src/webmachine_resource.erl"},{line,125}]},
         {webmachine_decision_core,resource_call,1,
             [{file,"src/webmachine_decision_core.erl"},{line,48}]},
         {webmachine_decision_core,decision,1,
             [{file,"src/webmachine_decision_core.erl"},{line,532}]}]}}

К сожалению то, что erchef пишет в свой лог не информативно. Однако путём длительного перебора удалось понять, что проблема в соединении к базе.

Решение

Суть проблемы в том, что erchef открывает N соединений к базе postgresql (по умолчанию 20) и вываливается с выше указанной ошибкой, если этих 20-и соединений ему не хватает. Чтобы увеличить количество соединений нужно поправить конфиг erchef’a.

/var/opt/chef-server/erchef/etc/app.config

...
{pooler, [
           {pools, [[{name, "sqerl"},
                     {max_count, 60},
                     {init_count, 40},
                     {start_mfa, {sqerl_client, start_link, []}}]]},
           {metrics_module, folsom_metrics}
          ]},
...

Правим значения для max_count и init_count с 20 на большие. В моём случае пока хватает 60 и 40.