關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn
【 Domain 1的組織複雜性設計（Design for Organizational Complexity）】——-理解CloudWatch Logs
Hello大家好，歡迎回來，我們今天的視頻課程內容是理解CloudWatch Logs，我們開始今天課程內容。
將日誌的內容集中存儲
無論我們的服務器運行着是windows還是linux操作系統，每個操作系統都會產生日誌文件。服務器可產生很多類型的日誌文件，如系統日誌、安全日誌，如果您的應用程序在系統中運行，可能還包括應用程序產生的日誌。
當應用程序遇到問題需要調試的時候， 就需要訪問日誌文件，一般會怎麼做呢？因爲日誌文件生成並存儲在服務器中，如果要調試應用程序，調查程序BUG，就需要訪問服務器。
讓我們舉個例子，假設有個php程序運行在linux服務器上，出於某種原因，這個php的應用程序沒有按照預期的情況正常運行，開發人員想要查看日誌文件，這時候該怎麼辦？在這個場景下很多組織都是爲開發人員分配了SSH權限，然後開發人員SSH服務器後查看日誌調試。
這當然不是一個很好的安全實踐，可能會造成不可控風險等。當前很多組織中，都會建立並遵循開發/部署流程和規範，並不會分配開發人員直接登錄生產環境的服務器權限，也就是說開發人員無法訪問服務器，那在這種情況下，開發人員怎麼通過服務器上的日誌文件進行調試排查問題呢？答案是集中式日誌存儲架構，將日誌文件從系統中拉取並放置一箇中心區域集中存儲，並提供給開發人員查看/調試。
將/var/log/messages日誌內容推送至cloudwatch日誌組快速演示
爲了讓大家更好的理解，我們下面在舉個例子。
切換到終端，我已登陸一臺東京的EC2，進入到系統的/var/log目錄，可以看到目錄裏面有很多日誌文件。
假設我們要使用/var/log/messages日誌來調試，一種方式是，像我現在這樣手動ssh登陸到這臺服務器上，然後通過tail、grep等命令，對messages日誌進行檢索並查看與排查問題相關的記錄，並定位問題。然而，前面討論過，最理想的方式是將這個文件推送到中心區域，然後在中心區域檢索日誌。
因爲我們這節課是CloudWatch logs內容，針對以上這個場景，我在EC2上安裝了CloudWatch logs代理，通過CloudWatch logs代理，將EC2中的messages日誌內容推送至cloudwatch 日誌組，然後可在cloudwatch日誌組中檢索日誌，我們已經將上述的環境和服務都配置好了，現在快速演示下。
我們現在打開cloudwatch控制檯，打開日誌組，我們會看到一個/var/log/messages日誌組，進入後是我之前登陸的EC2實例ID，然後可以看到剛剛登陸的那臺EC2中的/var/log/messages日誌所有內容，全部在這個日誌組裏面。
以上，我們只是拿messages日誌舉例，同樣，在實際環境中，您也可以推送所有服務器上的應用程序的日誌至一箇中央區域日誌服務器，這個中央區域日誌服務器可以是cloudwatch，可以是rsyslog，也可以是EasticSearch等等。最重要的一點是，當您將所有的日誌文件都推送到了一箇中央區域的日誌服務器後，在有調試BUG或者其他需要檢索日誌文件的時候，您就不需要分配服務器的ssh登陸權限給相應的人員，在登陸服務器查詢對應的日誌文件了。
以上，就是今天的CloudWatch logs的內容，在下節課我們將從頭開始配置，實現將一個ec2的日誌推送至CloudWatch的日誌組的整個操作步驟。
希望此係列教程能爲您通過 AWS解決方案架構師認證 Professional 認證考試帶來幫助，如您有任何疑問:
關注公衆號：AWS愛好者（iloveaws）
文 | 沉默惡魔（禁止轉載，轉載請先經過作者同意）
網站：www.iloveaws.cn
