上一篇介紹了 API 伺服器異常連線攀升的事件中，一些初步的調查和分析。同時也否定了最初的猜測，但也得到了另一個切入點。
在這一篇中，我們將從個切入點出現，繼續探究事件的成因並分享後續的處理方法。
首先，既然是連線數量的攀升，那是誰對我們的 ALB 進行連線呢？這當然會需要諮詢對這個專案比較熟悉的其它開發或架構師才能知道，但我們也可以直接翻出 ALB 的日誌來確認。
幸運的是，我們針對主要服務的 ALB ，都有啟動日誌的功能，因此找到放在 S3 的 ALB 的日誌之後，就可以試著從裡面獲得一些異常資訊。
這邊也可以分享給讀者 AWS 的文件，有關閱讀 ALB 日誌的方式：https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-log-entry-syntax
第一次閱讀日誌，滿有可能與筆者一樣直接迷失在浩瀚的字海之中。因此這邊，筆者也想簡單分享一下日誌的閱讀方式。
首先，一份日誌檔案中會包含好幾筆的日誌，每一條日誌都會佔據一行的數量。而每一條日誌裡面的資訊都會以空格的方式來區分彼此。比如以下的格式：
h2 2023-07-07T18:51:30.584030Z abc-alb
h2 2023-07-07T18:52:31.584030Z xxx-alb
h2 2023-07-07T18:55:22.584030Z abc-alb
在以上這份日誌檔案中，共包含了三筆日誌，而每一筆日誌都分別包含三個資訊(以空隔區分)。以第一筆日誌為例它所包含的三個資訊分別是「h2」、「2023-07-07T18:51:30.584030Z」、「abc-alb」。
而我們要怎麼知道這3個資訊分別代表什麼意思呢？這時候我們就會需要透過 AWS 的文件來理解這些資訊各自的意思。比如說，在 ALB 的日誌中，第一個欄位是請求或連線的模式，而「h2」是代表透過 TLS 連線的 HTTP/2 。只要按照文件提供的順序來拆解日誌，就可以理解這些資訊各自的意思了。如下圖：
從上圖中可以看到，實際上 Load Balancer 的日誌非常多，在我上面的舉例中，其實只有拿出日誌的前三個資訊來做範例而已。但無論日誌有多長，只要按照文件一步一步拆解，要理解其內容絕不困難。
由於不方便將實際的日誌分享給讀者，但透過日誌的內容，確實發現了一些看起來比較異常的地方。看起來異常的日誌主要有以下兩種：
當然實際上的資訊是非常雜亂的，不過在觀察到似乎有以上的現象之後，我們似乎又可以開始講出一個有邏輯的故事：
「某個來自 Android 平台的服務，在針對某些特定或不特定的 API endpoint 的送出請求時，可能會因為不明原因而導致連線數量增加。在連線數量增加的情況下，伺服器開始無法負荷後續的請求，進一步增加回應的速度或無法回應，因此接續發生一連串 503 的回應。」
從這裡開始，我們大致上可以判斷，這應該是程式面上的問題了。這可能會是 Client (Android) 端的問題，也可能是 A-API 自己的問題。但無論是何者，接下來就主要會是開發工程師的工作了。 SRE 這邊所能做的事情，就是如實把調查到的結果與日誌呈現給產品經理與開發工程師，交由他們進行後續的處理與改善。
在這個事件中，筆者算是第一次認真地閱讀並理解日誌，也算是一個非常新奇的體驗。
不過最重要還是想與讀者分享在整個問題排查過程中的分析方式。根據一開始所獲得的警報來猜測事件的可能成因，並透過實際獲得的資訊來證實猜測的真實性。在否定猜測之後，透過更為細節的日誌進一步推測事件成因。
事實上，雖然日誌分析的結果是程式面的問題，但這個猜測一樣有可能在之後的調查過程中被否證。雖然日誌的分析結果一般會有更高的真實性，但因為後續的調查並沒有 SRE 能夠介入的空間，因此也只能等待其它開發工程師的研究結果了。
另外一個也值得分享給讀者的是， SRE 除了將調查後的結果呈現給其它權責單位之外，也可以作為維運的權責單位來追蹤後續的改善進度。特別是在警報頻繁或嚴重影響系統可用性的情況下，能夠將系統的風險說明給產品經理理解，協助他們調度工程師的資源，筆者認為，這也算是是 SRE 的責任或價值所在呢。
P0 事件發生的當下，常常伴隨著一連串警報的出現，在當下如何正確判讀警報，會是 SRE 一個相當重要的技能。但反過來說，如何正確設計警報，讓值班人員在事件當下有比較良好的判斷依據，也是一個值得探究的事情。
因此接續著嚴重 P0 事件系列，接下來會是一篇與警報改善的分享。
iThome鐵人賽
看影片追技術