日誌是系統的重要組成部分，讓您了解它是否按預期工作（或不工作）。 在微服務架構的條件下，使用日誌成為特殊奧林匹克競賽的一個單獨學科。 有很多問題需要解決：
- 如何從應用程序寫入日誌；
- 在哪裡寫日誌；
- 如何傳送日誌進行存儲和處理；
- 如何處理和存儲日誌。
當前流行的容器化技術的使用在問題解決選項領域的耙子之上添加了沙子。
這就是 Yuri Bushmelev 的報告抄本“收集和運送原木領域的耙圖”
誰管，請貓下。
我叫尤里·布什梅列夫。 我為 Lazada 工作。 今天我將談談我們如何製作日誌、如何收集日誌以及我們在其中寫入的內容。
我們來自哪裡？ 我們是誰？ Lazada 是東南亞六個國家排名第一的在線零售商。 所有這些國家都分佈在數據中心之間。 現在總共有 1 個數據中心。為什麼這很重要？ 因為有些決定是由於中心之間的聯繫非常薄弱。 我們有一個微服務架構。 我驚訝地發現我們已經有 4 個微服務了。 當我用日誌開始任務時，只有 80 個日誌。另外，還有相當大的 PHP 遺留問題，我也不得不忍受和忍受。 目前，所有這些為我們生成了整個系統每分鐘超過 20 萬條消息。 此外，我將展示我們如何努力忍受這種情況，以及為什麼會這樣。
您必須以某種方式忍受這 6 萬條消息。 我們該怎麼辦？ 需要 6 萬條消息：
- 從應用程序發送
- 收貨
- 送去分析和儲存。
- 分析
- 以某種方式存儲。
當有三百萬條消息時，我的表情大致相同。 因為我們從一些便士開始。 很明顯，應用程序日誌寫在那裡。 例如，無法連接到數據庫，可以連接到數據庫，但無法讀取某些內容。 但除此之外，我們的每個微服務還寫入一個訪問日誌。 到達微服務的每個請求都會落入日誌中。 我們為什麼要這樣做呢？ 開發者希望能夠追踪。 每個訪問日誌都包含 traceid 字段，然後一個特殊的界面根據該字段展開整個鏈並精美地顯示跟踪。 跟踪顯示了請求是如何進行的，這有助於我們的開發人員更快地處理任何未知的垃圾。
如何忍受它？ 現在我將簡要描述選項域——這個問題通常是如何解決的。 如何解決日誌的採集、傳輸和存儲問題。
如何從應用程序中寫入？ 很明顯，有不同的方法。 尤其是有best practice，時尚同志告訴我們。 正如祖父所說，守舊派有兩種類型。 還有其他方法。
通過收集日誌，情況大致相同。 解決這個特定部分的選項並不多。 他們有更多，但還沒有那麼多。
但隨著交付和後續分析，變體的數量開始激增。 我現在不會描述每個選項。 我認為所有對該主題感興趣的人都知道主要選項。
我將向您展示我們在 Lazada 是如何做到的，以及這一切是如何開始的。
一年前，我來到Lazada，被派往日誌項目。 那裡是這樣的。 來自應用程序的日誌被寫入 stdout 和 stderr。 一切都以時尚的方式完成。 但隨後開發人員將其從標準流中刪除，然後基礎架構專家將以某種方式解決它。 在基礎設施專家和開發人員之間，也有發布者說：“呃……好吧，讓我們用 shell 將它們包裝在一個文件中，僅此而已。” 由於所有這些都在一個容器中，他們將其直接包裝在容器本身中，將目錄映射到內部並將其放在那裡。 我認為每個人都非常清楚發生了什麼。
讓我們看得更遠一點。 我們如何交付這些日誌。 有人選了td-agent，其實是fluentd但不是很fluentd。 我還是不明白這兩個項目的關係，不過好像是一回事。 這個用 Ruby 編寫的 fluentd 讀取日誌文件，使用一些正則表達式將它們解析為 JSON。 然後他們被送到卡夫卡。 此外，在 Kafka 中，每個 API 都有 4 個單獨的主題。 為什麼是4？ 因為有 live，所以有 staging，因為有 stdout 和 stderr。 開發人員生產它們，而基礎設施工作者必須在 Kafka 中創建它們。 而且，Kafka 是由另一個部門控制的。 因此，有必要創建一個工單，以便他們為每個 api 創建 4 個主題。 大家都忘記了。 總的來說，這是垃圾和廢物。
我們接下來用它做了什麼？ 我們把它發送到卡夫卡。 離 Kafka 更遠，一半的日誌飛到 Logstash。 另一半日誌是共享的。 有些飛到一個 Graylog，有些飛到另一個 Graylog。 結果，所有這些都飛到了一個 Elasticsearch 集群中。 也就是說，這一切亂七八糟的事情最後都落在那裡了。 你不必那樣做！
這是從上面看時的樣子。 你不必那樣做！ 在這裡，問題區域會立即用數字標記。 實際上還有更多，但有 6 個確實有問題，需要對其進行處理。 我現在將分別講述它們。
我們在這裡 (1,2,3) 寫入文件，因此，這裡同時有三個耙子。
第一個 (1) 是我們需要將它們寫在某個地方。 賦予 API 直接寫入文件的能力並不總是可取的。 最好將 API 隔離在一個容器中，最好是只讀的。 我是一名系統管理員，所以我對這些事情有稍微不同的看法。
第二點 (2,3) 是我們有很多請求進入 API。 API 將大量數據寫入文件。 文件越來越大。 我們需要旋轉它們。 因為否則您將無法在那裡保存任何光盤。 旋轉它們是不好的，因為它們通過 shell 重定向到一個目錄。 我們無法旋轉它。 您不能告訴應用程序重新打開句柄。 因為開發人員會像看傻子一樣看著你：“什麼描述符？ 我們通常寫入標準輸出。 框架將 copytruncate 轉換為 logrotate，它只是製作文件的副本和原始文件的主幹。 因此，在這些複製過程之間，磁盤空間通常會用完。
(4) 我們在不同的 API 中有不同的格式。 它們略有不同，但正則表達式必須以不同的方式編寫。 因為它全部由 Puppet 管理，所以有一大群類都有自己的蟑螂。 另外，td-agent 大部分時間都可以吞噬內存，變得愚蠢，他可以假裝自己在工作，什麼都不做。 從表面上看，不可能理解他什麼都不做。 充其量，他跌倒了，等會兒有人扶他起來。 更準確地說，警報會飛進來，有人會去用手舉起它。
(6) 最垃圾和浪費的是 elasticsearch。 因為是舊版本。 因為我們那時候沒有專門的師父。 我們有字段可能重疊的異構日誌。 不同應用的不同日誌可以寫入相同的字段名，但同時裡面可能有不同的數據。 也就是說，一個日誌在一個字段中帶有一個Integer，例如level。 另一個日誌在級別字段中帶有一個字符串。 在沒有靜態映射的情況下，竟然出現了這麼美妙的事情。 如果在索引輪換之後，帶有字符串的消息最先到達 elasticsearch，那麼我們就正常生活了。 如果第一個消息以 Integer 到達，則所有以 String 到達的後續消息都將被簡單地丟棄。 因為字段類型不匹配。
我們開始問這些問題。 我們決定不追究罪魁禍首。
但有些事情需要做！ 顯而易見的是，我們需要建立標準。 我們已經有了一些標準。 有些我們稍後帶來了。 幸運的是，當時已經批准了適用於所有 API 的單一日誌格式。 它直接寫入服務交互標準。 因此，那些想要接收日誌的人應該按照這種格式來寫。 如果有人不以這種格式寫日誌，那麼我們不做任何保證。
此外，我希望對記錄、傳送和收集日誌的方法有一個單一的標準。 實際上，在哪裡寫它們，以及如何傳遞它們。 理想情況是項目使用同一個庫。 Go 有一個單獨的日誌庫，PHP 有一個單獨的庫。 我們擁有的每個人，每個人都應該使用它們。 目前，我想說我們成功了 80%。 但有些人繼續吃仙人掌。
那裡（在幻燈片上）“用於日誌傳送的 SLA”才剛剛開始出現。 目前還沒有，但我們正在努力。 因為 infra 說如果你以這樣那樣的格式寫到某某地方並且每秒不超過 N 條消息，那麼我們很可能會把它傳遞到那裡，這很方便。 它消除了很多頭痛。 如果有 SLA，那就太好了！
我們是如何開始解決問題的？ 主要的抽成是 td-agent。 目前還不清楚我們的日誌去了哪裡。 他們送貨了嗎？ 他們要去嗎？ 他們到底在哪裡？ 因此，決定將td-agent替換為第一項。 我在這裡簡要概述了替換它的選項。
流利的。 首先，我在以前的工作中遇到過他，他也經常在那裡跌倒。 其次，這是相同的，只是在側面。
文件節拍。 這對我們有什麼好處？ 他在圍棋方面的事實，我們在圍棋方面擁有豐富的專業知識。 因此，如果有的話，我們可以以某種方式將它添加到我們自己身上。 這就是我們沒有接受它的原因。 這樣就不會有任何開始為自己重寫它的誘惑。
系統管理員的明顯解決方案是這個數量的各種系統日誌 (syslog-ng/rsyslog/nxlog)。
或者自己寫一些東西，但是我們丟棄了它，還有filebeat。 寫東西，不如寫對業務有用的東西。 交付日誌，最好拿現成的東西。
因此，選擇實際上歸結為在 syslog-ng 和 rsyslog 之間進行選擇。 我傾向於 rsyslog 只是因為我們已經在 Puppet 中有了 rsyslog 的類，而且我沒有發現它們之間有明顯的區別。 什麼是syslog，什麼是syslog。 是的，有些文檔更糟，有些更好。 他知道這種方式，而且他做的方式不同。
還有一些關於 rsyslog 的內容。 首先，它很酷，因為它有很多模塊。 它具有人類可讀的 RainerScript（現代配置語言）。 一個很棒的好處是我們可以用它的標準工具模擬 td-agent 的行為，並且應用程序沒有任何改變。 也就是說，我們將 td-agent 更改為 rsyslog，並且不要觸及其他所有內容。 我們立即得到了有效的交付。 接下來，mmnormalize 是 rsyslog 的一個很酷的地方。 它允許您解析日誌，但不能使用 Grok 和正則表達式。 它製作了一個抽象語法樹。 它解析日誌的方式與編譯器解析源代碼的方式大致相同。 這可以讓你工作得非常快，佔用很少的 CPU，而且，總的來說，這是一件非常酷的事情。 還有很多其他的獎金。 我不會詳述它們。
rsyslog 有很多缺點。 它們與獎金大致相同。 主要問題是你需要能煮，而且你需要選擇一個版本。
我們決定在 unix 套接字中寫入日誌。 而不是在 /dev/log 中，因為那裡有一堆系統日誌，所以在這個管道中有 journald。 因此，讓我們寫入自定義套接字。 我們會將其附加到一個單獨的規則集。 我們不要干涉任何事情。 一切都將是透明和可理解的。 所以我們確實做到了。 包含這些套接字的目錄被標準化並轉發給所有容器。 容器可以看到他們需要的套接字，打開並寫入它。
為什麼不是文件？ 因為大家都讀過 ，其中嘗試將文件轉發給docker，發現重啟rsyslog後，文件描述符發生變化，docker丟失了這個文件。 他一直打開別的東西，但不是他們寫的同一個套接字。 我們決定繞過這個問題，同時繞過阻塞問題。
Rsyslog 執行幻燈片上指示的操作並將日誌發送到中繼或 Kafka。 卡夫卡沿襲老路。 Rayleigh - 我嘗試使用純 rsyslog 來傳送日誌。 沒有 Message Queue，使用標準的 rsyslog 工具。 基本上，它有效。
但是稍後如何將它們填充到這部分 (Logstash/Graylog/ES) 中存在細微差別。 這部分（rsyslog-rsyslog）在數據中心之間使用。 這是一個壓縮的 tcp 鏈接，它允許您節省帶寬，因此，以某種方式增加我們在通道已滿時從另一個數據中心接收一些日誌的可能性。 因為我們有印度尼西亞，那裡的一切都很糟糕。 這就是持續存在的問題所在。
我們考慮了我們如何實際監控，我們從應用程序記錄的日誌達到那個目的的可能性有多大？ 我們決定開始度量。 Rsyslog 有自己的統計收集模塊，其中有某種計數器。 例如，它可以向您顯示隊列的大小，或者某項操作收到的消息數量。 你已經可以從他們那裡拿走一些東西了。 此外，它還具有您可以配置的自定義計數器，它會向您顯示某些 API 已記錄的消息數等信息。 接下來，我用 Python 編寫了 rsyslog_exporter，我們將其全部發送到 Prometheus 並進行了繪製。 我們真的想要 Graylog 指標，但到目前為止我們還沒有時間設置它們。
有什麼問題？ 問題出現了，因為我們發現（突然！）我們的 Live API 每秒寫入 50k 條消息。 這只是沒有暫存的 Live API。 而 Graylog 每秒只向我們顯示 12 條消息。 一個合理的問題出現了，殘餘物在哪裡？ 從中我們得出結論，Graylog 根本無法應對。 我們看了看，確實，帶有 Elasticsearch 的 Graylog 並沒有掌握這個流程。
接下來是我們在此過程中取得的其他發現。
寫入套接字被阻止。 它是怎麼發生的？ 當我使用 rsyslog 進行傳送時，在某些時候我們打破了數據中心之間的通道。 一個地方送貨起來，另一個地方送貨起來。 所有這一切都歸結為具有寫入 rsyslog 套接字的 API 的機器。 有一個隊列。 然後寫入 unix 套接字的隊列已滿，默認情況下為 128 個數據包。 應用程序塊中的下一個 write() 。 當我們查看我們在 Go 應用程序中使用的庫時，它是在非阻塞模式下寫入套接字的。 我們確信沒有任何東西被阻擋。 因為我們讀過 誰寫的。 但有那麼一刻。 圍繞此調用還有一個無限循環，其中不斷嘗試將消息推送到套接字中。 我們沒有註意到他。 我不得不重寫圖書館。 從那以後，它已經改變了幾次，但現在我們已經擺脫了所有子系統的鎖。 因此，您可以停止 rsyslog 並且什麼都不會下降。
有必要監控隊列的大小，這有助於避免踩到這個耙子。 首先，我們可以監控何時開始丟失消息。 其次，我們可以監控到我們基本上在交付方面存在問題。
還有一個不愉快的時刻——在微服務架構中放大 10 倍非常容易。 我們沒有那麼多傳入請求，但由於這些消息沿著圖表進一步運行，由於訪問日誌，我們實際上將日誌的負載增加了大約十倍。 不幸的是，我沒有時間計算確切的數字，但微服務就是這樣。 必須牢記這一點。 事實證明，目前日誌收集子系統是 Lazada 中負載最多的。
如何解決彈性搜索問題？ 如果您需要在一個地方快速獲取日誌，以免跨所有機器運行並在那裡收集它們，請使用文件存儲。 這保證有效。 它是從任何服務器完成的。 您只需要將磁盤放在那裡並放置系統日誌。 之後，您可以保證將所有日誌放在一個地方。 然後就可以慢慢配置elasticsearch，graylog什麼的了。 但是您將已經擁有所有日誌，而且，只要有足夠的磁盤陣列，您就可以存儲它們。
在我提交報告時，該方案開始看起來像這樣。 我們實際上停止了寫入文件。 現在，我們很可能會關閉殘留物。 在運行 API 的本地機器上，我們將停止寫入文件。 首先是文件存儲，效果很好。 其次，這些機器不斷地耗盡空間，你需要不斷地監控它。
這部分與 Logstash 和 Graylog 一起，它真的飆升了。 因此，您需要擺脫它。 你必須選擇一個。
我們決定放棄 Logstash 和 Kibana。 因為我們有一個安全部門。 有什麼聯繫？ 連接是沒有 X-Pack 和沒有 Shield 的 Kibana 不允許您區分對日誌的訪問權限。 因此，他們選擇了 Graylog。 它擁有一切。 我不喜歡它，但它有效。 我們購買了新硬件，在那里安裝了一個新的 Graylog，並將所有具有嚴格格式的日誌移動到一個單獨的 Graylog。 我們有組織地解決了同一領域的不同類型的問題。
新的 Graylog 中究竟包含什麼。 我們只是在 docker 中編寫了所有內容。 我們使用了一堆服務器，推出了三個 Kafka 實例，7 個 Graylog 服務器版本 2.3（因為我想要 Elasticsearch 版本 5）。 所有這些都是在 HDD 的突襲中提出的。 我們看到索引速度高達每秒 100 萬條消息。 我們看到了每週 140 TB 數據的數字。
又是一個耙子！ 我們有兩個銷售即將到來。 我們已經超過 6 萬個帖子。 我們 Graylog 沒有時間咀嚼。 你必須以某種方式再次生存。
我們就是這樣活下來的。 添加了更多的服務器和 SSD。 此刻我們就是這樣生活的。 現在我們已經每秒處理 160k 條消息。 我們還沒有達到極限，所以目前還不清楚我們實際上可以從中得到多少。
這些是我們對未來的計劃。 其中，實際上，最重要的可能是高可用性。 我們還沒有。 幾輛車的設置方式相同，但到目前為止一切都通過一輛車。 有必要花時間在它們之間建立故障轉移。
從 Graylog 收集指標。
制定一個速率限制，這樣我們就有了一個瘋狂的 API，它不會耗盡我們的帶寬和其他一切。
最後，與開發人員簽署某種 SLA，這樣我們就可以提供那麼多服務。 如果你寫多了，那就抱歉了。
並編寫文檔。
簡而言之，我們所經歷的一切的結果。 第一，標準。 其次，系統日誌是蛋糕。 第三，rsyslog 的工作方式與幻燈片上寫的完全一樣。 讓我們開始回答問題。
問題.
問題：他們為什麼決定不採取...（filebeat？）
回答: 需要寫入文件。 我真的不想。 當您的 API 每秒寫入數千條消息時，即使您每小時輪換一次，這仍然不是一個選項。 您可以寫入管道。 開發人員問我：“如果我們編寫的過程發生故障會怎樣”？ 我只是不知道該回答他們什麼，然後說：“好吧，我們不要那樣做。”
問題: 你為什麼不把日誌寫到HDFS？
回答A：這是下一步。 我們一開始就考慮過它，但由於目前沒有資源來處理它，所以它掛在我們的長期解決方案中。
問題: 列格式會更合適。
回答： 我明白。 我們雙手“為”。
問題: 你寫到rsyslog。 那裡可以使用 TCP 和 UDP。 但是如果是 UDP，那麼你如何保證交付？
回答答：有兩點。 首先我馬上告訴大家，我們不保證日誌的投遞。 因為當開發人員過來說：“讓我們開始在那裡寫財務數據，你會把它放在某個地方以防萬一，”我們回答他們，“太棒了！ 讓我們開始阻塞寫入套接字，並在事務中執行，這樣您就可以保證為我們將它放入套接字並確保我們從另一端收到它。 而這一刻，所有人頓時變得多餘了。 如果沒有，那麼我們有什麼問題？ 如果您不想保證寫入套接字，那麼我們為什麼要保證交付？ 我們正在盡最大努力。 我們確實盡力提供盡可能多和最好的服務，但我們不提供 100% 的保證。 因此，您不需要在那裡寫入財務數據。 為此有事務數據庫。
問題: 當 API 生成一些消息到日誌並將控制權轉移到微服務時，您是否遇到過來自不同微服務的消息到達順序錯誤的問題？ 因此，混亂出現了。
回答A：它們以不同的順序出現是正常的。 你必須為此做好準備。 因為任何網絡交付都不能保證給你訂單，或者你需要為此花費專門的資源。 如果我們採用文件存儲，那麼每個 API 都會將日誌保存到自己的文件中。 相反，rsyslog 將它們分解到那裡的目錄中。 每個 API 都有自己的日誌，你可以去那裡查看，然後你可以使用這個日誌中的時間戳來比較它們。 如果他們去查看 Graylog，那麼他們將按時間戳排序。 那裡一切都會好起來的。
問題: 時間戳可能會以毫秒為單位變化。
回答: 時間戳是API自己生成的。 事實上，這就是重點。 我們有 NTP。 API 會在消息本身中生成一個時間戳。 它不是由 rsyslog 添加的。
問題: 數據中心之間的交互不是很清楚。 在數據中心的框架內，日誌是如何收集和處理的，一目了然。 數據中心之間的交互如何？ 還是每個數據中心都有自己的生活？
回答： 幾乎。 我們讓每個國家都位於一個數據中心。 我們目前沒有spreading，所以一個國家放在不同的數據中心。 因此，沒有必要將它們結合起來。 每個中心內都有一個日誌中繼。 這是一個 Rsyslog 服務器。 其實就是兩台管理機。 它們的設置方式相同。 但就目前而言，流量僅通過其中之一。 她記錄所有聚合。 它有一個磁盤隊列以防萬一。 她按下日誌並將它們發送到中央數據中心（新加坡），在那裡它們已經在 Graylog 中被毒化了。 每個數據中心都有自己的文件存儲。 萬一我們失去連接，我們有所有的日誌。 他們會留在那裡。 它們將存儲在那裡。
問題: 在異常情況下你從那裡獲取日誌嗎？
回答: 你可以去那裡（到文件存儲）看看。
問題: 你如何監控你不丟失日誌？
回答：我們實際上正在失去他們，我們正在監視它。 一個月前開始監測。 Go API 使用的庫有指標。 她可以數出她有多少次寫入套接字失敗。 目前有一個棘手的啟發式方法。 那裡有一個緩衝區。 它嘗試將消息從它寫入套接字。 如果緩衝區溢出，它就會開始丟棄它們。 他數著他掉了多少。 如果那裡的計數器開始溢出，我們就會知道。 他們現在也來prometheus了，大家可以在Grafana中看圖。 您可以設置警報。 但目前尚不清楚將它們發送給誰。
問題: 在 elasticsearch 中，您存儲冗餘日誌。 你有多少個複製品？
回答: 一個副本。
問題: 是只有一行嗎？
回答: 這是主和副本。 數據以雙份形式存儲。
問題：您是否以某種方式調整了 rsyslog 緩衝區的大小？
回答：我們將數據報寫入自定義 unix 套接字。 這立即對我們施加了 128 KB 的限制。 我們不能再往裡面寫了。 我們已將此寫入標準。 誰想進入存儲，他們寫入 128 KB。 此外，圖書館會切斷信息並放置一個標誌，表明消息已被切斷。 我們在消息本身的標準中有一個特殊的字段，它顯示它是否在錄製過程中被切斷。 所以我們才有機會追踪這一刻。
問題: 你寫的 JSON 有問題嗎？
回答: 損壞的 JSON 將在中繼期間被丟棄，因為數據包太大。 否則 Graylog 將被丟棄，因為它將無法解析 JSON。 但是這裡有一些細微差別需要修復，它們主要與 rsyslog 相關。 我已經在那裡填寫了一些問題，這些問題仍然需要解決。
問題: 為什麼是卡夫卡？ 你試過 RabbitMQ 嗎？ Graylog 在這樣的負載下不加起來？
回答：它不適用於 Graylog。 Graylog 正在成形。 對他來說真的是個問題。 他有點東西。 而且，事實上，它是不需要的。 我寧願從 rsyslog 直接寫到 elasticsearch，然後看 Kibana。 但是我們需要和保安解決這個問題。 這是我們扔掉 Graylog 而使用 Kibana 時的一種可能的開髮變體。 Logstash 將沒有意義。 因為我可以用 rsyslog 做同樣的事情。 它有一個模塊可以寫入 elasticsearch。 有了 Graylog，我們正試圖以某種方式生活。 我們甚至稍微調整了一下。 但仍有改進的餘地。
關於卡夫卡。 歷史上就是這樣發生的。 當我到達時，它已經在那裡，並且已經在向它寫入日誌。 我們剛剛提升了我們的集群並將日誌移入其中。 我們管理他，我們知道他的感受。 至於 RabbitMQ……我們在使用 RabbitMQ 時遇到了麻煩。 而 RabbitMQ 正在為我們開發。 我們在生產中使用它，但它存在問題。 現在，在出售之前，他將被薩滿化，然後開始正常工作。 但在此之前，我還沒有準備好將其投入生產。 還有一點。 Graylog可以讀取AMQP 0.9版本，rsyslog可以寫入AMQP 1.0版本。 並且沒有一個解決方案可以在中間做到這兩點。 有一個或另一個。 所以現在只有卡夫卡。 但也有細微差別。 因為我們使用的 rsyslog 版本的 omkafka 可能會丟失它從 rsyslog 中獲取的整個消息緩衝區。 只要我們忍受它。
問題: 你使用 Kafka 是因為你有它嗎？ 不用於任何其他目的？
回答: Kafka，數據科學團隊使用的。 這是一個完全獨立的項目，不幸的是，我對此無能為力。 我不知道。 她由數據科學團隊管理。 當日誌啟動時，他們決定使用它，以免放置自己的日誌。 現在我們更新了Graylog，我們失去了兼容性，因為有一個舊版本的Kafka。 我們必須自己做。 同時，我們為每個 API 去掉了這四個主題。 我們為所有現場製作了一個寬頂，為所有舞台製作了一個寬頂，我們就在那裡拍攝所有東西。 Graylog 並行處理所有這些。
問題：為什麼我們需要這種帶插座的薩滿教？ 您是否嘗試過將 syslog 日誌驅動程序用於容器。
回答: 在我們問這個問題的時候，我們和docker的關係很緊張。 它是 docker 1.0 或 0.9。 Docker 本身很奇怪。 其次，如果您也將日誌推送到其中……我有一個未經證實的懷疑，即它通過 docker 守護進程通過自身傳遞所有日誌。 如果我們有一個 API 變得瘋狂，那麼其餘的 API 將遇到無法發送 stdout 和 stderr 的事實。 我不知道這會導致什麼。 我懷疑在這個地方沒有必要使用docker syslog驅動程序。 我們的功能測試部門有自己的帶有日誌的 Graylog 集群。 他們使用 docker 日誌驅動程序，那裡的一切似乎都很好。 但是他們立即將 GELF 寫入 Graylog。 在我們開始這一切的那一刻，我們需要它正常工作。 也許以後有人來，說它已經正常工作一百年了，我們就試試。
問題：您使用 rsyslog 在數據中心之間傳送。 為什麼不在卡夫卡？
回答: 我們這樣做，這就是它的真實情況。 有兩個原因。 如果通道完全死了，那麼我們所有的日誌，即使是壓縮形式，也不會爬過它。 而 kafka 讓他們在這個過程中簡單地失去了。 這樣，我們就擺脫了這些原木的粘連。 在這種情況下，我們只是直接使用 Kafka。 如果我們有一個好的頻道並且想要釋放它，那麼我們使用他們的 rsyslog。 但實際上，您可以對其進行設置，使其丟棄未通過的內容。 目前，我們只是在某個地方直接使用 rsyslog 交付，在 Kafka 的某個地方。
來源： www.habr.com