容器從根本上改變了我們運(yùn)行應(yīng)用程序的方式。組織不再將應(yīng)用程序作為長期運(yùn)行的服務(wù)運(yùn)行，而是作為臨時(shí)進(jìn)程運(yùn)行。容器的配置速度使組織能夠比以往更快地?cái)U(kuò)展、優(yōu)化資源消耗和更新應(yīng)用程序。一個(gè)典型的Kubernetes容器只持續(xù)一天，而一個(gè)典型的AWS Lambda容器只持續(xù)大約一小時(shí)。
容器的動態(tài)性和短暫性也影響了其可觀測性。可觀測性是DevOps過程的關(guān)鍵部分，但與更傳統(tǒng)的單體應(yīng)用程序相比，容器增加了獨(dú)特的挑戰(zhàn)。
在本文中，筆者將解釋這些挑戰(zhàn)是什么，以及DevOps團(tuán)隊(duì)可以做些什么來簡化向基于容器的體系結(jié)構(gòu)的過渡。
容器可觀測性的復(fù)雜性
在我們深入研究容器的壽命之前，筆者將首先解釋從容器中收集可觀測數(shù)據(jù)的挑戰(zhàn)。有幾種方法，包括一些內(nèi)置到容器運(yùn)行時(shí)和編排工具（如Docker和Kubernetes）中的方法。其中包括：
——將專用監(jiān)控代理部署為主機(jī)應(yīng)用程序或容器。
——部署日志路由器以自動收集容器生成的日志。
——使用Docker日志驅(qū)動程序?qū)⑷萜魅罩敬鎯Φ街鳈C(jī)。
——通過docker stats、Kubernetes metrics管道或類似的API收集指標(biāo)。
然而，這些方法也存在風(fēng)險(xiǎn)。企業(yè)微服務(wù)部署可能涉及跨越許多云平臺的數(shù)百、數(shù)千、甚至數(shù)萬臺主機(jī)。不僅應(yīng)用程序不再連續(xù)運(yùn)行，而且在部署應(yīng)用程序之前，團(tuán)隊(duì)不再確定哪個(gè)主機(jī)將運(yùn)行該應(yīng)用程序。一個(gè)應(yīng)用程序也可能同時(shí)運(yùn)行多個(gè)實(shí)例，因此當(dāng)出現(xiàn)問題時(shí)，很難知道在哪里查找。由于容器是短暫的，因此寫入容器文件系統(tǒng)的任何數(shù)據(jù)都將隨容器一起刪除，除非可以將其傳輸?shù)街鳈C(jī)。這也意味著不再保證工程師能夠交互地對正在運(yùn)行的容器進(jìn)行故障排除，因?yàn)樗赡茉诠こ處煷蜷_會話之前已被刪除。
此外，主機(jī)本身也可能是短暫的。Kubernetes Cluster Autoscaler、Google Kubernetes Engine和Amazon Elastic Kubernetes Service等工具可以自動添加或刪除主機(jī)以滿足需求的更改，這可能導(dǎo)致寫入主機(jī)文件系統(tǒng)的任何文件的數(shù)據(jù)丟失。與更傳統(tǒng)的單體應(yīng)用程序相比，部署環(huán)境在應(yīng)用程序的整個(gè)生命周期中保持相對一致。在傳統(tǒng)的環(huán)境中，DevOps團(tuán)隊(duì)可以在主機(jī)上安裝一個(gè)監(jiān)控代理，直接將數(shù)據(jù)從應(yīng)用程序記錄到主機(jī)的文件系統(tǒng)，甚至可以登錄到主機(jī)環(huán)境來收集信息或解決問題。對于容器，這幾乎是不可能的任務(wù)。這就是為什么用單體的思維方式來考慮容器的可觀測性不僅是自欺欺人的，而且是危險(xiǎn)的。
在基于容器的架構(gòu)中實(shí)現(xiàn)可觀測性時(shí)，團(tuán)隊(duì)需要關(guān)注兩個(gè)關(guān)鍵目標(biāo)：
——從容器和主機(jī)收集和集中可觀測性數(shù)據(jù)。
——在整個(gè)應(yīng)用程序而不是單個(gè)容器的上下文中測量可觀測性數(shù)據(jù)。
接下來，筆者將解釋這些目標(biāo)的含義以及如何實(shí)現(xiàn)它們。
可觀測性數(shù)據(jù)的采集與集中
如前所述，容器和主機(jī)是短暫的：它們可以隨時(shí)啟動、停止和遷移。因此，容器和主機(jī)生成的任何可觀測數(shù)據(jù)都應(yīng)發(fā)送到持久性收集和存儲服務(wù)。
在這種情況下，像LogDNA這樣的第三方服務(wù)是一個(gè)理想的解決方案，因?yàn)樗鼈兲峁┝艘粋€(gè)專用、快速和可靠的平臺，用于接收大量數(shù)據(jù)。例如，LogDNA聚合并解析傳入的日志數(shù)據(jù)，以便工程師可以立即對其進(jìn)行搜索、篩選和分析。這消除了工程師遠(yuǎn)程登錄應(yīng)用程序環(huán)境的需要，并確保即使原始容器或主機(jī)被破壞，可觀測性數(shù)據(jù)始終可用。
通過元數(shù)據(jù)實(shí)現(xiàn)上下文化
與單體不同，容器只是大型應(yīng)用程序的一小部分。雖然從單個(gè)容器收集可觀測性數(shù)據(jù)很重要，但是在整個(gè)應(yīng)用程序的上下文中查看時(shí)，這些數(shù)據(jù)會變得非常有用。
例如，假設(shè)你有一個(gè)三層web應(yīng)用程序，每層都作為單獨(dú)的容器運(yùn)行?，F(xiàn)在想象一下，你的后端層突然開始生成錯誤，容器因此崩潰。從單個(gè)容器中提取日志和指標(biāo)有助于進(jìn)行根本原因分析，但這無助于在整個(gè)應(yīng)用程序的上下文中看到錯誤。該問題可能是特定于容器的，也可能表示更廣泛的、應(yīng)用程序范圍內(nèi)的問題。
這與短暫性有什么關(guān)系？在收集可觀測性數(shù)據(jù)時(shí)，你收集的數(shù)據(jù)應(yīng)標(biāo)識容器提供的服務(wù)，而不是容器本身。例如，LogDNA代理自動用容器名和鏡像名標(biāo)記每個(gè)容器日志。Kubernetes代理通過包含Pod名稱、節(jié)點(diǎn)和Kubernetes名稱空間，以及其他有用的元數(shù)據(jù)來擴(kuò)展它。這允許你在容器、Kubernetes服務(wù)或部署的所有實(shí)例中搜索和篩選日志。擁有這種級別的上下文對于分布式跟蹤特別重要，但它適用于所有形式的可觀測數(shù)據(jù)。
如何有效處理短暫性？
像LogDNA這樣的托管監(jiān)視服務(wù)是收集、上下文化和訪問可觀測性數(shù)據(jù)的最簡單和最有效的解決方案之一。使用LogDNA，你可以部署一個(gè)代理，只需兩個(gè)命令就可以從整個(gè)Kubernetes集群收集日志。LogDNA代理除了收集容器日志之外還收集主機(jī)日志，為你提供應(yīng)用程序和基礎(chǔ)設(shè)施的整體視圖。而且，因?yàn)榇硎亲鳛槭刈o(hù)程序部署的，它會隨著你的基礎(chǔ)設(shè)施自動擴(kuò)展。
原文鏈接：
https://thenewstack.io/how-container-lifespan-affects-observability/
