先說Elasticsearch配置的一個重要組成部分：操作系統。在索引過程中，尤其是有很多分片和副本時，Elasticsearch會創建若干文件。因此，OS對打開文件數量的限制不能少於32000。Linux服務器通常可以在/etc/security/limits.conf中進行修改，並且可以利用ulimit命令來查看當前值。接下來的設置與每個節點的內存空間大小有關。默認的內存空間（1024MB）可能不夠。如果在日誌文件中發現帶有OutOfMemory錯誤的記錄，則應將環境變量ES_HEAP_SIZE設爲大於1024的值。注意不應超過總可用物理內存的50%，剩餘內存可用作磁盤高速緩存，這樣可以大大提高搜索性能。
昨天在導入數據的時候，數據量不是很大，八十幾萬個event，導入的過程中Kafka lag不斷上升，elasticsearch開始無響應，master與slave斷掉連接，重啓後無法自動發現。查資料後得知這是elasticsearch的腦裂現象，這篇博客 http://m.blog.csdn.net/blog/huwei2003/47004745 提供了處理方案，按照他的說法，處理方式如下：
9.115.42.77 的elasticsearch的config下的elasticsearch.yml：
################################## Discovery ##################################
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.timeout: 120s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["9.115.42.89", "9.115.42.95"]
9.115.42.89 的elasticsearch的config下的elasticsearch.yml：
################################## Discovery ##################################
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.timeout: 120s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["9.115.42.77", "9.115.42.95"]
9.115.42.95 的elasticsearch的config下的elasticsearch.yml：
################################## Discovery ##################################
discovery.zen.minimum_master_nodes: 1
discovery.zen.ping.timeout: 120s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["9.115.42.77", "9.115.42.89"]
均啓動elasticsearch後需要等比較長的一段時間構建集羣，但是經過http://9.115.42.77:9200/_cluster/health?pretty=true發現昨天導入數據生成的shard大部分都unassigned了，導致集羣status爲red，刪除了index，重新導入。作爲indexer的logstash又報出flush exception。
因爲elasticsearch有三種protocol，上面關閉了multicast，這時就要在logstash裏爲node transport mode做配置，配置如下：
output {
elasticsearch{
cluster => "elasticsearch_production"
protocol => "node"
host => ["9.115.42.77","9.115.42.89","9.115.42.95"]
}
}
完畢，可以正常工作。