在 Elasticsearch 中備份舊索引
我們有一個 ELK (ElasticSearch-Logstash-Kibana) 部署，我們通過 logstash 將日誌發送到 Elasticsearch 集群。每天都會創建索引。我們關閉超過 3 天的索引，並對超過 7 天的索引進行快照，然後通過 curator 將它們推送到 Amazon S3。
我們有大約 10 個不同的每日索引，每個索引的平均大小約為 1GB。複製因子為 1。每個索引有 2 個分片。Logstash 以每秒 2000 個 log_events 的速率將數據推送到 ES Cluster
我們的拓撲
- 3 專用主控+數據
- 1 個專用客戶端節點 + Kibana
硬體配置
- 12芯
- 64 GB 記憶體
- 2 TB 旋轉磁碟
- Debian 7
- 彈性搜尋版本 - 1.7.1
- Logstash - 1.5.3
遵循所有標準配置，如發現中的單播模式，已分配 30 GB RAM。
現在，快照作業通過 curator 從客戶端機器上執行，請求本地發送到客戶端機器上執行的 ES 實例。Logstash 將日誌直接發送到客戶端節點
正在使用的館長命令：-
curator --timeout 21600 --host es-client --port 9200 snapshot --name $snapshot_name_$project-$date --repository walle_elk_archive indices --older-than 3 --time-unit days --timestring %Y-%m-%d --prefix $prefix有人可以在以下方面幫助我：-
- 可以像我們一樣在客戶端機器上執行 curator 作業嗎？
- 可以從一台機器上拍攝所有索引的快照嗎？
- 由於日誌是連續推送的，當快照創建和推送到 Amazon S3 進行時，是否會使集群不穩定？
- 人們從 Elasticsearch 備份舊索引時通常遵循哪些最佳實踐？
可以像我們一樣在客戶端機器上執行 curator 作業嗎？
是的，因為“客戶端”機器除了在您的 ES 集群上觸發 REST 請求並等待響應之外什麼都不做。
可以從一台機器上拍攝所有索引的快照嗎？
再次，是的。原因與第一個問題相同。
由於日誌是連續推送的，當快照創建和推送到 Amazon S3 進行時，是否會使集群不穩定？
Snapshotting process is executed in non-blocking fashion. All indexing and searching operation can continue to be executed against the index that is being snapshotted.索引速度可能會略微放緩，但根據您的機器規格，我認為它可能會很好，但除非您嘗試，否則真的沒有辦法知道。快照速度的限制因素可能是共享文件系統儲存庫的磁碟，以及 S3 儲存庫的 Internet 連接速度。
在使用 S3 儲存庫以及它如何影響流程方面，S3 儲存庫外掛的文件中沒有太多詳細資訊（例如，沒有）關於它的實際工作方式。我懷疑每個持有主分片的數據節點都會將其分片推送到儲存庫、S3 或其他地方。這意味著在對 S3 儲存庫執行快照時，ES 集群上的負載可能不會比對共享文件系統儲存庫的負載多。
再次，測試它，因為每個環境都是獨一無二的，對一個人有用的可能不適用於下一個。
從 Elasticsearch 備份舊索引時，人們通常遵循哪些最佳實踐？
我發現 ES 有很好的文件，並且有一個關於Snapshot And Restore的部分。在“最佳”實踐方面實際上並沒有太多，所以除非你在網上遇到其他一些資源，否則我會說你最好的選擇就是開始嘗試看看什麼對你有用。