雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
以前，日誌管理相對簡單。日誌的數量，類型和結構都很簡單且易於管理。
但是，在過去的幾年中，所有這些簡單性都沒有出現。由於向雲原生技術（例如，松耦合服務，微服務架構以及容器和Kubernetes等技術）的轉移，過去的日誌管理策略已不再足夠。在雲原生世界中成功管理日誌需要對日誌的聚合，分析等方式進行根本性的更改。
這就是雲原生革命如何改變了日誌管理的本質，以及IT和DevOps團隊可以做什麼以繼續有效地管理日誌。
是什麼使雲原生日誌記錄與衆不同？
乍一看，雲原生環境中的日誌管理似乎與常規日誌記錄沒有什麼不同。雲原生基礎架構和應用程序仍會生成日誌，並且日誌管理流程的基本步驟（收集，聚合，分析和輪換）仍然適用。
但是，如果您開始嘗試監視雲本機環境，那麼很快就會很清楚，要有效地管理日誌要困難得多。原因有四個。
1.更多日誌
首先，最簡單的是要處理更多的日誌。
在雲原生時代之前，大多數應用程序都是運行在單個服務器上的整體組件。每個應用程序通常僅生成一個日誌（如果它甚至完全創建了自己的日誌；有時，應用程序會將數據記錄到Syslog中）。每個服務器通常還只生成少量日誌，其中主要是Syslog和auth。因此，要管理整個環境的日誌，您只需要處理幾個日誌。
相比之下，在雲原生環境中，您通常使用微服務體系結構-可能有十幾個或更多不同的服務在運行，每個服務都提供了組成整個應用程序所需的不同功能。每個微服務都可以生成自己的日誌。
不僅如此，還有更多的基礎架構層；因此，通過擴展，更多的日誌。您不僅具有基礎主機服務器及其生成的日誌，而且還具有位於應用程序和基礎架構之間的抽象層（如Docker或Kubernetes或兩者，取決於您的使用方式）創建的日誌。
簡而言之，向雲本機的轉變意味着IT團隊已經從爭奪支持的每個應用程序的少數幾個單獨日誌的競爭發展到十幾個甚至更多。
2.更多日誌類型
總體上不僅有更多的日誌，而且還有更多類型的日誌。您不僅擁有服務器日誌和應用程序日誌，還擁有云基礎架構的日誌，Kubernetes或Docker的日誌，身份驗證日誌，Windows和Linux的日誌（因爲現在更常見的是在同一操作系統中同時使用兩種類型的操作系統）商店）等等。
這種多樣性增加了複雜性，這不僅是因爲要管理的日誌數據類型更多，而且還因爲這些日誌類型的格式經常不同。結果，使用正則表達式匹配或其他類型的通用查詢一次解析所有日誌變得更加困難。
3.多樣化的記錄架構
隨着日誌數量和類型的增加，現在在應用程序環境中公開日誌數據的方式變得更加複雜和變化。
Kubernetes是一個很好的例子。Kubernetes提供了一些內置功能，可以在節點級別收集日誌。進行收集的確切方式取決於環境變量。例如，它在安裝了systemd的系統上記錄日誌，但是直接寫入/ var / log中的.log文件。
使事情變得更加複雜的是，Kubernetes沒有對集羣級日誌的本地支持，儘管同樣可以使用多種方法。您可以使用在每個Kubernetes節點上運行的日誌記錄代理來爲集羣生成日誌數據，也可以在sidecar容器中運行日誌記錄代理。或者，您可以嘗試直接從應用程序生成集羣範圍的日誌數據，前提是您的集羣體系結構和應用程序使此操作切實可行。
最重要的是，即使在同一平臺內，日誌記錄體系結構的設置方式也存在很大差異。結果，在雲原生環境中設計統一的日誌管理流程變得越來越困難，該流程可以在需要支持的所有應用程序或平臺上一致地工作。
4.非永久性日誌存儲
雲本機日誌記錄的最後一個挑戰來自以下事實：某些雲本機應用程序缺少持久性數據存儲。容器就是最好的例子。
當容器實例停止運行時，存儲在容器中的所有數據將被永久銷燬。因此，如果日誌數據存儲在容器內（默認情況下通常是默認情況下），它將與容器一起消失。由於容器是短暫的，實例會暫停並被刪除，而新實例會自動旋轉，因此並不是在容器關閉之前詢問管理員是否要保存日誌數據。它將關閉並被刪除，並隨同您的日誌數據一起使用，除非您事先將該數據移到了其他地方。
如果您只關心實時處理日誌數據，那麼這種瞬態可能還可以。但是，如果您需要在一段時間內保持歷史日誌可用，那麼在容器停止運行時丟失日誌數據是不可接受的。
雲原生日誌管理的最佳準則
爲了應對在雲原生環境中遭遇的這些挑戰，團隊可以使用以下準則。
1.統一日誌收集和彙總
要使用多種不同類型的日誌格式和架構來支持和記憶，嘗試分別管理每個系統的日誌是不可行的。而是實施統一的集中式日誌管理解決方案，該解決方案可自動從環境的所有部分收集數據並將其聚合到一個位置。
2.採用靈活的日誌管理解決方案
您的日誌管理工具和流程應該能夠支持任何類型的環境，而無需重新配置環境。例如，如果您有一個Kubernetes集羣以一種方式公開日誌數據，而另一個集羣以另一種方式進行日誌記錄，則您應該能夠從這兩個集羣中收集和分析日誌，而不必更改任何一個集羣的處理方式。日誌。同樣，如果您有一個應用程序在一個公共雲上運行，而另一個應用程序在另一雲上運行，則不必爲了從一箇中央位置管理其日誌而修改任何一個雲環境的默認日誌記錄行爲。
3.實時收集日誌
確保沒有持久存儲的環境中的日誌不會消失的一種方法是實時收集日誌數據並將其聚集在一個獨立的位置。這樣，日誌數據一出生就將保存在持久性日誌管理器中，即使容器關閉也將保持可用。與嘗試僅在固定時間段內從容器內部收集日誌數據相比，此方法更爲可取，如果容器比您預期的更早關閉，則可能會丟失一些日誌。
4.使用自定義日誌解析器
除了忽略以常規分析工具無法支持的方式構造的日誌之外，還可以利用自定義日誌解析器來處理任何格式的數據。這樣，您就不會冒從非標準日誌中遺漏重要見解的風險。
結論
雲本機日誌管理從根本上不同於管理常規整體應用程序的日誌數據。不僅日誌數據的規模有所增加（儘管有所增加），而且在記錄，結構化和公開日誌數據的方式上還存在更大的多樣性。面對這些挑戰，有效地管理日誌需要一個日誌管理解決方案，該解決方案必須完全集中和統一來自您支持的所有系統的日誌數據，同時還提供從非標準日誌類型中獲取見解的能力。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK
原文發佈時間：2020-06-15
本文作者：雨果的書房
本文來自：“dockone”，瞭解相關信息可以關注“dockone”