小土刀

【通天塔之日志分析平台】叁 监控、安全、报警与通知

前面我们已经把 ELK 和 Kafka 组合成了一个比较稳定的系统,这次我们来看看,如何通过 X-Pack 插件包来完成日常运维监控的各项任务。


更新历史

  • 2016.11.22: 完成初稿

系列文章

任务目标

  1. 完成 X-Pack 的安装
  2. 了解 Security, Alerting, Monitoring, Reporting 几大组件的功能
  3. 自己编写一个报警规则
  4. 自己生成一个数据报表

X-Pack 简介与安装

在 Elasticsearch 2.4 时代,如果想对其进行监控和管理,除了五花八门的开源解决方案外,还可以使用 elastic 官方的配套插件。但是从前的名字比较乱,从 Shield 到 Watcher 再到 Marvel,还要一个一个安装配置。

不过在 ElasticStack 5.0 时代,所有的功能得到了统一,统称为 X-Pack,包含:

  • 安全:用户权限管理
  • 警报:自动报警
  • 监控:监控 Elasticsearch 集群状态
  • 报告:发送报表、导出数据
  • 图表:可视化数据

这些功能基本上涵盖了日常应用的方方面面,接下来我们就来简单了解一下各项功能。不过开始之前,我们先把 X-Pack 装好。

安装需要先停止 Kibana 和 Elasticsearch,这个时候就体现出 Kafka 的优势了:我们可以对 Elasticsearch 进行修改,因为缓存到了 Kafka
,所以不必担心日志服务停止。

# 为 Elasticsearch 安装 X-Pack
bin/elasticsearch-plugin install x-pack
# 启动 Elasticsearch
bin/elasticsearch
# 为 Kibana 安装 X-Pack
bin/kibana-plugin install x-pack
# 启动 Kibana
bin/kibana

命令完成之后,安装就算完成了。这里需要额外提一点,因为加上了安全认证,所以原先我们的 Logstash 脚本就不能用了,初始的用户名为 user 和密码为 changeme,对应的配置文件需要更新为:

# 文件名:kafka-to-es.conf
input {
kafka {
bootstrap_servers => "localhost:9092"
topics => ["logs"]
}
}
output {
# for debugging
stdout {
codec => rubydebug
}
elasticsearch {
hosts => "localhost:9200"
index => "system-log"
# 用户名和密码如果变更需要更改
user => "elastic"
password => "changeme"
}
}

安全 Security

再次打开之前的 Kibana 页面,就会发现我们需要登录了:

输入一开始预置的用户名与密码(elastic:changeme),就可以进入 Kibana 了。然后我们在 Management 面板中可以看到一个新的 Elasticsearch 的栏目,可以在这里进行用户和角色的定制。

这里我们暂时使用默认的帐号和角色进行操作,更多关于安全方面的问题可以参考下面的链接:

监控 Monitoring

点击左侧的 Monitoring 面板,便可以清楚查阅 Elasticsearch 和 Kibana 的状态。

点击进入 Overview,便可以清晰了解整体的使用状况:

而在 Indices 分页中点击具体的索引,便可以看到索引的详细:

监控功能在遇到问题的时候进行问题查找和确定非常有用,也可以结合报警和报告功能实现自动化通知。

报警 Alerting

Elasticsearch 中报警功能的实现目前还不算特别智能,这里我们只简单了解一下其工作机制,具体在需要的时候可以根据文档来进行设置。

简单来说,我们需要自己设定触发条件,并指定条件触发之后的动作。一个实际的例子就是,如果发现近十分钟内某个接口一直返回 503 错误,那么就发送邮件通知。分解一下,一个可能的逻辑是:

  1. Trigger: 每十分钟执行一次
  2. Input: 对某个 index 进行检索,查询日志中状态为 error 的条目
  3. Condition: 如果 error 的次数超过 5 次,则认为触发了条件
  4. Transform: 触发之后会再次进行检索,检索的结果可以被之后的动作访问
  5. Actions: 执行具体的操作,可以是通知第三方系统或发送邮件等

上面的套路对应到配置文件就是:

PUT _xpack/watcher/watch/log_errors
{
"metadata" : {
"color" : "red"
},
"trigger" : {
"schedule" : {
"interval" : "5m"
}
},
"input" : {
"search" : {
"request" : {
"indices" : "log-events",
"body" : {
"size" : 0,
"query" : { "match" : { "status" : "error" } }
}
}
}
},
"condition" : {
"compare" : { "ctx.payload.hits.total" : { "gt" : 5 }}
},
"transform" : {
"search" : {
"request" : {
"indices" : "log-events",
"body" : {
"query" : { "match" : { "status" : "error" } }
}
}
}
},
"actions" : {
"my_webhook" : {
"webhook" : {
"method" : "POST",
"host" : "mylisteninghost",
"port" : 9200,
"path" : "/{{watch_id}}",
"body" : "Encountered {{ctx.payload.hits.total}} errors"
}
},
"email_administrator" : {
"email" : {
"to" : "sys.admino@host.domain",
"subject" : "Encountered {{ctx.payload.hits.total}} errors",
"body" : "Too many error in the system, see attached data",
"attachments" : {
"attached_data" : {
"data" : {
"format" : "json"
}
}
},
"priority" : "high"
}
}
}
}

以上也可以在 Dev Tools 中的面板中执行试试看。

报告 Reporting

简单来说,这个功能就是一个输出搜索结果和图表的按钮。我们进入 Dashboard 页面,保存当前的图表后,点击右上角的 Reporting 按钮,就会出现一个下载按钮:

点击之后我们会发现并不能够直接下载,因为这个按钮只是给系统发送了一个生成报表的请求,具体的文件我们需要在 Management 面板的 Kibana/Reporting 部分查看:

除了手动生成,我们也可以设置自动生成(使用上面图片中的 Generation URL)并通过给出的 api 来进行下载,具体可以参照 Automating Report Generation

试一试

  1. 阅读 X-Pack Settings 来了解各种设置
  2. 阅读 X-Pack APIs 来了解相关 API,以实现自动化设置
  3. 阅读 Limitaions 来了解 X-Pack 的限制
  4. 自己设定一个报警条件,并在触发之后自动发送邮件给自己

总结

经历了前两节辛苦的环境搭建,本节内容还是比较轻松的,把环境基本搭建完成之后,就可以真刀真枪做一些实际的项目了。下一讲我们会学习从单机到集群的迁移操作和需要注意的地方,为扩展系统做好准备。

捧个钱场?

热评文章