原文: https://medium.com/adobetech/best-practices-for-serverless-observability-a99d8dc8af5c
WRITTEN BY
Ran Ribenzaft
Co-Founder & CTO @epsagon | AWS Serverless Hero | Entrepreneur, passionate about serverless and microservices.
翻譯：祝坤榮(時序)
現(xiàn)在看起來每個工程師都熟悉serverless這個詞，但離在生產(chǎn)環(huán)境大規(guī)模使用還很遠(yuǎn)蔫饰。意思是，實際上腾供，大部分人在使用serverless時還是沒有經(jīng)驗的，并且由于這個原因姊途，很多最佳實踐還是缺失的作谭。
在這篇文章里，我們會深入可觀察性鸳惯，它是每個工程和運維團(tuán)隊在移動到生產(chǎn)環(huán)境的核心組件。我們會討論每個重要的基礎(chǔ)：度量叠萍，日志和分布式追蹤芝发，并提供serverless在真實世界的最佳實踐的例子。
可觀察性中的度量
傳統(tǒng)簡單直接做監(jiān)控的套路就是去看度量數(shù)據(jù)苛谷。 度量辅鲸， 尤其是度量中體現(xiàn)的趨勢， 可以展示出我們系統(tǒng)的基本統(tǒng)計情況腹殿，比如：
? CPU或內(nèi)存的使用峰值
? 流量和請求的趨勢
? 我們使用的跨服務(wù)的延遲情況
Google SRE圖書中指出了監(jiān)控分布式系統(tǒng)的4個黃金指標(biāo)是延遲独悴，流量例书，錯誤和飽和度。盡管看起來很簡單刻炒，它仍然需要一些經(jīng)驗和時間來進(jìn)行正確的監(jiān)控决采。這個流程包括：
? 從環(huán)境，應(yīng)用坟奥，資源和服務(wù)上收集所有度量指標(biāo)织狐。這包括，比如筏勒，我們的k8s集群，云資源旺嬉，Java和Node.js應(yīng)用管行，我們的Redis集群。想要記錄這些度量信息每個實體都需要一套不同的處理方法邪媳。
? 將度量信息傳給一個統(tǒng)一平臺捐顷，它要處理正確的量級，聚合所有度量指標(biāo)雨效，展示正確的數(shù)據(jù)(比如迅涮，用百分位替代平均值)。
? 最終徽龟，我們需要為每個應(yīng)用或環(huán)境建一個儀表盤叮姑，并且為其中重要的定義合適的報警。
在serverless化后据悔，CPU和內(nèi)存變得不那么相關(guān)了传透；不要只盯著調(diào)用和錯誤的基本圖表。多看和觀察你的function有的每個動作极颓。你調(diào)用的任何API都需要被監(jiān)控朱盐。
可觀察性中的日志
度量指標(biāo)只能告訴我們’好或壞’。他們不會提供任何信息和一種方式來告訴我們?yōu)槭裁匆粋€應(yīng)用不工作了菠隆。
要定位問題的種類兵琳，我們需要理解我們代碼或服務(wù)的流程。要達(dá)到這個目的我們要打印包括所有從開始到詳細(xì)異常的日志(到一個文件骇径，socket或服務(wù))躯肌。
Elastic中的日志
每個工程師都熟悉定位問題或bug的場景和要找到正確日志時持續(xù)升高的壓力。這些問題都是由于日志的一些缺陷和固有的問題：
? 它們基本上是手動的破衔。日過你沒有記錄一些事情羡榴，它不會出現(xiàn)（然后你補(bǔ)了日志，部署你的代碼运敢，并且等著問題再次出現(xiàn)）校仑。
? 通常忠售，它們沒有上下文。這表示你要找到你想要找的日志迄沫，你需要對發(fā)生在你代碼或服務(wù)的事件的相關(guān)日志進(jìn)行搜索稻扬。
? 在眾多服務(wù)中有很多的日志，這很難在它們之間進(jìn)行導(dǎo)航羊瘩。
想要從日志中得到有效的信息：
? 在你的日志行中填加元數(shù)據(jù)泰佳；例如，服務(wù)/函數(shù)function名稱尘吗，場景逝她，請求ID等。
? 在你使用的代碼中自動化日志事件的處理睬捶。我們會在下面追蹤章節(jié)討論這個黔宛。
? 保證在你的服務(wù)中用正確的方式索引日志，然后你可以使用工具來進(jìn)行分析擒贸。使用工具分析日志(用元數(shù)據(jù)和維度)可以幫助你理解你應(yīng)用中的復(fù)雜趨勢臀晃。
? 記錄自定義的度量指標(biāo)。這也適用于之前的基礎(chǔ)指標(biāo)介劫，但它可以幫你發(fā)現(xiàn)業(yè)務(wù)核心指標(biāo)徽惋。比如，上周用戶注冊的數(shù)量座韵。
可觀察性中的分布式追蹤
追蹤是可觀察性中的重要基礎(chǔ)险绘，它在微服務(wù)和serverless中度量和日志中扮演重要角色。追蹤的目的是收集一次操作的數(shù)據(jù)誉碴，這樣我們可以在不同的服務(wù)中看到流程隆圆。
在一個運行微服務(wù)和serverless的現(xiàn)代應(yīng)用中，我們需要對追蹤的“分布式”部分有更多的關(guān)注翔烁。追蹤里最流行的標(biāo)準(zhǔn)是OpenTracing(或新的OpenTelemetry)渺氧。分布式追蹤描述了一個框架來收集關(guān)于事件的數(shù)據(jù)(比如，一個DB查詢蹬屹，我們會收集主機(jī)名侣背，表名，持續(xù)時間慨默，操作等)贩耐，這叫做spans與上下文。它也描述了在你的服務(wù)中注入和抽取“追蹤ID”厦取。
有效在代碼中抓取追蹤的一種推薦的方式是進(jìn)行增強(qiáng)instrument(https://epsagon.com/blog/instrumentation-for-better-monitoring-and-troubleshooting/)潮太，所以每個調(diào)用不需要手動。Instrumentation增強(qiáng)修改了一些調(diào)用；比如铡买，每次你調(diào)用HTTP更鲁，它會路由到一個中間件，由其保存追蹤信息奇钞。
由于追蹤是被一種結(jié)構(gòu)化的方式捕捉的澡为，它讓我們可以對日志問一些更有意思的問題；比如景埃，你可以查找所有“insert”操作超過300ms的事件媒至，其被打了一個特定customer ID的標(biāo)簽。
追蹤捕捉了結(jié)構(gòu)化數(shù)據(jù)
要牢記以下幾個關(guān)鍵問題：
? 增強(qiáng)和追蹤你的應(yīng)用是一個非常長的過程谷徙，需要長時間維護(hù)拒啰。如果你選擇自己實現(xiàn)不會快速獲勝。
? 我們只討論了追蹤收集的部分完慧。下一步是傳送它們到一些服務(wù)谋旦。Jaeger（https://www.jaegertracing.io/）可能是展現(xiàn)和搜索追蹤信息的主流服務(wù)。
如果要從追蹤中得到最大的收獲：
? 用標(biāo)簽來充實你的追蹤骗随。標(biāo)簽讓你們可以在你的復(fù)雜系統(tǒng)中精確定位事件，按維度進(jìn)行分析赴叹，比如鸿染，userId=X的一個特定事件有多少次，用了多久乞巧。好的標(biāo)簽可以是user ID涨椒，商品ID，事件類型绽媒，或任何你系統(tǒng)中特定的信息蚕冬。
? 因為追蹤給日志加入了上下文所以它在問題定位中扮演了核心組件。要做到那樣是辕，請考慮下載追蹤里記錄payload囤热。比如，每一個對DB的調(diào)用获三，增加查詢信息旁蔼；每一個HTTP調(diào)用，填加request/reponse的header和body信息疙教。
? 要在沒有任何上下文信息里在成噸的日志或圖表里搜索是很難的棺聊。通過使用追蹤你可以可視化這些在你系統(tǒng)中的復(fù)雜服務(wù)和事務(wù)。
可視化追蹤和payload信息是一個故障排查的強(qiáng)大工具（Epsagon）
總結(jié)
可觀察性在每個現(xiàn)代應(yīng)用中扮演了很重要的部分贞谓。它需要很多規(guī)劃限佩，繁重的維護(hù)來應(yīng)用最佳實踐。將每個基礎(chǔ)部分分離到不同的工具可以讓工程團(tuán)隊有很大的生產(chǎn)力，強(qiáng)化他們的合作祟同。當(dāng)選擇一個工具來整合一切事物時這很重要作喘。
另外，自動化你的流程以便它們不會對日常工程的工作流產(chǎn)生影響很重要耐亏。選一個受控的解決方案可以有很大的優(yōu)勢徊都，就像你從云供應(yīng)商選擇數(shù)據(jù)庫，消息隊列广辰，或服務(wù)器暇矫。
在Epsagon(https://epsagon.com/)，我們在建立一個針對serverless和微服務(wù)的追蹤和監(jiān)控的定制方案择吊。你過你有興趣可以聯(lián)系我們李根。
本文來自祝坤榮(時序)的微信公眾號「麥芽面包，id「darkjune_think」
轉(zhuǎn)載請注明几睛。
交流Email: zhukunrong@yeah.net
