· 更多精彩内容,请下载阅读全本《Elastic Stack实战手册》
创作人:高冬冬
审稿人:刘帅
Monitoring
Monitoring 就是跟踪和监控 Elastic Stack 各个组件的实时运行状况和性能指标;当监控一个集群时,不仅要采集 Elasticsearch 节点的指标,而且要采集集群相关的 Logstash 节点,Kibana 实例以及各种 Beats 节点的性能指标甚至还要通过 Filebeat 采集集群日志,存储在 Elasticsearch 集群中,以便可以通过 Kibana 可视化,实时监控各种组件和节点的实时运行状态。
两种监控方案
- 组件自身监控
- Metricbeat 监控
组件自身监控
开启快捷简单,无需额外组件,收集采集指标会占用组件自身资源;
默认情况下,每一个 Elastic Stack 组件自身都包含一个内置的 agent 负责采集数据
配置方式
Elasticsearch
在 Elasticsearch 集群中监控采集配置默认关闭的 xpack.monitoring.collection.enabled : false
- 通过 Kibana 开启
- 打开 Kibana
- 进入 Management-->Stack Monitoring
- 点击 Turn on monitoring
- 通过 API 开启
GET _cluster/settings
PUT _cluster/settings
{
"persistent": {
"xpack.monitoring.collection.enabled": true
}
}
- Elasticsearch 的其他配置
在节点的配置文件 elasticsearch.yml 更多配置
xpack.monitoring.collection.indices | 指定要监控的索引名,默认是监控所有的,指定 | The indices to collect data from. Defaults to all indices, but can be a comma-separated list. |
---|---|---|
xpack.monitoring.collection.interval | 数据采集频率,默认是 10s | How often data samples are collected.Defaults to 10s |
xpack.monitoring.exporters | 指标数据的存储位置 ,默认存储在自身集群,可以通过此配置指定远端集群。 | Configures where the agent stores monitoringdata. By default, the agent uses a localexporter that indexes monitoring data on thecluster where it is installed. |
参考文献:https://www.elastic.co/guide/en/elasticsearch/reference/7.10/monitoring-settings.html
Kibana
在配置文件 kibana.yml 开启
#是否开启Kibana NodeJS server指标采集
monitoring.kibana.collection.enabled: true
#采集频率(ms),默认10s
monitoring.kibana.collection.interval: 10000
#指定监控指标存储远程ES集群
monitoring.ui.elasticsearch.hosts: ["https://es1:9200", "https://es2:9200"]
#远程ES集群的账号和密码
monitoring.ui.elasticsearch.username: elasticsearch
monitoring.ui.elasticsearch.password: changeme
#控制monitoring后端的运行和kibana运行状态的监控
monitoring.enabled: true
#在kibana中隐藏Stack Monitoring功能。
monitoring.ui.enabled: true
参考文档:https://www.elastic.co/guide/en/kibana/7.10/monitoring-settings-kb.html#monitoring-general-settings
Logstash
在配置文件 logstash.yml 开启
# X-Pack Monitoring
# https://www.elastic.co/guide/en/logstash/current/monitoring-logstash.html
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.hosts: ["https://es1:9200", "https://es2:9200"]
xpack.monitoring.elasticsearch.username: elasticsearch
xpack.monitoring.elasticsearch.password: password
Beats:Filebeat、Metricbeat
在配置文件 filebeat.yml 或 metricbeat.yml 中开启
monitoring.enabled: true
#monitoring.cluster_uuid:
monitoring.elasticsearch.hosts: ["https://es1:9200"]
monitoring.elasticsearch.username: filebeat_system
monitoring.elasticsearch.password: password
APM
在配置文件 apm-server.yml 中开启
monitoring.enabled: true
monitoring.elasticsearch.hosts: ["https://es1:9200"]
monitoring.elasticsearch.username: filebeat_system
monitoring.elasticsearch.password: password
从某种程度上讲 AMP Server 其实就是另外一种 Beat。对于它的监控和 Beats 完全是一样的。
Metricbeat 监控
使用 Metricbeat 采集 Elastic Stack 监控指标,需单独部署监控 Metricbeat 及单独的监控集群。开启对应的 metricbeat modules,避免由于采集数据对组件自身带来压力,而影响组件运行性能。
监控方案
可用来监控 Elastic Stack 的所有类型组件
- 未来版本中默认的监控方案
- 采集性能比内置采集更好
配置方式
注意在 6.5 版本以及以后,才可以通过 Metricbeat 采集 Elasticsearch 监控指标,并可指定专用的监控集群。
- 开启监控数据采集
在生产集群中 xpack.monitoring.collection.enabled 默认为 false,可以通过以下 API 进行开启和关闭。针对 Metricbeat 监控,这个设置应为 false。
GET _cluster/settings
PUT _cluster/settings
{
"persistent": {
"xpack.monitoring.collection.enabled": false
}
"transient" : { }
}
- 在生产集群的每个 node 上安装 Metricbeat, 保证每个 node 都安装
- 在每个 Elasticsearch node 的 Metricbeat 上开启 Elasticsearch X-Pack module
metricbeat modules enable elasticsearch-xpack
- 在每个 Elasticsearch node 上配置 Elasticsearch X-Pack module
- module: elasticsearch
xpack.enabled: true
period: 10s
hosts: ["http://localhost:9200"]
- 指定监控数据存储的集群
在 Metricbeat 的配置文件(metricbeat.yml)中配置 Elasticsearch output 信息。
output.elasticsearch:
hosts: ["http://es-mon-1:9200", "http://es-mon-2:9200"]
#protocol: "https"
#username: "elastic"
#password: "changeme"
- 在每个 Elasticsearch node 节点启动 Metricbeat
nohup ./metricbeat -c metricbeat.yml >/dev/null 2>&1 &
- 关闭默认的 Elasticsearch 监控数据采集
在生产集群中配置 xpack.monitoring.elasticsearch.collection.enabled 为 false
通过以下 API 进行配置
PUT _cluster/settings
{
"persistent": {
"xpack.monitoring.elasticsearch.collection.enabled": false
}
}
- 在监控集群的 Kibana 中查看监控页面
参考文档:https://www.elastic.co/guide/en/elasticsearch/reference/7.10/monitoring-overview.html
专用的监控集群
在生产环境推荐部署专用的监控集群来实现集群的指责分离
- 减少被监控的业务集群的负载和存储压力。
- 防止被监控集群的故障影响监控功能。
- 实现职责隔离,比如监控集群和业务集群可配置不同的安全策略,保障级别等。
统一监控UI
Monitoring 概览
概览页面展示了所有正在被监控的 Elastic Stack 组件,包括但不限于 Elasticseach,Kibana,Beats,Logstash,APM 等等。
Elasticsearch监控
概览页面主要展示了四块内容:
- 集群状态
包括集群状态,节点总数,索引总数,JVM 使用状态,分片总数,未分配的分片数,索引文档总数,存储的数据总大小。
- 集群吞吐量
查询 TPS,查询耗时,索引 TPS 以及索引耗时等时序图。
- 集群日志列表。
- 活动分片迁移列表。
采集的 Elasticsearch 的监控数据包括:Cluster Stats,Index Stats, Index Recovery, Shards,Jobs, Node Stats 等等。
节点监控
主要包含节点列表,同时可以实时查看节点的告警数,在线状态,分片数, 使用率,节点负载,JVM 使用情况以及当前节点空余的存储空间。
点击节点名可以下钻到更详细全面的节点监控以及时序图。
索引监控
主要包含索引列表,可以实时查看到当前索引的状态,文档数,索引大小,索引 TPS,搜索 TPS 以及未分配的分片数。
点击索引名可下钻到更详细全面的索引监控以及时序图。
Kibana 监控
在此页面中可以监控到访问 Kibana 的 client request 次数和 client 请求平均耗时的时序图
点击 Instances 还可以监控到所有 Kibana 实例列表以及当前运行状况。
Beats 监控
统计 Beats 的告警数,Beats 总数,Metricbeat 数,总共生产的事件数和发送的事件字节数,
最近一天活跃的 Beats,Beats 类型的 Top5 以及 Beats 版本的 Top5
成功事件数/秒,失败事件数/秒,平均的吞吐量 bytes/second,以及输出失败数/秒
Beats 实例监控
在实例下可以看到该集群监控到所有 Beats 列表和其运行状态
点击实例名可下钻到更详细全面的 Beats 实例监控以及时序图。
Central Management
开发工具,包括一些可以方便用户和集群中数据进行交互探索分析的工具
Console终端
使用 Elasticsearch 的 REST API 进行交互,包含发送请求和查看 API 文档
如上图所示,在 console 里面执行类似 CRUL 的命令,点击语句后面的➡️执行,即可在右侧栏中实时查看结果;
- 支持 GET,PUT,POST,DELETE 四种命令;
- 支持包含写入,搜索,集群,节点和索引状态等等 Elasticsearch 相关的所有 API;
- 输入命令行时,支持自动补全;
- 支持自动格式化(Auto indent);
- 支持查看 API 文档(Open documention);
- 支持查看执行命令历史记录(点击History);
- 设置 console 配置
- 关闭 console:
在 Kibana 的配置文件 kibana.yml 配置如下
console.enabled: false
然后重启 Kibana 即可
查询分析器
检查并分析您的搜索查询。
Elasticsearch 具有功能强大的 Profile API,可用于检查和分析您的搜索查询。响应返回一个较大的JSON Blob,可能很难手动对其进行分析。
Search Profiler 工具可以将此 JSON 输出转换为易于浏览的可视化文件,从而使您可以更快地诊断和调试效果不佳的查询。
Query Profile
- *
BooleanQuery
组件和 query 中 bool 相对应。 - 第二个
BooleanQuery
对应于条件查询,该条件在内部转换为一个Boolean 的 should 子句,它有两个子查询,分别与terms query中的 “sue” 和 “sally” 相对应。 - 在
TermQuery
标有 “name:fred” 这是对应于 match: fred 在查询中。
如图你可以看到每一行的 Self time 和 Total time 都是不一样的,Self time 表示查询组件执行所需的时间。Total time 是查询组件及其所有子组件执行所花费的时间。因此,诸如 Boolean queries 之类的查询的总时间通常比 Self time 长。
Aggregation
点击 Aggregation Profile 去查看聚合的性能统计信息,
选择 shard 查看聚合详细信息和时序分布。
Grok调试器
在数据处理管道中使用 grok 模式之前,请先对其进行构建和调试。
您可以在 Kibana Grok 调试器中构建和调试 grok 模式, 然后再在数据处理管道中使用它们。Grok 是一种模式匹配语法,可用于解析任意文本并对其进行结构化。Grok 非常适合解析 syslog,apache 和其他 Web 服务器日志,mysql 日志,以及具备可读性的任何日志格式。
使用实例:
自定义模式:
如果默认的grok模式字典不包含你所需的模式,则可以使用Grok Debugger定义,测试和调试自定义模式。
Painless 实验室
实时实验和调试 Painless 脚本(beta功能)
此处不做过多的介绍。
采集管理
Logstash Pipelines管理
Logstash Pipelines 管理就是集中管理配置 Logstash pipeline,使其事件处理和结果调试可视化。
准备步骤如下:
- 安装对应版本的 Logstash(和 Elasticsearch 版本保持一致)
- 开启 Logstash 监控和集中管理
- 创建 Logstash Pipeline
- 验证 Pipelines 集中管理
安装 Logstash
#下载安装包
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.10.0-linux-x86_64.tar.gz
#解压到指定目录下
tar -zxvf logstash-7.10.0-linux-x86_64.tar.gz -C /opt/
#启动安装包
cd /opt/logstash-7.10.0
./bin/logstash
第一次启动会启动失败,这个不用担心,因为没有对logstash进行任何配置。
开启监控和集中管理
开启 Logstash 监控的前提,请确保在 Elasticsearch 集群中启动xpack.monitoring.collection.enabled : true
通过 Kibana 启动方式如下:
设置 Logstash 监控
在配置文件 logstash.yml 添加如下配置
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.username: "elastic"
xpack.monitoring.elasticsearch.password: "esTeam123456"
xpack.monitoring.elasticsearch.hosts: ["http://es-cn-6ja24dt4r007brz85.public.elasticsearch.aliyuncs.com:9200"]
xpack.monitoring.collection.interval: 10s
xpack.monitoring.collection.pipeline.details.enabled: true
设置 Logstash 集中管理
创建用于管理 Logstash 的用户和角色
POST _xpack/security/role/logstash_writer
{
"cluster": ["manage_index_templates", "monitor", "manage_ilm"],
"indices": [
{
"names": [ "test1_*", ".monitoring-logstash-*" ],
"privileges": ["write","create","create_index","manage","manage_ilm"]
}
]
}
POST _xpack/security/user/logstash_internal
{
"password" : "123456",
"roles" : [ "logstash_writer", "logstash_admin", "logstash_system"],
"full_name" : "Internal Logstash User"
}
创建一个 logstash_writer 角色,并给其分配相应 cluster 和 indices 的权限
在配置文件 logstash.yml 添加如下配置
xpack.management.enabled: true
xpack.management.pipeline.id: ["Team7_test"]
xpack.management.elasticsearch.username: "logstash_internal"
xpack.management.elasticsearch.password: "123456"
xpack.management.elasticsearch.hosts: ["http://es-cn-6ja24dt4r007brz85.public.elasticsearch.aliyuncs.com:9200"]
xpack.management.logstash.poll_interval: 1s
注意:X-pack.management.pipeline.id 中支持配置多个 pipeline.id,请保证此处填入的和Kibana 创建发布的保持一致。
启动 Logstash
[root@master01 logstash-7.10.0]# ./bin/logstash --debug
Using JAVA_HOME defined java: /opt/jdk1.8.0_251
WARNING, using JAVA_HOME while Logstash distribution comes with a bundled JDK
在 Kibana monitor 查看 Logstash 监控
依次可以查看 Logstash 的概览,Logstash节点和 Logstash pipeline监控。
创建 Logstash Pipeline
在 Kibana 上操作,依次点击 Mangement-> Stack Management ->Logstash Pipelines->Create pipeline,输入配置参数后,点击 Create and Deploy 即可创建和发布成功。
验证 Pipelines 集中管理
首先往 /var/log/test1 文件中写入多条日志
[root@master01 ~]# echo "test1" >> /var/log/test1
[root@master01 ~]# echo "test2" >> /var/log/test1
[root@master01 ~]# echo "test3" >> /var/log/test1
[root@master01 ~]# echo "test4" >> /var/log/test1
在 Elasticsearch 中可查询到刚刚 test1_20210501 写入的 4 条日志
也可以在 Logstash 的监控中,看到在 15:36-15:38 之间采集到数据
使用总结
该功能属于 X-pack 的高级特性,基础版本的 License 不能体验;
使用该功能时无需在 Logstash 节点配置任何 pipeline;
创建和发布的 pipeline 会自动下发至该集群管理的所有 Logstash 实例,不能进行单独管控。
Beats 集中管理
功能概述
在 6.5 的版本中,Elastic 官方在 Kibana 中引入了一个新功能:Beats 的集中管理。主要用来解决
Beats 的集中配置管理,通过此功能,你无需重复的登录每台机器上调整配置,这样可以大大减轻配置管理相关的工作量。
Beats 的集中管理功能很简单,包含 3 个步骤:
- 注册 Beats:
注册 Beats 就是通过 Beats enroll 命令将 Beats 注册集群中,目前只支持两种 beats(filebeats和metricbeat),注册成功以后才能被管控。
- 配置标签
使用一种使用配置标签的机制来对相关配置进行分组,详细的相关配置在配置标签中进行添加
目前支持 4 种类型。Filebeat input,Filebeat module, Metricbeat module 和 output。
最后在 Beats 列表中绑定配置标签,即可自动批量下发配置标签中的相关配置,如下图所示。
验证方案
安装 Metricbeat
wget https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.10.0-linux-x86_64.tar.gz
tar -zxvf metricbeat-7.10.0-linux-x86_64.tar.gz
cd /opt/metricbeat-7.10.0-linux-x86_64
创建 Enroll Beats
在 Kibana 上操作,依次点击 Mangement-> Stack Management ->Beats Central Management->Enroll Beats
选择 Beat type=Metricbeat 和 Platform=DEB/RPM
即可得到 Metricbeat Enroll 命令
在 Metricbeat 安装节点执行:
[root@master01 metricbeat-7.10.0-linux-x86_64]# ./metricbeat enroll https://es-cn-6ja24dt4r007brz85.kibana.elasticsearch.aliyuncs.com:5601 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjcmVhdGVkIjoiMjAyMS0wNS0wMVQxMDowNzo0OC4xNzZaIiwiZXhwaXJlcyI6IjIwMjEtMDUtMDFUMTA6MTc6NDguMTc2WiIsInJhbmRvbUhhc2giOiJYJO-_ve-_vSczMu-_vSjvv71cdTAwMDfvv73vv70qJVx1MDAxZe-_vWU-XHUwMDAz77-9O13vv73vv73vv70iLCJpYXQiOjE2MTk4NjM2Njh9.p3q-hw8r5I-34ICuVcRHQGqT7c6LoJ6VAZBcyIN-AfA
This will replace your current settings. Do you want to continue? [Y/n]:y
Saving a copy of current settings to metricbeat.yml.2021-05-01T18-12-22.bak
Enrolled and ready to retrieve settings from Kibana
[root@master01 metricbeat-7.10.0-linux-x86_64]#
即可在显示在 Kibana 注册成功
点击 Done 即可
启动 metricbeat
./metricbeat -e -c metricbeat.yml
创建 Configuration tags
创建一个 Team7 的 Configuration tags,并在其中配置了两个 Configuration blocks,
- 输出到 Elasticsearch
- 开启 system 的 metricbeat modules
应用配置到 Beats
验证数据
Metricbeat 索引的文档数持续增加
GET metricbeat-7.10.0-2021.05.01/_count
{
"count" : 405,
"_shards" : {
"total" : 3,
"successful" : 3,
"skipped" : 0,
"failed" : 0
}
}
在 Kibana 的 discover 页面分析 Metricbeat 索引数据
数据管理
索引管理
Kibana 的索引管理菜单中,主要管理着和索引相关的四类数据
索引列表
管理着集群中的所有 indices,包含 Rollup 索引(通过 Rollup 聚合索引)和隐藏索引(名字以.开头的索引)
同时还可以根据是否被 ILM 管理(Managed 和 Unmanaged)和处于 ILM 管理阶段(Hot,warm,Frozen,Cold 和 Delete)进行查询和过滤
点击索引名可以查看索引的详细
在索引详情中,可以查看索引概览信息,settings,mappings,当前索引状态数据以及对该索引的 settings 进行修改。
同时你可以对该索引进行关闭,segment 强制合并,Refresh,清空索引缓存,Flush,冻结,删除和解除 ILM 管理等操作
索引模板管理
在创建索引时,根据索引名匹配符合条件的索引自动设置索引的 settings,mappings 和 aliases
在此处创建索引模板,支持创建两种方式创建索引模板
新版模板创建流程:
设置模板总览信息
选择 templates 组件,包括 settings,mappings,aliases
自定义修改 index settings
自定义 mappings
添加 Aliases 信息
检查设置好的 template 信息
点击创建按钮即可完成模板创建
旧版模板创建流程:
和新版本的创建流程基本相同,少了可选择已有 template 组件这一步。
模板组件管理
使用组件模板可以在多个索引模板中重用设置,映射和别名配置
创建索引组件模板的流程如下:
创建成功的效果:
创建成功后,该索引组件模板,就可以在创建索引模板时进行复用。
索引生命周期
ElasticSearch 在 6.7 版本推出的索引生命周期管理(index lifecycle management,简称ILM),生命周期把索引分为四个阶段,Hot,Warm,Cold,和 Delete。这也是 Elastic 目前官方比较推荐的索引管理方法。
hot | 索引可写入,也可查询,也就是我们通常说的热数据。 |
---|---|
warm | 索引通常不会被写入,但仍然会被查询。 |
cold | 索引不再被更新,并且很少被查询。这些信息仍然需要可搜索,但如果查询速度较慢也没关系。 |
delete | 索引不再需要,可以安全地删除。 |
创建一个 Index Lifecycle policy
在 Kibana 上操作,依次点击 Mangement-> Stack Management -> Index Lifecycle Policies->Create policy,输入配置参数后,点击 Save as new policy 可以生成一个新的策略。
点击 Show request,可得到创建此 Policy 的请求语句
PUT _ilm/policy/team7_policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_docs": 5
},
"set_priority": {
"priority": 100
}
}
},
"delete": {
"min_age": "10m",
"actions": {}
}
}
}
}
在集群中验证创建的策略:
- 配置 lifecycle 检测时间
PUT _cluster/settings
{
"transient": {
"indices.lifecycle.poll_interval": "5s"
}
}
默认为十分钟,为了测试效果,改为 5 秒钟。
- 创建索引模板
PUT _template/team7_template
{
"index_patterns": [
"my_team7*"
],
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1,
"index.lifecycle.name": "team7_policy",
"index.lifecycle.rollover_alias": "my_team7",
"index.default_pipeline": "indexed_at"
}
}
索引以 my_team7-开头的自动采用 settings 的配置。
index.lifecycle.name 表示采用 team7_policy 的策略,
index.lifecycle.rollover_alias 表示创建使用该模版创建的索引
统一用 my_team7 的别名进行管理。
- 创建索引
PUT my_team7-000001
{
"aliases": {
"my_team7": {
"is_write_index": true
}
}
}
创建一个开始的索引,并设置当前索引可通过索引别名写入。
- 验证功能
一切准备就绪,我们开始验证
首先执行下面的新建文档操作5次
POST my_team7/_doc
{
"message": "this is team7 test"
}
之后 Rollover 执行,新的索引创建,如下所示
10m 以后, my_team7-000001 删除至此,一个完整的 ILM Policy 执行的流程就结束了,而后续 my_team7-000002 也会按照这个设定进行流转。
索引快照和恢复
console开发工具
- console终端
- Profiler分析
- Grok调试工具
采集管理
- Logstash管道
- Beats集中管理
数据管理
- 索引管理
- 索引生命周期
- 索引快照和恢复
创作人简介:
高冬冬,从事运维架构, 参与私有云平台运维体系平台开发,金融行业统一日志平台(PB
级)的规划和建设,正在进行包含监控体系和智能运维的统一监控告警平台的规划和设
计。
自 2016 年开始使用和研究 Elastic Stack 相关技术栈,擅长使用 Elastic Stack 解决日
志分析和可观测性相关问题,对 PB 级日志平台的规划,部署,优化和运维有丰富的经
验和实践,喜欢学习运用新技术,解决工作中问题和提高生产力。希望以后有更多的机
会,分享输出更多有价值的东西给大家。