以前，日志管理相對簡單。日志的數(shù)量，類型和結構都很簡單且易于管理。

但是，在過去的幾年中，所有這些簡單性都沒有出現(xiàn)。由于向云原生技術(例如，松耦合服務，微服務架構以及容器和Kubernetes等技術)的轉移，過去的日志管理策略已不再足夠。在云原生世界中成功管理日志需要對日志的聚合，分析等方式進行根本性的更改。

這就是云原生革命如何改變了日志管理的本質，以及IT和DevOps團隊可以做什么以繼續(xù)有效地管理日志。

[[330310]]

是什么使云原生日志記錄與眾不同

乍一看，云原生環(huán)境中的日志管理似乎與常規(guī)日志記錄沒有什么不同。云原生基礎架構和應用程序仍會生成日志，并且日志管理流程的基本步驟(收集，聚合，分析和輪換)仍然適用。

但是，如果您開始嘗試監(jiān)視云本機環(huán)境，那么很快就會很清楚，要有效地管理日志要困難得多。原因有四個。

1.更多日志

首先，最簡單的是要處理更多的日志。

在云原生時代之前，大多數(shù)應用程序都是運行在單個服務器上的整體組件。每個應用程序通常僅生成一個日志(如果它甚至完全創(chuàng)建了自己的日志;有時，應用程序會將數(shù)據記錄到Syslog中)。每個服務器通常還只生成少量日志，其中主要是Syslog和auth。因此，要管理整個環(huán)境的日志，您只需要處理幾個日志。

相比之下，在云原生環(huán)境中，您通常使用微服務體系結構-可能有十幾個或更多不同的服務在運行，每個服務都提供了組成整個應用程序所需的不同功能。每個微服務都可以生成自己的日志。

不僅如此，還有更多的基礎架構層;因此，通過擴展，更多的日志。您不僅具有基礎主機服務器及其生成的日志，而且還具有位于應用程序和基礎架構之間的抽象層(如Docker或Kubernetes或兩者，取決于您的使用方式)創(chuàng)建的日志。

簡而言之，向云本機的轉變意味著IT團隊已經從爭奪支持的每個應用程序的少數(shù)幾個單獨日志的競爭發(fā)展到十幾個甚至更多。

2.更多日志類型

總體上不僅有更多的日志，而且還有更多類型的日志。您不僅擁有服務器日志和應用程序日志，還擁有云基礎架構的日志，Kubernetes或Docker的日志，身份驗證日志，Windows和Linux的日志(因為現(xiàn)在更常見的是在同一操作系統(tǒng)中同時使用兩種類型的操作系統(tǒng))商店)等等。

這種多樣性增加了復雜性，這不僅是因為要管理的日志數(shù)據類型更多，而且還因為這些日志類型的格式經常不同。結果，使用正則表達式匹配或其他類型的通用查詢一次解析所有日志變得更加困難。

3.多樣化的記錄架構

隨著日志數(shù)量和類型的增加，現(xiàn)在在應用程序環(huán)境中公開日志數(shù)據的方式變得更加復雜和變化。

Kubernetes是一個很好的例子。Kubernetes提供了一些內置功能，可以在節(jié)點級別收集日志。進行收集的確切方式取決于環(huán)境變量。例如，它在安裝了systemd的系統(tǒng)上記錄日志，但是直接寫入/ var / log中的.log文件。

使事情變得更加復雜的是，Kubernetes沒有對集群級日志的本地支持，盡管同樣可以使用多種方法。您可以使用在每個Kubernetes節(jié)點上運行的日志記錄代理來為集群生成日志數(shù)據，也可以在sidecar容器中運行日志記錄代理?；蛘?，您可以嘗試直接從應用程序生成集群范圍的日志數(shù)據，前提是您的集群體系結構和應用程序使此操作切實可行。

最重要的是，即使在同一平臺內，日志記錄體系結構的設置方式也存在很大差異。結果，在云原生環(huán)境中設計統(tǒng)一的日志管理流程變得越來越困難，該流程可以在需要支持的所有應用程序或平臺上一致地工作。

4.非永久性日志存儲

云本機日志記錄的最后一個挑戰(zhàn)來自以下事實：某些云本機應用程序缺少持久性數(shù)據存儲。容器就是最好的例子。

當容器實例停止運行時，存儲在容器中的所有數(shù)據將被永久銷毀。因此，如果日志數(shù)據存儲在容器內(默認情況下通常是默認情況下)，它將與容器一起消失。由于容器是短暫的，實例會暫停并被刪除，而新實例會自動旋轉，因此并不是在容器關閉之前詢問管理員是否要保存日志數(shù)據。它將關閉并被刪除，并隨同您的日志數(shù)據一起使用，除非您事先將該數(shù)據移到了其他地方。

如果您只關心實時處理日志數(shù)據，那么這種瞬態(tài)可能還可以。但是，如果您需要在一段時間內保持歷史日志可用，那么在容器停止運行時丟失日志數(shù)據是不可接受的。

云原生日志管理的最佳準則

為了應對在云原生環(huán)境中遭遇的這些挑戰(zhàn)，團隊可以使用以下準則。

1.統(tǒng)一日志收集和匯總

要使用多種不同類型的日志格式和架構來支持和記憶，嘗試分別管理每個系統(tǒng)的日志是不可行的。而是實施統(tǒng)一的集中式日志管理解決方案，該解決方案可自動從環(huán)境的所有部分收集數(shù)據并將其聚合到一個位置。

2.采用靈活的日志管理解決方案

您的日志管理工具和流程應該能夠支持任何類型的環(huán)境，而無需重新配置環(huán)境。例如，如果您有一個Kubernetes集群以一種方式公開日志數(shù)據，而另一個集群以另一種方式進行日志記錄，則您應該能夠從這兩個集群中收集和分析日志，而不必更改任何一個集群的處理方式。日志。同樣，如果您有一個應用程序在一個公共云上運行，而另一個應用程序在另一云上運行，則不必為了從一個中央位置管理其日志而修改任何一個云環(huán)境的默認日志記錄行為。

3.實時收集日志

確保沒有持久存儲的環(huán)境中的日志不會消失的一種方法是實時收集日志數(shù)據并將其聚集在一個獨立的位置。這樣，日志數(shù)據一出生就將保存在持久性日志管理器中，即使容器關閉也將保持可用。與嘗試僅在固定時間段內從容器內部收集日志數(shù)據相比，此方法更為可取，如果容器比您預期的更早關閉，則可能會丟失一些日志。

4.使用自定義日志解析器

除了忽略以常規(guī)分析工具無法支持的方式構造的日志之外，還可以利用自定義日志解析器來處理任何格式的數(shù)據。這樣，您就不會冒從非標準日志中遺漏重要見解的風險。

結論

云本機日志管理從根本上不同于管理常規(guī)整體應用程序的日志數(shù)據。不僅日志數(shù)據的規(guī)模有所增加(盡管有所增加)，而且在記錄，結構化和公開日志數(shù)據的方式上還存在更大的多樣性。面對這些挑戰(zhàn)，有效地管理日志需要一個日志管理解決方案，該解決方案必須完全集中和統(tǒng)一來自您支持的所有系統(tǒng)的日志數(shù)據，同時還提供從非標準日志類型中獲取見解的能力。