
創作人:高冬冬
審稿人:劉帥
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-settingsLogstash
在配置檔案 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 采集 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 中檢視監控頁面
專用的監控叢集
在生産環境推薦部署專用的監控叢集來實作叢集的指責分離
- 減少被監控的業務叢集的負載和存儲壓力。
- 防止被監控叢集的故障影響監控功能。
- 實作職責隔離,比如監控叢集和業務叢集可配置不同的安全政策,保障級别等。
統一監控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
- 頂級
元件和 query 中 bool 相對應。BooleanQuery
- 第二個
對應于條件查詢,該條件在内部轉換為一個Boolean 的 should 子句,它有兩個子查詢,分别與terms query中的 “sue” 和 “sally” 相對應。BooleanQuery
- 在
标有 “name:fred” 這是對應于 match: fred 在查詢中。TermQuery
如圖你可以看到每一行的 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 的權限
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監控。
在 Kibana 上操作,依次點選 Mangement-> Stack Management ->Logstash Pipelines->Create pipeline,輸入配置參數後,點選 Create and Deploy 即可建立和釋出成功。
首先往 /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 級日志平台的規劃,部署,優化和運維有豐富的經
驗和實踐,喜歡學習運用新技術,解決工作中問題和提高生産力。希望以後有更多的機
會,分享輸出更多有價值的東西給大家。