Введение в Riemann: мониторинг и анализ событий

[Arrest]

Эй, а ничего, что в riemann.influxdb уже лежит клиент для InfluxDB? Зачем его второй раз писать?

[Scratch]

Используем риман около года в связке с ELK. Отличная вещь, но добавлять в него правила — сущий гемор. Сейчас думаем над фасадом в виде внешнего легкочитаемого файлика, который позволял бы гибко настраивать алерты. Так же, не хватает отказоустойчивого кластера. Упал риман\рестартанулся и всё, все метрики/ttl слетели.

[acmnu]

Кто-нибудь может подсказать что можно ли подобный софт использовать для мониторинга предопределённых событий? Ну например, каждую ночь идет бэкап определённого хоста. При этом, сутуация, когда он закончился фейлом ловится любой системой мониторинга хорошо, а вот ситуация, когда он вообще в тихую не начался, требует сопоставления с эталонным расписанием. И вот этот случай я как-то не знаю чем можно покрыть. Читаешь о всех этих модных средствах и аж глаза разбегаются.

[Scratch]

В римане есть таймаут у событий. Т.е. если что-то не произошло в заданный промежуток времени, то он может сгенерировать алерт.
Я так сделал довольно оригинальную фичу — оповещение о падении и поднятии одного глючного клиентского FTP сервера. Если сервер падает, то мы отсылаем клиенту сообщение «Подними сервак» и ждем, пока логи о падении сервака перестанут приходить. Как перестают — отсылаем сообщение, мол сервак поднялся.

http://riemann.io/howto.html#detect-down-services

[acmnu]

Немного не то. TTL это вещь понятная: наступило событие, если через n секунд не наступило ещё раз, значит дело труба. Во многих системах мониторинга это называется heart beat — отслеживаение периодических событий. В случае бэкапа дело сложнее. Во-первых, расписание не имеет четкого периода. Логика расписания намного сложнее и завязана на бизнес нагрузку (днем легкие инкременталы, ночью полный бэкап, но не в каждую ночь). Во-вторых, нужно анализировать не только время запуска, но и длительность, которая тоже разная в разные периоды месяца, и нужно уметь отследить аномалии в длительности или объеме бэкапа.

[Scratch]

Есть метрики, их тоже можно использовать для алерта. Можно ttl передавать прям в сообщении, у нас так делается. Это если вы заранее знаете что должно произойти, а что нет. Например — запланировали бекап на 11:00, отправили сообщение риману, которое протухает в 11:10. Если бекап сделаться не успел, то алерт по протуханию. Сам он вычислять аномалии, конечно, не будет. А сложную логику на clojure писать я никому не пожелаю

[NikolaySivko]

Проще всего брать размер целевого файла бэкапа, если файла нет — размер 0. Алерт, если размер бэкапа за сегодня меньше N байт. Проверка корректности — отдельная задача.

[porutchik]

В новых версиях выпилили capacitor. Конфиг теперь примерно такой:

(def influxdb-creds {
     :version :0.9
     :host "localhost"
     :port 8086
     :db "riemann"
     :username "riemann"
     :password "riemann"
})

(def influxBatchSender
  (batch 100 1/10
         (async-queue! :agg {:queue-size 1000
                             :core-pool-size 1
                             :max-pool-size 4
                             :keep-alive-time 60000}
                       (influxdb influxdb-creds))))

;; Riemann log file location
(logging/init {:file "/var/log/riemann/riemann.log"})

;; listen on the local interface over TCP (5555), UDP (5555) and websockets (5556)
(let [host "0.0.0.0"]
  (tcp-server {:host host})
  (udp-server {:host host})
  (ws-server  {:host host}))

;; Expire states from its core's index every 60 seconds. Default is 10.
(periodically-expire 60)

(let [index (index)]
  (streams
   (default :ttl 60
     index
     #(info %)
     influxBatchSender)))