開發與維運

Serverless可觀察性的最佳實踐

原文: 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.

翻譯:祝坤榮(時序)

現在看起來每個工程師都熟悉serverless這個詞,但離在生產環境大規模使用還很遠。意思是,實際上,大部分人在使用serverless時還是沒有經驗的,並且由於這個原因,很多最佳實踐還是缺失的。

在這篇文章裡,我們會深入可觀察性,它是每個工程和運維團隊在移動到生產環境的核心組件。我們會討論每個重要的基礎:度量,日誌和分佈式追蹤,並提供serverless在真實世界的最佳實踐的例子。

image.png

可觀察性中的度量

傳統簡單直接做監控的套路就是去看度量數據。 度量, 尤其是度量中體現的趨勢, 可以展示出我們系統的基本統計情況,比如:

• CPU或內存的使用峰值
• 流量和請求的趨勢
• 我們使用的跨服務的延遲情況
image.png
Google SRE圖書中指出了監控分佈式系統的4個黃金指標是延遲,流量,錯誤和飽和度。儘管看起來很簡單,它仍然需要一些經驗和時間來進行正確的監控。這個流程包括:

• 從環境,應用,資源和服務上收集所有度量指標。這包括,比如,我們的k8s集群,雲資源,Java和Node.js應用,我們的Redis集群。想要記錄這些度量信息每個實體都需要一套不同的處理方法。
• 將度量信息傳給一個統一平臺,它要處理正確的量級,聚合所有度量指標,展示正確的數據(比如,用百分位替代平均值)。
• 最終,我們需要為每個應用或環境建一個儀表盤,並且為其中重要的定義合適的報警。

在serverless化後,CPU和內存變得不那麼相關了;不要只盯著調用和錯誤的基本圖表。多看和觀察你的function有的每個動作。你調用的任何API都需要被監控。

可觀察性中的日誌

度量指標只能告訴我們’好或壞’。他們不會提供任何信息和一種方式來告訴我們為什麼一個應用不工作了。

要定位問題的種類,我們需要理解我們代碼或服務的流程。要達到這個目的我們要打印包括所有從開始到詳細異常的日誌(到一個文件,socket或服務)。

image.png
Elastic中的日誌

每個工程師都熟悉定位問題或bug的場景和要找到正確日誌時持續升高的壓力。這些問題都是由於日誌的一些缺陷和固有的問題:

• 它們基本上是手動的。日過你沒有記錄一些事情,它不會出現(然後你補了日誌,部署你的代碼,並且等著問題再次出現)。
• 通常,它們沒有上下文。這表示你要找到你想要找的日誌,你需要對發生在你代碼或服務的事件的相關日誌進行搜索。
• 在眾多服務中有很多的日誌,這很難在它們之間進行導航。

想要從日誌中得到有效的信息:

• 在你的日誌行中填加元數據;例如,服務/函數function名稱,場景,請求ID等。
• 在你使用的代碼中自動化日誌事件的處理。我們會在下面追蹤章節討論這個。
• 保證在你的服務中用正確的方式索引日誌,然後你可以使用工具來進行分析。使用工具分析日誌(用元數據和維度)可以幫助你理解你應用中的複雜趨勢。
• 記錄自定義的度量指標。這也適用於之前的基礎指標,但它可以幫你發現業務核心指標。比如,上週用戶註冊的數量。

可觀察性中的分佈式追蹤

追蹤是可觀察性中的重要基礎,它在微服務和serverless中度量和日誌中扮演重要角色。追蹤的目的是收集一次操作的數據,這樣我們可以在不同的服務中看到流程。
image.png

在一個運行微服務和serverless的現代應用中,我們需要對追蹤的“分佈式”部分有更多的關注。追蹤裡最流行的標準是OpenTracing(或新的OpenTelemetry)。分佈式追蹤描述了一個框架來收集關於事件的數據(比如,一個DB查詢,我們會收集主機名,表名,持續時間,操作等),這叫做spans與上下文。它也描述了在你的服務中注入和抽取“追蹤ID”。

有效在代碼中抓取追蹤的一種推薦的方式是進行增強instrument(https://epsagon.com/blog/instrumentation-for-better-monitoring-and-troubleshooting/),所以每個調用不需要手動。Instrumentation增強修改了一些調用;比如,每次你調用HTTP,它會路由到一箇中間件,由其保存追蹤信息。

由於追蹤是被一種結構化的方式捕捉的,它讓我們可以對日誌問一些更有意思的問題;比如,你可以查找所有“insert”操作超過300ms的事件,其被打了一個特定customer ID的標籤。

image.png

                    追蹤捕捉了結構化數據

要牢記以下幾個關鍵問題:
• 增強和追蹤你的應用是一個非常長的過程,需要長時間維護。如果你選擇自己實現不會快速獲勝。
• 我們只討論了追蹤收集的部分。下一步是傳送它們到一些服務。Jaeger(https://www.jaegertracing.io/)可能是展現和搜索追蹤信息的主流服務。
如果要從追蹤中得到最大的收穫:
• 用標籤來充實你的追蹤。標籤讓你們可以在你的複雜系統中精確定位事件,按維度進行分析,比如,userId=X的一個特定事件有多少次,用了多久。好的標籤可以是user ID,商品ID,事件類型,或任何你係統中特定的信息。
• 因為追蹤給日誌加入了上下文所以它在問題定位中扮演了核心組件。要做到那樣,請考慮下載追蹤裡記錄payload。比如,每一個對DB的調用,增加查詢信息;每一個HTTP調用,填加request/reponse的header和body信息。
• 要在沒有任何上下文信息裡在成噸的日誌或圖表裡搜索是很難的。通過使用追蹤你可以可視化這些在你係統中的複雜服務和事務。

image.png
可視化追蹤和payload信息是一個故障排查的強大工具(Epsagon)

總結

可觀察性在每個現代應用中扮演了很重要的部分。它需要很多規劃,繁重的維護來應用最佳實踐。將每個基礎部分分離到不同的工具可以讓工程團隊有很大的生產力,強化他們的合作。當選擇一個工具來整合一切事物時這很重要。

另外,自動化你的流程以便它們不會對日常工程的工作流產生影響很重要。選一個受控的解決方案可以有很大的優勢,就像你從雲供應商選擇數據庫,消息隊列,或服務器。

在Epsagon(https://epsagon.com/),我們在建立一個針對serverless和微服務的追蹤和監控的定製方案。你過你有興趣可以聯繫我們。

Leave a Reply

Your email address will not be published. Required fields are marked *