一千萬個為什麽

搜索

在組織中實施和使用Elastic的最佳實踐是什麽?



目前有多個微服務登錄到單個文件。如果有問題,那麽該團隊正在調試像無頭雞。為了防止這種情況的出現,目的是引入綜合記錄,例如, elastic 。遷移到這種聚合日誌記錄系統的最佳實踐是什麽?

當前想法

應該配置什麽端點?

轉載註明原文: 在組織中實施和使用Elastic的最佳實踐是什麽?

一共有 1 個回答:

最好的做法是將所有內容記錄到同一位置。您的“當前想法”表明您將在本地運行Elastic堆棧,這對於本地開發環境非常有用,但對於您希望將所有微服務中的日誌傳送到相同位置以外的任何內容。這使您可以在日誌之間進行關聯,並為日誌記錄提供“單一窗格”方法。

為此,您將不得不在服務器上運行它,或使用托管服務(如Elastic Cloud或AWS Elasticsearch)。您可以通過軟件包管理器安裝組件,例如yum或apt, https://www.elastic.co/start ,或者也可以運行它在Docker中。 stack-docker 存儲庫非常適合在本地運行,但由於缺乏可伸縮性,它不適用於任何大規模部署。

您運送的端點將取決於您用於發送日誌的方法/協議,例如,在AWS EC2實例上運行的Nginx可能會使用Filebeat並將其發送到位於Elasticsearch之前的負載均衡器,或者如果您使用Docker,您可以使用gelf Docker logdriver將日誌發送到Logstash。

一些更好的實踐:

  • 以JSON記錄所有消息,重點關註對象/字段而不是長字符串消息。
  • 例外情況應該是可操作的,其他任何情況都可能是警告。
  • 避免多行日誌。
  • 使用關聯ID。如果您的應用通過了相關ID,則應該將其包含在由該調用觸發的每條消息中,否則應該生成一個。相關ID應包含在對其他微服務的調用中。
  • 在記錄數量多於而不是少的情況下,你永遠不知道你什麽時候可能需要那些數據,或者通過分析其他不明顯的數據來發現什麽趨勢。
  • 從邏輯上分離您的環境,以便您可以在日誌中擁有不同的保留期和歸檔。