输出到 Redis
配置示例
input { stdin {} } output { redis { data_type => "channel" key => "logstash-chan-%{+yyyy.MM.dd}" } }
Usage
我们还是继续先用 redis-cli 命令行来演示 outputs/redis 插件的实质。
basical use case
运行 logstash 进程，然后另一个终端启动 redis-cli 命令。输入订阅指定频道的 Redis 命令 ("SUBSCRIBE logstash-chan-2014.08.08") 后，首先会看到一个订阅成功的返回信息。如下所示：
# redis-cli 127.0.0.1:6379> SUBSCRIBE logstash-chan-2014.08.08 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "logstash-chan-2014.08.08" 3) (integer) 1
好，在运行 logstash 的终端里输入 "hello world" 字符串。切换回 redis-cli 的终端，你发现已经自动输出了一条信息：
1) "message" 2) "logstash-chan-2014.08.08" 3) "{\"message\":\"hello world\",\"@version\":\"1\",\"@timestamp\":\"2014-08-08T16:34:21.865Z\",\"host\":\"raochenlindeMacBook-Air.local\"}"
看起来是不是非常眼熟？这一串字符其实就是我们在 inputs/redis 一节中使用的那段数据。
看，这样就把 outputs/redis 和 inputs/redis 串联起来了吧！
事实上，这就是我们使用 redis 服务器作为 logstassh 架构中 broker 角色的原理。
让我们把这两节中不同配置的 logstash 进程分别在两个终端运行起来，这次不再要运行 redis-cli 命令了。在配有 outputs/redis 这端输入 "hello world"，配有 "inputs/redis" 的终端上，就自动输出数据了！
notification use case
我们还可以用其他程序来订阅 redis 频道，程序里就可以随意写其他逻辑了。你可以看看 output/juggernaut插件的原理。这个 Juggernaut 就是基于 redis 服务器和 socket.io 框架构建的。利用它，logstash 可以直接向 webkit 等支持 socket.io 的浏览器推送告警信息。
扩展方式
和 LogStash::Inputs::Redis 一样，这里也有设置成 list 的方式。使用 RPUSH 命令发送给 redis 服务器，效果和之前展示的完全一致。包括可以调整的参数 batch_event，也在之前章节中讲过。这里不再重复举例。
输出到 Statsd
Statsd 最早是 2008 年 Flickr 公司用 Perl 写的针对 graphite、datadog 等监控数据后端存储开发的前端网络应用，2011 年 Etsy 公司用 nodejs 重构。用于接收、写入、读取和聚合时间序列数据，包括即时值和累积值等。
配置示例
output { statsd { host => "statsdserver.domain.com" namespace => "logstash" sender => "%{host}" increment => ["httpd.response.%{status}"] } }
解释
Graphite 以树状结构存储监控数据，所以 statsd 也是如此。所以发送给 statsd 的数据的 key 也一定得是 "first.second.tree.four" 这样的形式。而在 outputs/statsd 插件中，就会以三个配置参数来拼接成这种形式：
namespace.sender.metric
其中 namespace 和 sender 都是直接设置的，而 metric 又分为好几个不同的参数可以分别设置。statsd 支持的 metric 类型如下：
metric 类型
- increment
示例语法：increment => ["nginx.status.%{status}"]
- decrement
语法同 increment。
- count
示例语法：count => {"nginx.bytes" => "%{bytes}"}
- gauge
语法同 count。
- set
语法同 count。
- timing
语法同 count。
关于这些 metric 类型的详细说明，请阅读 statsd 文档：github.com/etsy/statsd…。
推荐阅读
- Etsy 发布 nodejs 版本 statsd 的博客：Measure Anything, Measure Everything
- Flickr 发布 statsd 的博客：Counting & Timing
报警到 Nagios
Logstash 中有两个 output 插件是 nagios 有关的。outputs/nagios 插件发送数据给本机的 nagios.cmd 管道命令文件，outputs/nagios_nsca 插件则是 调用 send_nsca 命令以 NSCA 协议格式把数据发送给 nagios 服务器(远端或者本地皆可)。
Nagios.Cmd
nagios.cmd 是 nagios 服务器的核心组件。nagios 事件处理和内外交互都是通过这个管道文件来完成的。
使用 CMD 方式，需要自己保证发送的 Logstash 事件符合 nagios 事件的格式。即必须在 filter 阶段预先准备好 nagios_host 和 nagios_service 字段；此外，如果在 filter 阶段也准备好 nagios_annotation 和 nagios_level 字段，这里也会自动转换成 nagios 事件信息。
filter { if [message] =~ /err/ { mutate { add_tag => "nagios" rename => ["host", "nagios_host"] replace => ["nagios_service", "logstash_check_%{type}"] } } } output { if "nagios" in [tags] { nagios { } } }
如果不打算在 filter 阶段提供 nagios_level ，那么也可以在该插件中通过参数配置。
所谓 nagios_level，即我们通过 nagios plugin 检查数据时的返回值。其取值范围和含义如下：
- "0"，代表 "OK"，服务正常；
- "1"，代表 "WARNNING"，服务警告，一般 nagios plugin 命令中使用
-w参数设置该阈值； - "2"，代表 "CRITICAL"，服务危急，一般 nagios plugin 命令中使用
-c参数设置该阈值； - "3"，代表 "UNKNOWN"，未知状态，一般会在 timeout 等情况下出现。
默认情况下，该插件会以 "CRITICAL" 等级发送报警给 Nagios 服务器。
nagios.cmd 文件的具体位置，可以使用 command_file 参数设置。默认位置是 "/var/lib/nagios3/rw/nagios.cmd"。
关于和 nagios.cmd 交互的具体协议说明，有兴趣的读者请阅读 Using external commands in Nagios 一文，这是《Learning Nagios 3.0》书中内容节选。
NSCA
NSCA 是一种标准的 nagios 分布式扩展协议。分布在各机器上的 send_nsca 进程主动将监控数据推送给远端 nagios 服务器的 NSCA 进程。
当 Logstash 跟 nagios 服务器没有在同一个主机上运行的时候，就只能通过 NSCA 方式来发送报警了 —— 当然也必须在 Logstash 服务器上安装 send_nsca 命令。
nagios 事件所需要的几个属性在上一段中已经有过描述。不过在使用这个插件的时候，不要求提前准备好，而是可以在该插件内部定义参数：
output { nagios_nsca { nagios_host => "%{host}" nagios_service => "logstash_check_%{type}" nagios_status => "2" message_format => "%{@timestamp}: %{message}" host => "nagiosserver.domain.com" } }
这里请注意，host 和 nagios_host 两个参数，分别是用来设置 nagios 服务器的地址，和报警信息中有问题的服务器地址。
关于 NSCA 原理，架构和配置说明，还不了解的读者请阅读官方网站 Using NSClient++ from nagios with NSCA 一节。
推荐阅读
除了 nagios 以外，logstash 同样可以发送信息给其他常见监控系统。方式和 nagios 大同小异：
- outputs/ganglia 插件通过 UDP 协议，发送 gmetric 型数据给本机/远端的
gmond或者gmetad - outputs/zabbix 插件调用本机的
zabbix_sender命令发送
发送邮件(Email)
配置示例
output { email { to => "admin@website.com,root@website.com" cc => "other@website.com" via => "smtp" subject => "Warning: %{title}" options => { smtpIporHost => "localhost", port => 25, domain => 'localhost.localdomain', userName => nil, password => nil, authenticationType => nil, # (plain, login and cram_md5) starttls => true } htmlbody => "" body => "" attachments => ["/path/to/filename"] } }
解释
outputs/email 插件支持 SMTP 协议和 sendmail 两种方式，通过 via 参数设置。SMTP 方式有较多的 options 参数可配置。sendmail 只能利用本机上的 sendmail 服务来完成 —— 文档上描述了 Mail 库支持的 sendmail 配置参数，但实际代码中没有相关处理，不要被迷惑了。。。
调用命令执行(Exec)
outputs/exec 插件的运用也非常简单，如下所示，将 logstash 切割成的内容作为参数传递给命令。这样，在每个事件到达该插件的时候，都会触发这个命令的执行。
output { exec { command => "sendsms.pl \"%{message}\" -t %{user}" } }
需要注意的是。这种方式是每次都重新开始执行一次命令并退出。本身是比较慢速的处理方式(程序加载，网络建联等都有一定的时间消耗)。最好只用于少量的信息处理场景，比如不适用 nagios 的其他报警方式。示例就是通过短信发送消息。
