本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
無服務器架構中的日誌處理會遇到諸多挑戰，讓我們就此作一番探究，同時也瞭解 ELK Stack（使用 Kinesis Firehose）是如何解決這些問題的。
在我們以前的文章中，有一篇內容是關於 NASA 同一艘飛船進行通訊聯繫的，那艘飛船被派往火星，主要任務是研究和探測火星的氣候、大氣以及行星表面。最後，NASA 宣佈與那艘火星氣候探測飛船失去聯繫，而在此前的24 小時中，NASA 的工程師們曾想盡辦法聯繫一個早已不存在的對象。
在無服務器架構運行模式下，函數及其容器在數秒鐘內便完成開啓和關閉，除非能及時捕捉，否則和上面提到的例子相似，我們將不可挽回地丟失其確定和不確定的狀態以及其它信息。
無服務器架構促使開發人員編寫出快速、獨立和可執行的代碼，這些代碼由事件觸發並駐留在臨時容器內。不過，如果其中某一個函數未能如期運行會出現什麼情況？DevOps團隊人員如何確認相應事件是否激活了對應的函數？
在無服務器應用程序中，各服務趨於小型化且分工精確，這讓追根溯源變得異常複雜。在查找故障源時，相關服務和這些服務的集成點可能根本不存在。當操作涉及超過一個函數時，查找故障源就像在黑夜中尋找獵物一般困難。
要查看無服務器應用程序的運行情況，以及故障時會發生什麼，最重要的就是記錄日誌。
1.爲什麼需要進行無服務器日誌處理？
對開發人員來說，日誌的必要性是顯而易見的，但具體到無服務器架構日誌記錄，仍有一些特殊情況需要考慮。
顯然，當數個函數發生故障導致其無法提供所請求的功能時，爲了能分析不同函數的日誌，日誌中必須包含事務唯一識別符，只有這樣才能方便地發現和彙集事務。在無服務器應用程序內，相同的日誌必須包含參與操作的所有函數的更多信息，包括響應值和運行次數。
如果一項函數在運行期間發生崩潰，其實例和容器在崩潰後也不復存在，那麼崩潰日誌記錄對於瞭解問題所在至關重要。現在的關鍵是，我們如何記錄下崩潰日誌，我們又如何從一項業已失效的函數中得到這些日誌呢？這就要求我們具備創造型思維。
有種值得注意的解決方案，即創建一個函數，它在另一項函數崩潰時會被觸發，或者從根本上說，它與其他各函數是關聯的。該函數負責收集容器中的所有信息，包括崩潰前的所有記錄，由基礎架構引發的事件可以觸發該函數，而且通過配置可使其能夠觸發崩潰函數的另一個實例。利用這種方法，在無人工干預的情況下，通過對故障的及時響應和恢復，日誌可以由無服務器應用程序實現自我維護。
無服務器日誌在應用程序檢查中還具有其它重要作用。當雲應用程序遭到惡意軟件或者黑客攻擊時，利用日誌可以輕而易舉地檢查服務負載、識別濫用服務的企圖。在無服務器環境中，服務執行不但很短暫，而且它也將自動伸縮作爲其目標，因此識別和處理上述攻擊活動便成爲一項現實的挑戰。在攻擊發生時，良好的規劃、專業的日誌記錄以及合適的分析工具，可以識別出攻擊類型，同時找出正在遭受攻擊的函數並對其採取恰當的保護措施。
無服務器架構會面臨另一個軟件方面的重大問題——即無狀態。有時各項函數的存續的時間僅爲幾秒鐘，因其容器狀態無法得以保留，從而造成在後續調用相同函數時，該函數無法訪問之前運行的數據。對於這個問題，有一些不同的解決方案，其中有些方案要求集成外部工具，而另一些則要求實現一個專門設計的無服務器框架。
日誌則可以相當輕鬆地解決這一問題。集中備份的函數日誌起到了存儲介質的作用，可以授權函數訪問此前的運行數據，如果不這樣處理，這些數據本來是要被丟棄的。函數可以基於先前的事件對應用程序狀態作出評估，而非僅僅基於應用程序的當前狀態。
2.那麼，應該如何在無服務器環境下記錄日誌呢？
通常，應用程序服務日誌存放在其容器的本地磁盤內。當基於雲的應用程序增長擴容之後，訪問、管理和分析這些日誌會是一件相當複雜的工作。如果不使用合適的工具，要遍歷保存在幾百臺服務器上的數百份日誌文件，來搜尋某個特定的錯誤，其困難可想而知。
所以一般需要使用基於文件複製或者 syslog 的技術，來制定中心化日誌解決方案。在無服務器架構中，日誌必須存放於中心服務器，以便於在函數和容器關閉後還能夠保存並分析其數據。
以 AWS Lambda 爲例，作爲一套中心化的日誌管理解決方案，ELK Stack用於採集和分析函數日誌。ELK Stack（Elasticsearch、Logstash 和Kibana）不僅使DevOps團隊具備了採集、儲存和分析日誌的能力，還可以據此構造出視圖或者數字儀表盤，以突出顯示重要信息，來爲函數實現及功能提供決策上的依據。
由於能夠提供清晰的應用程序狀態視圖，並能協助有關人員對相關故障點進行追根溯源，ELK Stack中的三大組件在許多 IT 組織得到了廣泛應用。
2015 年歲末，AWS 推出了一項名爲 Kinesis Firehose 的數據採集和傳輸解決方案，該方案允許用戶從應用程序內的所有日誌中採集數據，並將這些數據傳輸至 Amazon S3 或者 Redshift。
Elasticsearch 爲原始數據建立索引並對這些數據進行分析，用戶藉此可以查詢到任何重要的業務信息。Kibana 根據預定義的規則，將結果直觀地呈現給用戶，因此組織內的不同團隊可以獲得生產環境所需的特定視圖。
在無服務器架構中，一套基礎 EKK（Elasticsearch、Kibana 和 Kinesis）Stack 應該如下圖所示：
作爲替代方案，如果您不希望管理AWS 上的 Elasticsearch 和Kibana，可將Kinesis Firehose 構造的日誌流傳輸到 Logz.io 的S3服務，實現Kinesis Firehose 同諸如 Logz.io 的這樣的託管式 ELK 解決方案的結合。該項解決方案可向您提供全套的管理服務，您則無需關心Elasticsearch 伸縮、解析函數日誌或者 保護Kibana 安全等管理任務。
3.結論
儘管減少了維護工作量、實現了可伸縮性規劃、降低了服務器管理成本，但在調查系統故障、查找故障原因中引入無服務器應用程序，對於研發人員和運維開發人員來說仍是一項新挑戰。日誌顯示了各函數和其容器的功能和二者間的關係。我們必須利用各種專用工具才能將所有信息從生產環境傳輸至研發團隊，以幫助他們完成維護任務。
必須將無服務器日誌的採集和對分析工具的流傳輸當作函數執行的一部分，只有這樣我們才能在容器關閉後不會丟失數據。鑑於無服務器架構鼓勵快速執行，日誌採集任務也必須隨之做到迅速及時。很多無服務器開源框架（主要是 AWS Lambda，也包括 Azure Functions）都深知這種複雜性，因此它們都帶有日誌採集解決方案。儘管如此，以上方案均不夠簡單，所以在無服務器構架中的日誌處理技術依舊任重而道遠。
原文鏈接：https://logz.io/blog/logging-serverless-architecture/
關於作者
丹尼爾·伯曼（Daniel Berman）是Logz.io的產品傳播者。他熱衷於日誌分析、大數據、雲計算、家庭，愛好跑步、利物浦足球俱樂部，以及寫寫關於顛覆性高科技東西的文章。在推特上@proudboffin關注他。
他的推特地址是：https://twitter.com/proudboffin
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
