没有日志分析工具之前,运维工作存在哪些痛点?
如上所有的痛点都可以使用日志分析系统ELK解决,通过ELK,将运维所有的服务器日志,业务系统日志都收集到一个平台下,然后提取想要的内容,比如错误信息,警告信息等,当过滤到这种信息,就马上告警,告警后,运维人员就能马上定位是哪台机器、哪个业务系统出现了问题,出现了什么问题。
其实 ELK
不是一个单独的技术,而是一套技术的组合,是由 elasticsearch、logstash、kibana
组合而成的。
ELK
是一套开源免费、功能强大的日志分析管理系统。ELK
可以将我们的系统日志、网站日志、应用系统日志等各种日志进行收集、过滤、清洗,然后进行集中存放并可用于实时检索、分析。
E: elasticsearch
数据存储;L: logstash
数据采集、数据清洗、数据过滤;K: kibana
数据分析、数据展示;简单来说就是将 Logstash
替换成了 filebeat
,那为什么要进行替换?
因为 logstash
是基于 JAVA
开发的,在收集日志时会大量的占用业务系统资源,从而影响正常线上业务。
而替换成 filebeat
这种较为轻量的日志收集组件,会让业务系统的运行更加的稳定。
Haproxy、Nginx
Nginx、Tomcat、Httpd、PHP
mysql、redis、mongo、elasticsearch
nfs、glusterfs、fastdfs
message、security
Elasticsearch
是一个分布式、RESTful
风格的搜索和数据分析引擎。
数据存储、数据搜索、数据分析。
Document
文档就是用户存在 es
中的一些数据,它是 es
中存储的最小单元。(类似于表中的一行数据。)注意:每个文档都有一个唯一的 ID
表示,可以自行指定,如果不指定 es
会自动生成。
索引其实是一堆文档 Document
的集合。(它类似数据库的中的一个表)
在 ES
中,Document
就是一个 Json Object
,一个Json Object
其实是由多个字段组成的,每个字段它有不同的数据类型。
字符串:text、keyword。
数值型:long,integer,short,byte,double,float
布尔:boolean
日期:date
二进制:binary
范围类型:integer_range,float_range,long_range,double_range,date_range
ES
索引、文档、字段关系小结:
一个索引里面存储了很多的 Document
文档,一个文档就是一个json object
,一个json object
是由多个不同或相同的 filed
字段组成;
1.ES的操作和我们传统的数据库操作不太一样,它是通过 RestfulAPI 方式进行对ES进行操作,其实本质上就是通过 http 的方式去变更我们的资源状态。
通过 URI 的方式指定要操作的资源,比如 Index、Document等。
通过 Http Method 指明资源操作方法,如GET、POST、PUT、DELETE 等。
2.常见操作ES的两种方式:Curl 命令行、Kibana DevTools
3.安装配置kibana,用于数据展示。注意: Kibana不产生数据,需要获取ES的数据进行展示。
[root@es-node1 ~]# rpm -ivh kibana-7.4.0-x86_64.rpm
#配置kibana
[root@kibana ~]# grep "^[a-Z]" /etc/kibana/kibana.yml
server.port: 5601 #kibana默认监听端口
server.host: "0.0.0.0" #kibana监听地址段
elasticsearch.hosts: ["http://localhost:9200"] #kibana丛coordinating节点获取数据
i18n.locale: "zh-CN" #kibana汉化
#启动kibana
[root@kibana ~]# systemctl start kibana
[root@kibana ~]# systemctl enable kibana
es
有专门的 Index API
,用于创建、更新、删除索引配置等*
创建索引 api
如下:
# 创建索引
PUT /oldxu_index
#查看所有已存在的索引
GET _cat/indices
删除索引 api
如下:
#删除索引
DELETE /oldxu_index
ES
为索引添加文档,有专门的 Document API
创建文档,需要指定ID
#创建一个文档(指定ID)
POST /oldxu_index/_doc/1
{
"username": "oldxu",
"age": 18,
"salary": 1000000
}
创建文档,不指定ID
查询文档,指定要查询的文档id
查询文档,搜索所有文档,用_search
es
允许通过 _bulk
一次创建多个文档,从而减少网络传输开销,提升写入速率。
#批量创建document
POST _bulk
{"index":{"_index":"tt","_id":"1"}}
{"name":"oldxu","age":"18"}
{"create":{"_index":"tt","_id":"2"}}
{"name":"oldqiang","age":"30"}
{"delete":{"_index":"tt","_id":"2"}}
{"update":{"_id":"1","_index":"tt"}}
{"doc":{"age":"20"}}
es
允许通过 _mget
一次查询多个文档。
#批量查询document
GET _mget
{
"docs": [
{
"_index": "tt",
"_id": "1"
},
{
"_index": "tt",
"_id": "2"
}
]
}
es
天然支持集群模式,其好处主要有两个: es
集群可以支持PB级的数据;ELasticsearch
集群是由多个节点组成的,通过 cluster.name
设置集群名称,并且用于区分其它的集群,每个节点通过 node.name
指定节点的名称。
es
节点加入集群主机名称 | IP地址 |
---|
所有集群节点都需要安装 ES
软件
# yum install java -y
# rpm -ivh elasticsearch-7.4.0-x86_64.rpm
[root@es-node1-172 ~]# grep "^[a-Z]" /etc/elasticsearch/elasticsearch.yml
cluster.name: my-oldxu #集群名称
node.name: es-node1 #节点名称
path.data: /var/lib/elasticsearch #数据存储路径
path.logs: /var/log/elasticsearch #日志存储路径
#bootstrap.memory_lock: true #不使用swap分区
network.host: #本机内网IP
http.port: 9200 #监听端口
discovery.seed_hosts: ["172.16.1.161", "172.16.1.162", "172.16.1.163"] #集群主机列表
cluster.initial_master_nodes: ["172.16.1.161", "172.16.1.162", "172.16.1.163"] #仅第一次启动集群时进行选举
[root@oldxu-es-node2-172 ~]# grep "^[a-Z]" /etc/elasticsearch/elasticsearch.yml
cluster.name: my-oldxu
node.name: es-node2
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: #本机内网IP
discovery.seed_hosts: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
cluster.initial_master_nodes: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
[root@oldxu-es-node3-172 ~]# grep "^[a-Z]" /etc/elasticsearch/elasticsearch.yml
cluster.name: my-oldxu
node.name: es-node3
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: #本机内网IP
discovery.seed_hosts: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
cluster.initial_master_nodes: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
http.cors.enabled: true
http.cors.allow-origin: "*"
如何通过可视化方式检查 ES
集群状态;可以通过 cerebro
可视化工具检测;cerebro 传送门
[root@open ~]# rpm -ivh cerebro-0.8.5-1.noarch.rpm
[root@open ~]# vim /etc/cerebro/application.conf
data.path = "/tmp/cerebro.db"
[root@open ~]# systemctl start cerebro
[root@open-192 ~]# netstat -lntp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 :::9000 :::* LISTEN 504/java
es
集群中节点类型介绍 Cluster State
Master
Data
Coordinating
Cluster State
:集群相关的数据称为 cluster state
;会存储在每个节点中,主要有如下信息: ES
集群中只能有一个 master
节点,master
节点用于控制整个集群的操作;master
主要维护 Cluster State
,当有新数据产生后,Master
会将最新的数据同步给其他 Node
节点;master
节点是通过选举产生的,可以通过 node.master: true
指定为Master
节点。( 默认true
)当我们通过API
创建索引 PUT /oldxu_index
,Cluster State
则会发生变化,由 Master
同步至其他 Node
节点;
data
节点,默认节点都是 data
类型,相关配置node.data: true
( 默认为 true
)data
节点;coordinating
节点,该节点为所有节点的默认角色,不能取消coordinating
节点主要将请求路由到正确的节点处理。比如创建索引的请求会由 coordinating
路由到 master
节点处理;当配置 node.master: false、node.data:false
则为 coordinating
节点replication
解决,这样每个节点上都有完备的数据。node2
上是 oldxu_index
索引的一个完整副本数据。shard
解决;es
支持 Pb
级数据的基石oldxu_index
索引,指定3个分片,和1个副本;PUT /oldxu_index
{
"settings": {
"index": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
}
问题:目前一共有3个ES节点,如果此时增加一个新节点是否能提高 oldxu_index
索引数据容量?
答案:不能,因为 oldxu_index
只有3个分片,已经分布在3台节点上,那么新增的第四个节点对于 oldxu_index
而言是无法使用到的。所以也无法带来数据容量的提升;
问题:目前一共有3个ES节点,如果增加副本数是否能提高 oldxu_index
的读吞吐量;
答案:不能,因为新增的副本还是会分布在这 node1、node2、node3
这三个节点上的,还是使用了相同的资源,也就意味着有读请求来时,这些请求还是会分配到 node1、node2、node3
上进行处理、也就意味着,还是利用了相同的硬件资源,所以不会提升读取的吞吐量;
问题:如果需要增加读吞吐量性能,应该怎么来做;
答案:增加读吞吐量还是需要添加节点,比如在增加三个节点 node4、node5、node6
那么将原来的 R0、R1、R2
分别迁移至新增的三个节点上,当有读请求来时会被分配 node4、node5、node6
,也就意味着有新的 CPU、内存、IO
,这样就不会在占用 node1、node2、node3
的硬件资源,那么这个时候读吞吐量才会得到真正的提升;
Cluster Health
获取集群的健康状态,整个集群状态包括以下三种: green
健康状态,指所有主副分片都正常分配yellow
指所有主分片都正常分配,但是有副本分片未正常分配red
有主分片未分配,表示索引不完备,写可能有问题。(但不代表不能存储数据和读取数据)我们可以通过 GET _cluster/health?pretty=true
方式获取集群状态;
[root@es-node1-172 ~]# curl http://172.16.1.162:9200/_cluster/health?pretty=true
{
"cluster_name" : "my-oldxu",
"status" : "green", # 重点关注status一栏
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 33,
"active_shards" : 66,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
通过 Shell
脚本获取集群状态信息;如果出现异常则触发报警邮件;
[root@es-node1-172 ~]# curl http://172.16.1.162:9200/_cluster/health?pretty=true
{
"cluster_name" : "my-oldxu",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 33,
"active_shards" : 66,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
#shell检测脚本
# curl -s http://172.16.1.162:9200/_cluster/health?pretty=true | grep "status" |awk -F '"' '{print $4}'
所谓故障转移指的是,当集群中有节点发生故障时,这个集群是如何进行自动修复的。
ES
集群目前是由3个节点组成,如下图所示,此时集群状态是 green
node1
所在机器宕机导致服务终止,此时集群会如何处理;大体分为三个步骤: node2
和 node3
发现 node1
无法响应;一段时间后会发起 master
选举,比如这里选择 node2
为 master
节点;此时集群状态变为 Red
状态;
node2
发现主分片 P0
未分配,将 node3
上的 R0
提升为主分片;此时所有的主分片都正常分配,集群状态变为 Yellow
状态;
node2
将 P0
和 P1
主分片重新生成新的副本分片 R0、R1
,此时集群状态变为 Green
;
ES文档分布式存储,当一个文档存储至 ES集群时,存储的原理是什么样的?
如图所示,当我们想一个集群保存文档时,Document1是如何存储到分片P1的?选择P1的依据是什么?
其实是有一个文档到分片的映射算法,其目是使所有文档均匀分布在所有的分片上,那么是什么算法呢?随机还是轮询呢? 这种是不可取的,因为数据存储后,还需要读取,那这样的话如何读取呢?
实际上,在ES 中,通过如下的公式计算文档对应的分片存储到哪个节点,计算公式如下:
shard = hash(routing) % number_of_primary_shards
# hash 算法保证将数据均匀分散在分片中
# routing 是一个关键参数,默认是文档id,也可以自定义。
# number_of_primary_shards 主分片数
# 注意:该算法与主分片数相关,一但确定后便不能更改主分片。
# 因为一旦修改主分片修改后,Share的计算就完全不一样了。
主机名称 | IP地址 |
---|
[root@oldxu-es-node4-172 ~]# grep "^[a-Z]" /etc/elasticsearch/elasticsearch.yml
cluster.name: my-oldxu
node.name: es-node4
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
#bootstrap.memory_lock: true
node.data: true #data节点
node.master: false #不参与master选举
discovery.seed_hosts: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
[root@oldxu-es-node5-172 ~]# grep "^[a-Z]" /etc/elasticsearch/elasticsearch.yml
cluster.name: my-oldxu
node.name: es-node5
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
#bootstrap.memory_lock: true
network.host: 0.0.0.0
node.data: true #data节点
node.master: false #不参与master选举
discovery.seed_hosts: ["172.16.1.161", "172.16.1.162", "172.16.1.163"]
通过 cerebor
检查集群扩展后的状态;如果出现集群无法加入、或者加入集群被拒绝,尝试删除 /var/lib/elasticsearch
下的文件,然后重启 es
;