Logstash metric filter for log-level -

can please me metric filter. want set logstash check log-level= error every 5s , if log-level = error exceeds more 1 , should send email. using logstash 2.2.4

input {       file {         path => "/var/log/logstash/example"         start_position => beginning       }     }  filter {  grok{    match => { "message" => "\[%{timestamp_iso8601:timestamp}\]\[%{loglevel:log-level}\s*\]" }  }  if [log-level] == "error" {    metrics {        meter => [ "log-level" ]        flush_interval => 5        clear_interval => 5       }    } } output { if [log-level] == "error" {   if [log-level][count] < 1 {     email {         port => 25         address => "mail.abc.com"         authentication => "login"         use_tls => true         => "alerts@logstash.com"         subject => "logstash alert"         => "siya@abc.com"         via => "smtp"         body => "here event line %{message}"         debug => true       }     }   } } 

editorial:

i not fan of metrics {} filter, because breaks assumptions. logstash multi-threaded, , metrics 1 of filters keeps state within thread. if use it, need aware if you're running 4 pipeline workers, have 4 independent threads keeping own state. breaks assumption events coming "into logstash" counted "by metrics filter".

for use-case, i'd recommend not using logstash issue email, , instead rely on external polling mechanism hits backing stores.

---

because metrics filter, highly recommend set number of filter-workers 1. -w command-line option when logstash starts. you'll lose parallelism, you'll gain ability single filter see all events. if don't, can cases all, say, 6 threads each see error event; , 6 emails.

your config use updates. it's recommended add tag or metrics {} filter.

 metrics {      meter => [ "log-level" ]      flush_interval => 5      clear_interval => 5      add_tag => "error_metric"     }  } 

this way, can better filter email segment.

output {   if [tags] include "error_metric" , [log-level][count] > 1 {     email {     }   } } 

this because metrics {} filter creates new event when flushes, rather amending existing one. need catch new event filters.