原文: https://medium.com/adobetech/...WRITTEN BY數據庫
Ran Ribenzaft服務器
Co-Founder & CTO @epsagon | AWS Serverless Hero | Entrepreneur, passionate about serverless and microservices.微信
翻譯:祝坤榮(時序)框架
如今看起來每一個工程師都熟悉serverless這個詞,但離在生產環境大規模使用還很遠。意思是,實際上,大部分人在使用serverless時仍是沒有經驗的,而且因爲這個緣由,不少最佳實踐仍是缺失的。less
在這篇文章裏,咱們會深刻可觀察性,它是每一個工程和運維團隊在移動到生產環境的核心組件。咱們會討論每一個重要的基礎:度量,日誌和分佈式追蹤,並提供serverless在真實世界的最佳實踐的例子。運維
傳統簡單直接作監控的套路就是去看度量數據。 度量, 尤爲是度量中體現的趨勢, 能夠展現出咱們系統的基本統計狀況,好比:socket
• CPU或內存的使用峯值
• 流量和請求的趨勢
• 咱們使用的跨服務的延遲狀況
Google SRE圖書中指出了監控分佈式系統的4個黃金指標是延遲,流量,錯誤和飽和度。儘管看起來很簡單,它仍然須要一些經驗和時間來進行正確的監控。這個流程包括:分佈式
• 從環境,應用,資源和服務上收集全部度量指標。這包括,好比,咱們的k8s集羣,雲資源,Java和Node.js應用,咱們的Redis集羣。想要記錄這些度量信息每一個實體都須要一套不一樣的處理方法。
• 將度量信息傳給一個統一平臺,它要處理正確的量級,聚合全部度量指標,展現正確的數據(好比,用百分位替代平均值)。
• 最終,咱們須要爲每一個應用或環境建一個儀表盤,而且爲其中重要的定義合適的報警。函數
在serverless化後,CPU和內存變得不那麼相關了;不要只盯着調用和錯誤的基本圖表。多看和觀察你的function有的每一個動做。你調用的任何API都須要被監控。微服務
度量指標只能告訴咱們’好或壞’。他們不會提供任何信息和一種方式來告訴咱們爲何一個應用不工做了。
要定位問題的種類,咱們須要理解咱們代碼或服務的流程。要達到這個目的咱們要打印包括全部從開始到詳細異常的日誌(到一個文件,socket或服務)。
Elastic中的日誌
每一個工程師都熟悉定位問題或bug的場景和要找到正確日誌時持續升高的壓力。這些問題都是因爲日誌的一些缺陷和固有的問題:
• 它們基本上是手動的。日過你沒有記錄一些事情,它不會出現(而後你補了日誌,部署你的代碼,而且等着問題再次出現)。
• 一般,它們沒有上下文。這表示你要找到你想要找的日誌,你須要對發生在你代碼或服務的事件的相關日誌進行搜索。
• 在衆多服務中有不少的日誌,這很難在它們之間進行導航。
想要從日誌中獲得有效的信息:
• 在你的日誌行中填加元數據;例如,服務/函數function名稱,場景,請求ID等。
• 在你使用的代碼中自動化日誌事件的處理。咱們會在下面追蹤章節討論這個。
• 保證在你的服務中用正確的方式索引日誌,而後你可使用工具來進行分析。使用工具分析日誌(用元數據和維度)能夠幫助你理解你應用中的複雜趨勢。
• 記錄自定義的度量指標。這也適用於以前的基礎指標,但它能夠幫你發現業務核心指標。好比,上週用戶註冊的數量。
追蹤是可觀察性中的重要基礎,它在微服務和serverless中度量和日誌中扮演重要角色。追蹤的目的是收集一次操做的數據,這樣咱們能夠在不一樣的服務中看到流程。
在一個運行微服務和serverless的現代應用中,咱們須要對追蹤的「分佈式」部分有更多的關注。追蹤裏最流行的標準是OpenTracing(或新的OpenTelemetry)。分佈式追蹤描述了一個框架來收集關於事件的數據(好比,一個DB查詢,咱們會收集主機名,表名,持續時間,操做等),這叫作spans與上下文。它也描述了在你的服務中注入和抽取「追蹤ID」。
有效在代碼中抓取追蹤的一種推薦的方式是進行加強instrument(https://epsagon.com/blog/inst...,因此每一個調用不須要手動。Instrumentation加強修改了一些調用;好比,每次你調用HTTP,它會路由到一箇中間件,由其保存追蹤信息。
因爲追蹤是被一種結構化的方式捕捉的,它讓咱們能夠對日誌問一些更有意思的問題;好比,你能夠查找全部「insert」操做超過300ms的事件,其被打了一個特定customer ID的標籤。
追蹤捕捉告終構化數據
要牢記如下幾個關鍵問題:
• 加強和追蹤你的應用是一個很是長的過程,須要長時間維護。若是你選擇本身實現不會快速獲勝。
• 咱們只討論了追蹤收集的部分。下一步是傳送它們到一些服務。Jaeger(https://www.jaegertracing.io/)多是展示和搜索追蹤信息的主流服務。
若是要從追蹤中獲得最大的收穫:
• 用標籤來充實你的追蹤。標籤讓大家能夠在你的複雜系統中精肯定位事件,按維度進行分析,好比,userId=X的一個特定事件有多少次,用了多久。好的標籤能夠是user ID,商品ID,事件類型,或任何你係統中特定的信息。
• 由於追蹤給日誌加入了上下文因此它在問題定位中扮演了核心組件。要作到那樣,請考慮下載追蹤裏記錄payload。好比,每個對DB的調用,增長查詢信息;每個HTTP調用,填加request/reponse的header和body信息。
• 要在沒有任何上下文信息裏在成噸的日誌或圖表裏搜索是很難的。經過使用追蹤你能夠可視化這些在你係統中的複雜服務和事務。
可視化追蹤和payload信息是一個故障排查的強大工具(Epsagon)
可觀察性在每一個現代應用中扮演了很重要的部分。它須要不少規劃,繁重的維護來應用最佳實踐。將每一個基礎部分分離到不一樣的工具可讓工程團隊有很大的生產力,強化他們的合做。當選擇一個工具來整合一切事物時這很重要。
另外,自動化你的流程以便它們不會對平常工程的工做流產生影響很重要。選一個受控的解決方案能夠有很大的優點,就像你從雲供應商選擇數據庫,消息隊列,或服務器。
在Epsagon(https://epsagon.com/),咱們在創建一個針對serverless和微服務的追蹤和監控的定製方案。你過你有興趣能夠聯繫咱們。
本文來自祝坤榮(時序)的微信公衆號「麥芽麪包,id「darkjune_think」
轉載請註明。微信掃一掃關注公衆號。
交流Email: zhukunrong@yeah.net