內(nèi)存和打開的文件數(shù)如果你的elasticsearch運行在專用服務(wù)器上，經(jīng)驗值是分配一半內(nèi)存給elasticsearch。另一半用于系統(tǒng)緩存，這東西也很重要的。 你可以通過修改ES_HEAP_SIZE環(huán)境變量來改變這個設(shè)定。在啟動elasticsearch之前把這個變量改到你的預(yù)期值。另一個選擇上球該elasticsearch的ES_JAVA_OPTS變量，這個變量時在啟動腳本(elasticsearch.in.sh或elasticsearch.bat)里傳遞的。你必須找到-Xms和-Xmx參數(shù)，他們是分配給進(jìn)程的最小和最大內(nèi)存。建議設(shè)置成相同大小。嗯，ES_HEAP_SIZE其實就是干的這個作用。 你必須確認(rèn)文件描述符限制對你的elasticsearch足夠大，建議值是32000到64000之間。關(guān)于這個限制的設(shè)置，另有教程可以參見。 目錄數(shù)一個可選的做法是把所有日志存在一個索引里，然后用ttl field來確保就日志被刪除掉了。不過當(dāng)你日志量夠大的時候，這可能就是一個問題了，因為用TTL會增加開銷，優(yōu)化這個巨大且唯一的索引需要太長的時間，而且這些操作都是資源密集型的。 建議的辦法是基于時間做目錄。比如，目錄名可以是YYYY-MM-DD的時間格式。時間間隔完全取決于你打算保留多久日志。如果你要保留一周，那一天一個目錄就很不錯。如果你要保留一年，那一個月一個目錄可能更好點。目錄不要太多，因為全文搜索的時候開銷相應(yīng)的也會變大。 如果你選擇了根據(jù)時間存儲你的目錄，你也可以縮小你的搜索范圍到相關(guān)的目錄上。比如，如果你的大多數(shù)搜索都是關(guān)于最近的日志的，那么你可以在自己的界面上提供一個”快速搜索”的選項只檢索最近的目錄。 輪轉(zhuǎn)和優(yōu)化移除舊日志在有基于時間的目錄后變得異常簡單： 這個操作的速度非?？?，和刪除大小差不多的少量文件速度接近。你可以放進(jìn)crontab里半夜來做。 Optimizing indices是在非高峰時間可以做的一件很不錯的事情。因為它可以提高你的搜索速度。尤其是在你是基于時間做目錄的情況下，更建議去做了。因為除了當(dāng)前的目錄外，其他都不會再改，你只需要對這些舊目錄優(yōu)化一次就一勞永逸了。 分片和復(fù)制通過elasticsearch.yml或者使用REST API，你可以給每個目錄配置自己的設(shè)定。具體細(xì)節(jié)參見鏈接。 有趣的是分片和復(fù)制的數(shù)量。默認(rèn)情況下，每個目錄都被分割成5個分片。如果集群中有一個以上節(jié)點存在，每個分片會有一個復(fù)制。也就是說每個目錄有一共10個分片。當(dāng)往集群里添加新節(jié)點的時候，分片會自動均衡。所以如果你有一個默認(rèn)目錄和11臺服務(wù)器在集群里的時候，其中一臺會不存儲任何數(shù)據(jù)。 每個分片都是一個Lucene索引，所以分片越小，elasticsearch能放進(jìn)分片新數(shù)據(jù)越少。如果你把目錄分割成更多的分片，插入速度更快。請注意如果你用的是基于時間的目錄，你只在當(dāng)前目錄里插入日志，其他舊目錄是不會被改變的。 太多的分片帶來一定的困難——在空間使用率和搜索時間方面。所以你要找到一個平衡點，你的插入量、搜索頻率和使用的硬件條件。 另一方面，復(fù)制幫助你的集群在部分節(jié)點宕機(jī)的時候依然可以運行。復(fù)制越多，必須在線運行的節(jié)點數(shù)就可以越小。復(fù)制在搜索的時候也有用——更多的復(fù)制帶來更快的搜索，同時卻增加創(chuàng)建索引的時間。因為對豬分片的修改，需要傳遞到更多的復(fù)制。 映射_source和_allMappings定義了你的文檔如何被索引和存儲。你可以，比如說，定義每個字段的類型——比如你的syslog里，消息肯定是字符串，嚴(yán)重性可以是整數(shù)。怎么定義映射參見鏈接。 映射有著合理的默認(rèn)值，字段的類型會在新目錄的第一條文檔插入的時候被自動的檢測出來。不過你或許會想自己來調(diào)控這點。比如，可能新目錄的第一條記錄的message字段里只有一個數(shù)字，于是被檢測為長整型。當(dāng)接下來99%的日志里肯定都是字符串型的，這樣Elasticsearch就沒法索引他們，只會記錄一個錯誤日志說字段類型不對。這時候就需要顯式的手動映射”message” : {“type” : “string”}。如何注冊一個特殊的映射詳見鏈接。 當(dāng)你使用基于時間的目錄名時，在配置文件里創(chuàng)建索引模板可能更適合一點。詳見鏈接。除去你的映射，你?？梢远x其他目錄屬性，比如分片數(shù)等等。 在映射中，你可以選擇壓縮文檔的_source。這實際上就是整行日志——所以開啟壓縮可以減小索引大小，而且依賴你的設(shè)定，提高性能。經(jīng)驗值是當(dāng)你被內(nèi)存大小和磁盤速度限制的時候，壓縮源文件可以明顯提高速度，相反的，如果受限的是CPU計算能力就不行了。更多關(guān)于source字段的細(xì)節(jié)詳見鏈接。 默認(rèn)情況下，除了給你所有的字段分別創(chuàng)建索引，elasticsearch還會把他們一起放進(jìn)一個叫_all的新字段里做索引。好處是你可以在_all里搜索那些你不在乎在哪個字段找到的東西。另一面是在創(chuàng)建索引和增大索引大小的時候會使用額外更多的CPU。所以如果你不用這個特性的話，關(guān)掉它。即使你用，最好也考慮一下定義清楚限定哪些字段包含進(jìn)_all里。詳見鏈接。 刷新間隔在文檔被索引后，Elasticsearch某種意義上是近乎實時的。在你搜索查找文檔之前，索引必須被刷新。默認(rèn)情況下，目錄是每秒鐘自動異步刷新的。 刷新是一個非常昂貴的操作，所以如果你稍微增大一些這個值，你會看到非常明顯提高的插入速率。具體增大多少取決于你的用戶可以接受到什么程度。 你可以在你的index template里保存期望的刷新間隔值。或者保存在elasticsearch.yml配置文件里，或者通過(REST API)[http://www./guide/reference/api/admin-indices-update-settings.html]升級索引設(shè)定。 另一個處理辦法是禁用掉自動刷新，辦法是設(shè)為-1。然后用REST API手動的刷新。當(dāng)你要一口氣插入海量日志的時候非常有效。不過通常情況下，你一般會采用的就是兩個辦法：在每次bulk插入后刷新或者在每次搜索前刷新。這都會推遲他們自己本身的操作響應(yīng)。 Thrift通常時，REST接口是通過HTTP協(xié)議的，不過你可以用更快的Thrift替代它。你需要安裝transport-thrift plugin同時保證客戶端支持這點。比如，如果你用的是pyes Python client，只需要把連接端口從默認(rèn)支持HTTP的9200改到默認(rèn)支持Thrift的9500就好了。 異步復(fù)制通常，一個索引操作會在所有分片(包括復(fù)制的)都完成對文檔的索引后才返回。你可以通過index API設(shè)置復(fù)制為異步的來讓復(fù)制操作在后臺運行。你可以直接使用這個API，也可以使用現(xiàn)成的客戶端(比如pyes或者rsyslog的omelasticsearch)，都會支持這個。 用過濾器替代請求通常，當(dāng)你搜索日志的時候，你感興趣的是通過時間序列做排序而不是評分。這種使用場景下評分是很無關(guān)緊要的功能。所以用過濾器來查找日志比用請求更適宜。因為過濾器里不會執(zhí)行評分而且可以被自動緩存。兩者的更多細(xì)節(jié)參見鏈接。 批量索引建議使用bulk API來創(chuàng)建索引它比你一次給一條日志創(chuàng)建一次索引快多了。 主要要考慮兩個事情：
|
|
|
