1. 背景
Elasticsearch可廣泛應用於日誌分析、全文檢索、結構化數據分析等多種場景，大幅度降低維護多套專用系統的成本，在開源社區非常受歡迎。然而Elasticsearch爲滿足多種不同的使用場景，底層組合使用了多種數據結構，部分數據結構對具體的用戶使用場景可能是冗餘的，從而導致默認情況下無法達到性能和成本最優化。
幸運的是，Elasticsearch提供非常靈活的模板配置能力，用戶可以按需進行優化。多數情況下，用戶結合使用場景進行優化後，Elasticsearch的性能都會有數倍的提升，成本也對應有倍數級別的下降。本文主要介紹不同日誌使用場景下的調優經驗。
2. 日誌處理基本流程
日誌處理的基本流程包含：日誌採集 -> 數據清洗 -> 存儲 -> 可視化分析。Elastic Stack提供完整的日誌解決方案，幫助用戶完成對日誌處理全鏈路的管理，推薦大家使用。每個流程的處理如下：
- 日誌採集：從業務所在的機器上，較實時的採集日誌傳遞給下游。常用開源組件如Beats、Logstash、Fluentd等。
- 數據清洗：利用正則解析等機制，完成日誌從文本數據到結構化數據的轉換。用戶可使用Logstash 或 Elasticsearch Ingest模塊等完成數據清洗。
- 存儲：使用Elasticsearch對數據進行持久存儲，並提供全文搜索和分析能力。
- 可視化分析：通過圖形界面，完成對日誌的搜索分析，常用的開源組件如Kibana、Grafana。
使用Elastic Stack處理日誌的詳細過程，用戶可參考官方文章Getting started with the Elastic Stack，這裏不展開介紹。
3. 日誌場景調優
對於Elasticsearch的通用調優，之前分享的文章Elasticsearch調優實踐，詳細介紹了Elasticsearch在性能、穩定性方面的調優經驗。而對於日誌場景，不同的場景使用方式差別較大，這裏主要介紹常見使用方式下，性能和成本的優化思路。
3.1 基礎場景
對於多數簡單日誌使用場景，用戶一般只要求存儲原始日誌，並提供按關鍵字搜索日誌記錄的能力。對於此類場景，用戶可跳過數據清洗階段，並參考如下方式進行優化：
- 打開最優壓縮，一般可降低40%存儲。
- 設置原始日誌字段（message）爲text，去除keyword類型子字段，提供全文搜索能力，降低存儲。
- 關閉_all索引，前面已通過message提供全文搜索能力。
- 對於其他字符串字段，統一設置爲keyword類型，避免默認情況下字符串字段同時存儲text、keyword兩種類型的數據。
- 使用開源組件（如Beats）上報數據時會包含較多輔助信息，用戶可通過修改組件配置文件進行裁剪。
這樣去除message的keyword子字段、_all等冗餘信息後，再加上最優壓縮，可以保證數據相對精簡。下面給出這類場景的常用模板，供用戶參考：
{
"order": 5,
"template": "my_log_*",
"settings": {
"translog.durability": "async",
"translog.sync_interval": "5s",
"index.refresh_interval": "30s",
"index.codec": "best_compression" // 最優壓縮
},
"mappings": {
"_default_": {
"_all": { // 關閉_all索引
"enabled": false
},
"dynamic_templates": [
{
"log": { // 原始日誌字段，分詞建立索引
"match": "message",
"mapping": {
"type": "text"
}
}
},
{
"strings": { // 其他字符串字段，統一設置爲keyword類型
"match_mapping_type": "string",
"mapping": {
"type": "keyword"
}
}
}
]
}
}
}3.2 精準搜索場景
對於部分用戶，普通的全文檢索並不能滿足需求，希望精準搜索日誌中的某部分，例如每條日誌中包含程序運行時多個階段的耗時數據，對具體一個階段的耗時進行搜索就比較麻煩。對於此類場景，用戶可基於基礎場景，進行如下調整：
- 清洗過程中，可僅解析出需要精準搜索的部分作爲獨立字段，用於精準搜索。
- 對於精準搜索字段，如果無排序/聚合需求，可以關閉doc_values；對於字符串，一般使用keyword，可按需考慮使用text。
下面給出這類場景的常用模板，供用戶參考：
{
"order": 5,
"template": "my_log_*",
"settings": {
"translog.durability": "async",
"translog.sync_interval": "5s",
"index.refresh_interval": "30s",
"index.codec": "best_compression" // 最優壓縮
},
"mappings": {
"_default_": {
"_all": { // 關閉_all索引
"enabled": false
},
"dynamic_templates": [
{
"log": { // 原始日誌字段，分詞建立索引
"match": "message",
"mapping": {
"type": "text"
}
}
},
{
"precise_fieldx": { // 精準搜索字段
"match": "fieldx",
"mapping": {
"type": "keyword",
"doc_values": false
}
}
},
{
"strings": { // 其他字符串字段，統一設置爲keyword類型
"match_mapping_type": "string",
"mapping": {
"type": "keyword"
}
}
}
]
}
}
}3.3 統計分析場景
對於某些場景，日誌包含的主要是程序運行時輸出的統計信息，用戶通常會完全解析日誌進行精確查詢、統計分析，而是否保存原始日誌關係不大。對於此類場景，用戶可進行如下調整：
- 清洗過程中，解析出所有需要的數據作爲獨立字段；原始日誌非必要時，建議去除。
- 如果有強需求保留原始日誌，可以設置該字段enabled屬性爲false，只存儲不索引。
- 多數字段保持默認即可，會自動建立索引、打開doc_values，可用於查詢、排序、聚合。
- 對部分無排序/聚合需求、開銷高的字段，可以關閉doc_values。
下面給出這類場景的常用模板，供用戶參考：
{
"order": 5,
"template": "my_log_*",
"settings": {
"translog.durability": "async",
"translog.sync_interval": "5s",
"index.refresh_interval": "30s",
"index.codec": "best_compression" // 最優壓縮
},
"mappings": {
"_default_": {
"_all": { // 關閉_all索引
"enabled": false
},
"dynamic_templates": [
{
"log": { // 原始日誌字段，關閉索引
"match": "message",
"mapping": {
"enabled": false
}
}
},
{
"index_only_fieldx": { // 僅索引的字段，無排序/聚合需求
"match": "fieldx",
"mapping": {
"type": "keyword",
"doc_values": false
}
}
},
{
"strings": { // 其他字符串字段，統一設置爲keyword類型
"match_mapping_type": "string",
"mapping": {
"type": "keyword"
}
}
}
]
}
}
}ES 5.1及之後的版本，支持關鍵字查詢時自動選擇目標字段，用戶沒有必要再使用原始日誌字段提供不指定字段進行查詢的能力。
4. 小結
日誌的使用方式比較靈活，本文結合常見的客戶使用方式，從整體上對性能、成本進行優化。用戶也可結合自身業務場景，參考文章Elasticsearch調優實踐進行更細緻的優化。