目錄
1.10.添加其他流行資源（Adding Other Popular Sources）
1.16.彈性和恢復（Resiliency and Recovery）
1.部署和擴展Logstash（Deploying and Scaling Logstash）
從操作日誌和指標分析到企業和應用程序搜索，Elastic Stack可用於大量用例。能夠確保將數據可擴展的，持久的和安全的傳輸到Elasticsearch是至關重要，尤其是對於關鍵任務環境。
本文檔的目的是重點介紹Logstash的最常見體系結構模式，以及如何隨着部署的增長而有效地擴展。重點將放在操作日誌，指標和安全性分析用例上，因爲它們往往需要更大規模的部署。根據您自己的要求，此處提供的部署和擴展建議可能會有所不同
1.1.入門指南
對於初次使用的用戶，如果您只是想尾隨日誌文件以掌握Elastic Stack的功能，我們建議您嘗試使用Filebeat Modules。Filebeat模塊使您能夠在幾分鐘內快速收集，解析和索引常用日誌類型，並查看預建的Kibana儀表板（dashboards ）。Metricbeat模塊提供類似的體驗，但帶有度量標準數據。 在這種情況下，Beats會將數據直接傳送到Elasticsearch，在其中攝取節點（Ingest Nodes）將處理和索引您的數據。
1.2.介紹Logstash
將Logstash集成到您的體系結構中的主要好處是什麼？
- 通過攝取高峯擴展-Logstash具有基於磁盤的自適應緩衝系統，該系統將吸收傳入的吞吐量，從而減輕背壓
- 從其他數據源（例如數據庫，S3或消息傳遞隊列）中提取數據
- 將數據發送到多個目的地，例如S3，HDFS或寫入文件
- 使用條件數據流邏輯組成更復雜的處理管道
1.3.縮放攝取（Scaling Ingest）
Beats和Logstash使攝取變得很棒。 它們共同提供了可擴展且具有彈性的全面解決方案。 您能期待什麼？
- 水平可擴展性，高可用性和可變負載處理
- 消息持久性與至少一次交付保證
- 具有身份驗證和有線加密的端到端安全傳輸
1.4.Beats與Logstash
Beats運行在數千臺邊緣主機服務器上，將日誌收集，拖尾和運送到Logstash。Logstash用作集中式流引擎，用於數據統一和擴充。Beats輸入插件（Beats input plugin）爲Beats公開了一個基於確認的安全終結點，以將數據發送到Logstash。
強烈建議啓用持久隊列，並且這些體系結構特徵假定已啓用它們。 我們建議您查看Persistent Queues文檔，以瞭解功能優勢以及彈性的更多詳細信息。
1.5.可擴展性（Scalability）
Logstash是水平可伸縮的，可以形成運行同一管道的節點組。Logstash的自適應緩衝功能即使在吞吐量變化不定的情況下，也可以促進流暢的流傳輸。如果Logstash層成爲攝取瓶頸，則只需添加更多節點即可進行橫向擴展。
以下是一些一般性建議：
- Beats應該在一組Logstash節點之間實現負載平衡。
- 建議至少使用兩個Logstash節點以實現高可用性。
- 通常每個Logstash節點僅部署一個Beats輸入，但是也可以爲每個Logstash節點部署多個Beats輸入，以公開用於不同數據源的獨立端點。
1.6.彈性（Resiliency）
在此攝取流中使用Filebeat或Winlogbeat進行日誌收集時，可以保證至少一次交付。 從Filebeat或Winlogbeat到Logstash以及從Logstash到Elasticsearch的兩種通信協議都是同步的，並且支持確認。 其他Beats尚不支持確認。
Logstash持久隊列提供跨節點故障的保護。 對於Logstash中的磁盤級彈性，確保磁盤冗餘很重要。 對於本地部署，建議您配置RAID。 在雲端或容器化環境中運行時，建議您使用具有可反映數據SLA的複製策略的永久磁盤。
確保queue.checkpoint.writes: 1設置至少保證一次。 有關更多詳細信息，請參閱持久性隊列持久性文檔（persistent queue durability）。
1.7.處理（Processing）
Logstash通常將提取帶有grok 或 dissect的字段，增強地理信息（ geographical），並可以使用文件，數據庫或Elasticsearch（file, database, ， Elasticsearch）查找數據集進一步豐富事件。 請注意，處理複雜性會影響整體吞吐量和CPU利用率。 確保檢查其他可用的過濾器插件（available filter plugins.）。
1.8.安全傳輸（Secure Transport）
在整個交付鏈中都可以使用企業級安全性。
Beats to Logstash以及Logstash to Elasticsearch的傳輸都建議使用有線加密。
與Elasticsearch進行通訊時，有很多安全選項，包括基本身份驗證，TLS，PKI，LDAP，AD和其他自定義領域。 要啓用Elasticsearch安全性，請參閱Securing the Elastic Stack.
1.9.監控方式（Monitoring）
在運行Logstash 5.2或更高版本時，Monitoring UI可以深入瞭解您的部署指標，幫助您觀察性能並在擴展時緩解瓶頸。 監視是基本許可證下的X-Pack功能，因此可以免費使用。 首先，請參閱Monitoring Logstash。
如果首選外部監視，則有些 Monitoring APIs會返回時間點指標快照。
1.10.添加其他流行資源（Adding Other Popular Sources）
用戶可能還有其他收集日誌數據的機制，可以很容易地將它們集成並集中到Elastic Stack中。 讓我們看一下幾種情況：
1.11.TCP，UDP和HTTP協議
TCP，UDP和HTTP協議是將數據輸入Logstash的常用方法。 Logstash可以使用相應的TCP，UDP和HTTP輸入插件公開端點偵聽器。 下面列舉的數據源通常是通過這三種協議之一來提取的。
TCP協議不支持應用程序級別的確認，因此連接問題可能會導致數據丟失。
對於高可用性方案，應添加第三方硬件或軟件負載平衡器（例如HAProxy），以將流量散發到一組Logstash節點。
1.12.網絡和安全數據
儘管Beats可能已經滿足了您的數據提取用例，但網絡和安全性數據集卻以多種形式出現。 讓我們來談談其他一些攝取要點。
- 網絡線路數據-使用 Packetbeat收集和分析網絡流量。
- Netflow v5 / v9 / v10-Logstash可以使用Netflow codec理解來自Netflow / IPFIX導出程序的數據。
- Nmap-Logstash使用Nmap codec接受並解析Nmap XML數據。
- SNMP陷阱-Logstash具有本機SNMP陷阱輸入。
- CEF-Logstash使用 CEF codec從Arcsight SmartConnectors等系統接收並解析CEF數據。 有關更多詳細信息，請參閱此博客系列（blog series）。
1.13.集中式系統日誌服務器
現有的syslog服務器技術（例如rsyslog和syslog-ng）通常將syslog發送到Logstash TCP或UDP端點，以進行提取，處理和持久化。 如果數據格式符合RFC3164，則可以將其直接輸入到Logstash syslog input中。
1.14.基礎設施與應用數據和物聯網
可以使用Metricbeat收集基礎結構和應用程序指標，但是應用程序還可以將Webhooks發送到Logstash HTTP輸入，或者使用HTTP poller input plugin從HTTP端點輪詢指標。
對於使用log4j2登錄的應用程序，建議使用SocketAppender將JSON發送到Logstash TCP輸入。 另外，log4j2也可以登錄到文件以通過FIlebeat進行收集。 不建議使用log4j1 SocketAppender。
諸如Raspberry Pi，智能手機和聯網車輛之類的IoT設備通常通過以下協議之一發送遙測數據。
1.15.集成消息傳遞隊列
如果您將消息隊列技術用作現有基礎架構的一部分，那麼將數據放入彈性堆棧很容易。 對於使用Redis或RabbitMQ等外部排隊層僅通過Logstash進行數據緩衝的現有用戶，建議使用Logstash持久隊列而不是外部排隊層。 通過消除攝取架構中不必要的複雜性，這將有助於總體上簡化管理。
對於想要從現有Kafka部署中集成數據或需要臨時使用基礎存儲的用戶，Kafka可以充當Beats可以持久存在且Logstash節點可以使用的數據中心。
其他TCP，UDP和HTTP源可以使用Logstash作爲管道來持久存在Kafka，以代替負載平衡器來實現高可用性。 然後，一組Logstash節點可以使用 Kafka input 從主題中進行消費，以進一步轉換和豐富正在傳輸的數據。
1.16.彈性和恢復（Resiliency and Recovery）
當Logstash從Kafka消耗時，應啓用持久隊列，並將添加傳輸彈性，以減輕Logstash節點故障期間進行重新處理的需要。 在這種情況下，建議使用默認的持久隊列磁盤分配大小 queue.max_bytes: 1GB。
如果將Kafka配置爲保留較長時間的數據，則在災難恢復和調和的情況下，可以從Kafka重新處理數據。
1.17.其他消息隊列集成
儘管不需要額外的排隊層，但Logstash可以使用無數其他消息排隊技術，例如RabbitMQ和Redis。 它還支持從諸如 Pub/Sub, Kinesis和 SQS的託管排隊服務中提取。