本文獲文章做者受權翻譯，轉載須要註明來自公衆號EAWORLD。安全
做者：Daniel Berman服務器
譯者：海松微信
原標題：Logging in a Serverless Architecture架構
無服務器架構中的日誌處理會遇到諸多挑戰，讓咱們就此做一番探究，同時也瞭解 ELK Stack（使用 Kinesis Firehose）是如何解決這些問題的。框架
在咱們之前的文章中，有一篇內容是關於 NASA 同一艘飛船進行通信聯繫的，那艘飛船被派往火星，主要任務是研究和探測火星的氣候、大氣以及行星表面。最後，NASA 宣佈與那艘火星氣候探測飛船失去聯繫，而在此前的24 小時中，NASA 的工程師們曾想盡辦法聯繫一個早已不存在的對象。less
在無服務器架構運行模式下，函數及其容器在數秒鐘內便完成開啓和關閉，除非能及時捕捉，不然和上面提到的例子類似，咱們將不可挽回地丟失其肯定和不肯定的狀態以及其它信息。運維
無服務器架構促使開發人員編寫出快速、獨立和可執行的代碼，這些代碼由事件觸發並駐留在臨時容器內。不過，若是其中某一個函數未能如期運行會出現什麼狀況？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，長按二維碼關注
8月-9月，PWorld系列技術趴還將繼續上演。目前，9月24日將在上海舉行PWorld MeetUP「微服務的編排、配置與12要素專場」已啓動報名，戳「閱讀原文」可直達報名頁面，並瞭解更多詳情~
PWorld軟件架構&平臺創新大會：由普元發起主辦的全國頂級技術盛會，探討「數字化時代的企業軟件變化與創新」推動中國企業在數字化時代的成功轉型，積極爲CTO、CIO、架構師、技術經理、開發工程師等技術相關人員設計各項議題，演講嘉賓從企業軟件、人工智能、區塊鏈、雲計算、大數據、業務流程、移動開發等熱門話題中，分享他們的技術看法和最佳實踐。同時，PWorld在企業級技術會議裏獨開「交互式體驗」先河、賦予參會者最大程度尊重，帶給現場以及線上的聽衆以全新的參會體驗。
本文分享自微信公衆號 - EAWorld（eaworld）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。