Graylog工作流程
Graylog 架構
Deep Workflow
工作流草圖
-
Log messages source & LB
基本上，可以接受任何機器的資料（結構化或非結構化），并使用喜歡的任何負載均衡器。 消息的數量，其峰值率，平均大小和提取将影響性能。
-
Transport Layer
這是Graylog伺服器上的輸入和日志。内部處理使用的Kafka的代碼。
-
Processing Chain
将這些消息取出并寫入程序緩沖區，這是一個環形的緩沖區。然後，程序緩沖處理器處理消息，其中發生流路由和提取字段。 這部分處理時，過濾後的消息然後進入輸出緩沖區（另一個環形緩沖區），然後進入輸出緩沖區處理器，然後進入Elasticsearch（ES）或使用者定義的輸出。（提示：調整每個緩沖區運作的處理器數量很重要，不應超過可用于graylog-server的CPU核心數量。增加處理器數量，如果您看到過低的吞吐量，并嘗試專注于處理緩沖區處理器，因為輸出緩沖區通常不需要很多。）
-
REST API
Web前端使用的API
-
MONGODB
它隻存儲中繼資料：所有項目的使用者，設定和配置資料：流，儀表闆，提取器等。您配置的一切内容。如果Mongo當機挂掉了，Graylog将繼續運作。是以，如過我們使用過程選擇将其納入高可用性設計。可以選擇 Mongo的HA場景 三個執行個體。關鍵詞Mongo Replication set。
-
Elasticsearch Cluster
這裡看起來像一個ES節點，并且了解每個ES伺服器的配置資料（索引，分片等）。對于HA，建議至少配置一個副本。
-
Anatomy of an Index（索引解析）
單個索引（在上圖中，Graylog Index＃25）被分解成碎片。這意味着索引被分解，部件在不同的ES節點上運作。這樣可以更快地進行搜尋，因為可以在多個ES節點上并行計算查詢結果。索引也可以配置副本。這意味着每個分片都被鏡像到其他節點，對于HA是非常好的。
-
Index Model
每個索引首次從0開始編号。在時間序列資料庫中，所有資料都以時間戳存儲，一旦存儲就不會被重寫（是以标記為READ_ONLY對于WRITE_ACTIVE表現）。是以，消息不會被重新插入。這使的它很快。由于基于時間的存儲，這也意味着當查詢時，必須給出時間限制搜尋（即在最後一小時内）。 （提示：是以這些索引的大小在性能調優時很重要。你不想使索引太大，因為搜尋将需要更長的時間，并且你不希望它們太短，因為同樣的原因。索引的大小應根據您擁有的資料量以及通常搜尋的程度而定。有時候，人們将它用于較長的曆史戰略類型搜尋。了解并确定尺寸是非常重要的。備注：ES叢集都會存在搜尋，索引太大導緻時間拉長。）
-
Deflector（變流裝置，我的了解就像nginx日志切割一樣，不會影響下一個檔案的寫入）
原作者寫入一個可以被原子性的切換到新索引的被稱為“Deflector / 偏轉器”的索引别名。這樣我們就不必擔心在建立新的索引時停止消息處理，因為這樣很容易被管理（如：索引＃25現在已經關閉了啊等等，接下來的一個是＃26，繼續寫）。
二、支援的消息輸入源
-
Syslog
支援RFC 5424和RFC 3164相容的syslog消息，TCP和UDP傳輸日志。另外，許多裝置，特别是路由器和防火牆，不發送符合RFC的syslog消息，這個時候不得不使用原始/純文字消息輸入的組合。
-
GELF / Sending from applications
Graylog擴充日志格式（GELF）是一種日志格式，可以避免經典的純系統日志的缺點，非常适合從應用層記錄。它具有可選的壓縮，分塊和最重要的是一個明确定義的結構。 也可以通過HTTP發送所有GELF類型，包括隻是純JSON字元串的未壓縮GELF。
-
Using Apache Kafka as transport queue
使用apache 的 Kafka 作為傳輸隊列。
-
Using RabbitMQ (AMQP) as transport queue
使用RabbitMQ 作為傳輸隊列
- Ruby on Rails 在Gemfile 檔案中添加以下内容
gem "gelf"
gem "lograge" -
Raw/Plaintext inputs
内置的原始/純文字輸入允許您解析可以通過TCP或UDP發送任何文本。 如果需要極高的靈活性，還可以編寫插件。
-
Reading from files
Collector Sidecar，它作為其他程式（如nxlog和Filebeats）的主管程序，這些程式專門用于從本地檔案收集日志消息并将其發送到像Graylog這樣的遠端系統。 也可以使用支援GELF或syslog協定（包括其他）的任何程式将您的日志發送到Graylog。
三、最小安裝架構
最小安裝（不推薦生産環境）
各元件功能：
- MongoDB 用于存儲配置元資訊和配置資料（無需太多硬體資源配置）
- Elasticsearch 用于存儲日志資料（記憶體大以及更高的磁盤IO）
- Graylog 用于讀取日志、展示日志。（CPU密集）
缺點：
- 系統無備援、容易出現單點故障，适合測試階段
四、大型生産環境架構
生産安裝
生産安裝部署參考連結相比最小架構來說，以下是變化部分：
- 客戶通路和日志源面對的是前端的LB，LB通過Graylog REST API 負載管理Graylog叢集
- Elasticsearch 使用叢集方案，多節點存儲資料，達到備份備援、負載的效應
- MongoDB 叢集，具備自動的容錯功能(auto-failover),自動恢複的(auto-recovery)的高可用
- 各元件友善伸縮擴充