ELK专题：Day8——使用Metricbeat和X-Pack监控ELK集群

发表于 分类于 ， 阅读次数： Waline： 本文字数： 3k 阅读时长 ≈ 3 分钟

1. 前言

我们搭建这一套ELK以来，一直都只是在关注怎么去使用和配置，截止至Day7，我们这一套基于ELK的日志监控和统计方案已经初具雏形，是时候考虑一下监控ELK本身了。

完善的监控有助于让我们实时了解到集群的运行状况，及时发现故障或者是高负载的情况，避免影响业务。同时，在足够多的监控数据的支持下，我们可以提前预知系统负载，提前做好扩容准备；或者是及时发现性能瓶颈或者是不合理的配置项，避免引起更大的问题。

在接下来的内容，我们会通过Metricbeat的简单示例配置，再配合Elastic Stack中的X-Pack实现集群的性能监控。

example

2. 实现原理

2.1 架构图

官方文档里面的架构图看上去很复杂，拆开来说就是几点：

  • 运行Elasticsearch、Logstash、Kibana服务的服务器中都安装一个Metricbeat服务，监控具体服务的性能的同时，也监控操作系统的基础性能（CPU、内存等）
  • 所有Metricbeat都把收集到的监控信息汇总到Monitoring Elasticsearch中（可以和被监控的Elasticsearch是同一个）
  • Metricbeat也可以监控Metricbeat自己（自省 ; -) ）
  • Kibana通过读取Monitoring Elasticsearch的数据，展示监控界面

architecture

2.2 监控原理介绍

Metricbeat服务会定期收集服务器的监控信息，以JSON格式发送到ES，并存放在特定的Index中，每一次性能数据就是一条单独的数据（文档）。ES默认会有一套索引模板metrics，用于管理从Metricbeat收集回来的性能数据。

同时，Metricbeat自带有非常丰富的模块，在模块中已提前定义好了如何接入具体服务、如何采集指标、需要采集什么指标。只需在Metricbeat中完成简单的接入配置，Metricbeat就能自动地根据不同的服务类型自动采集需要的指标数据，如：Mysql、Redis、Apache、Nginx等。

和传统的监控方法（如Zabbix）不一样，Metricbeat在采集数据的时候，采用一次采集多个指标的模式。例如，在采集Redis的性能数据时，Metricbeat接入到redis服务中，再运行一个info命令，就会把所有的数据都一次性收录到ES中。这样的好处是，大大节省了TCP/IP连接数；而且，每次采集回来的结果是一个时间戳对应一组不同的指标数据，能提高数据的可靠性，使其更具有参考价值。

2.3 监控数据结构

Metricbeat收集到的CPU使用率监控数据：

点击展开完整json内容 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
{
  "_index": "metricbeat-7.14.1-2021.09.08-000001",
  "_type": "_doc",
  "_id": "-rhr_XsBMWVt4GMxm6fa",
  "_score": 1,
  "fields": {
    "system.cpu.iowait.norm.pct": [
      0
    ],
    "system.cpu.nice.norm.pct": [
      0.001
    ],
    "host.os.name.text": [
      "Ubuntu"
    ],
    "system.cpu.irq.norm.pct": [
      0
    ],
    "host.hostname": [
      "logstash"
    ],
    "host.mac": [
      "3a:24:ba:10:4d:21"
    ],
    "service.type": [
      "system"
    ],
    "system.cpu.iowait.pct": [
      0.001
    ],
    "host.os.version": [
      "20.04.2 LTS (Focal Fossa)"
    ],
    "host.os.name": [
      "Ubuntu"
    ],
    "system.cpu.idle.norm.pct": [
      0.995
    ],
    "agent.name": [
      "logstash"
    ],
    "host.name": [
      "logstash"
    ],
    "host.os.type": [
      "linux"
    ],
    "system.cpu.steal.pct": [
      0
    ],
    "system.cpu.steal.norm.pct": [
      0
    ],
    "agent.hostname": [
      "logstash"
    ],
    "host.architecture": [
      "x86_64"
    ],
    "agent.id": [
      "c02e1676-2468-4615-91db-8506429b9f03"
    ],
    "host.containerized": [
      false
    ],
    "ecs.version": [
      "1.10.0"
    ],
    "system.cpu.user.pct": [
      0.008
    ],
    "agent.version": [
      "7.14.1"
    ],
    "host.os.family": [
      "debian"
    ],
    "system.cpu.system.pct": [
      0.006
    ],
    "system.cpu.total.pct": [
      0.019
    ],
    "system.cpu.irq.pct": [
      0
    ],
    "system.cpu.user.norm.pct": [
      0.002
    ],
    "system.cpu.total.norm.pct": [
      0.005
    ],
    "host.ip": [
      "192.168.0.211",
      "fe80::3824:baff:fe10:4d21"
    ],
    "system.cpu.cores": [
      4
    ],
    "agent.type": [
      "metricbeat"
    ],
    "event.module": [
      "system"
    ],
    "host.os.kernel": [
      "5.4.0-84-generic"
    ],
    "system.cpu.softirq.pct": [
      0
    ],
    "host.id": [
      "629d68a1f15949af8c93d3860de0a0ad"
    ],
    "system.cpu.idle.pct": [
      3.98
    ],
    "system.cpu.softirq.norm.pct": [
      0
    ],
    "system.cpu.nice.pct": [
      0.005
    ],
    "metricset.period": [
      10000
    ],
    "host.os.codename": [
      "focal"
    ],
    "system.cpu.system.norm.pct": [
      0.002
    ],
    "metricset.name": [
      "cpu"
    ],
    "event.duration": [
      95499
    ],
    "@timestamp": [
      "2021-09-19T09:38:12.056Z"
    ],
    "host.os.platform": [
      "ubuntu"
    ],
    "host.cpu.usage": [
      0.0047
    ],
    "agent.ephemeral_id": [
      "e7489f9c-0669-48ce-b71c-efab634101eb"
    ],
    "event.dataset": [
      "system.cpu"
    ]
  }
}

2.4 什么是X-Pack

从6.3版本开始，Elastic Stack默认自带X-Pack。

X-Pack是Elastic Stack中用于支持安全、告警、监控、可视化等功能的插件的统称，在新版本的Elastic Stack中，很多方便易用的功能其实都是通过X-Pack实现的。

在后面的监控方案中，我们也会调用各个服务的X-Pack扩展去实现性能数据的采集。

3. 安装及配置Metricbeat

我们以Elasticsearch监控为例子，介绍Metricbeat的安装和配置，对于其他服务种类，也是类似的原理。

3.1 实验架构图

先来回顾一下，在本次实验中使用的架构：

diragram

3.2 在ubuntu系统使用DEB包安装

1
2
curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.14.1-amd64.deb
sudo dpkg -i metricbeat-7.14.1-amd64.deb

在其他系统上的安装方法，可以参考官方文档：Quick start: installation and configuration

3.3 metricbeat.yml配置示例

我们使用最简单的配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
metricbeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false
setup.template.settings:
  index.number_of_shards: 1
  index.codec: best_compression
setup.kibana:
  host: "192.168.0.213:5601"
output.elasticsearch:
  hosts: ["192.168.0.212:9200"]
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_docker_metadata: ~
  - add_kubernetes_metadata: ~

http.enabled: true
http.host: localhost
http.port: 5066

3.4 示例：在Metricbeat启用Elasticsearch模块

3.4.1 启用Elasticsearch模块

1
metricbeat modules enable elasticsearch-xpack

3.4.2 查看可用的模块

1
metricbeat modules list

输出结果示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
Enabled:
beat-xpack
elasticsearch-xpack
system

Disabled:
activemq
......
traefik
uwsgi
vsphere
windows
zookeeper

3.4.3 修改elasticsearch模块监控配置

在默认情况下，在路径/etc/metricbeat/modules.d中会包含大量的预设模块，根据metricbeat.yml中的配置我们可以看到，只要满足*.yml的模块配置文件都会被加载到。

在这里，我们使用的elastic search模块配置文件（elasticsearch-xpack.yml）如下：

1
2
3
4
5
6
7
8
9
# Module: elasticsearch
# Docs: https://www.elastic.co/guide/en/beats/metricbeat/7.13/metricbeat-module-elasticsearch.html

- module: elasticsearch
  xpack.enabled: true
  period: 10s
  hosts: ["http://192.168.0.212:9200"]
  #username: "user"
  #password: "secret"

3.4.4 Metricbeat服务的启停

使用deb安装后，会自动在系统创建metricbeat.service服务，我们按照正常的systemctl操作即可。

1
systemctl start metricbeat.service

3.4.5 在Kibana中查看监控数据

进入Kibana后，在Discover页面中选择metricbeat-* pattern，即可查看metricbeat收集回来的监控数据：

discover

4. 在Kibana展示监控数据

4.1 配置监控看板

我们使用Metricbeat可以解决监控数据的采集，但采集完后，还需要考虑监控数据可视化的问题。幸好，我们可以使用Kibana的插件Stack Monitoring。正如前面提到的，Kibana中的Stack Monitoring功能，正是X-Pack插件的其中一个，当你把Metricbeat安装好，并启用相应服务的x-pack模块之后，只需要简单的步骤就可以在Kibana页面中搭建一个性能看板。

但是笔者在撰文的时候，监控面板已经完成搭建了，无法重新演示最初的步骤。简单说，在进入到Stack Monitoring页面后，页面上会有步骤指引，按照步骤指引数据填写即可。

下面是一个不完全的例子：

Stack_Monitoring

4.2 性能监控看板介绍

4.2.1 Stack Monitoring

主要针对的是Elastic Stack中各个服务的业务监控，如ES中的Indexing Time或者是Logstash中队列。

Stack_Monitoring

4.2.2 Observability

侧重于展示各个安装了Metricbeat服务的节点的基础性能监控，可以直观地看到节点的CPU使用率、内存使用率、网络流量等。

observability

5. 总结

在知道现在这个ELK Stack版本可以支持这么方便的性能监控可视化方案之前，我原来是计划使用传统的Zabbix/Grafana方案的，也查了一些资料，计划使用各个服务的API去调取性能数据。但是在一番摸索之后发现有了这么强大的监控插件之后，我只想说一句“真香”。也因为Kibana的页面提供了太详细的指引了，我甚至觉得自己的步骤说明只会是狗尾续貂，所以就没有多作介绍。

值得一提的是，如果我们的服务器本身是运行在云平台上，云平台本身会有服务器的基础监控，我们就不需要考虑通过Metricbeat去做基础性能监控了。在这种情况下，如果集群中的服务不多，只部署一个metricbeat服务就足够。需要提醒的是，Metricbeat默认会通过/etc/metricbeat/modules.d/system.yml这个配置文件开启系统监控，如果不需要了记得去禁用掉。

metricbeat modules disable system

说那么多，也还是绕不去那句“纸上得来终觉浅，绝知此事要躬行”。在这里，我也只是为大家提供一个思路，展示的都是最简单的配置，具体要如何实施，还是要根据实际情况做灵活的调整。

6. 参考文档

Elastic Support Matrix

X-Pack for the Elastic Stack

How Monitoring works

How Metricbeat works

Metricbeat installation and configuration

Stack Monitoring

Observability overview page