GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗，希望大家不管是喜歡或是有意見，都可以回饋給我們，讓我們有機會和大家對話並一起成長！
若有任何問題請來信：gss_crm@gss.com.tw
過去我們安裝部署了 Web Application 之後，除非發生問題，很少主動去仔細觀察應用程式紀錄了什麼，主要是因為內容太多，又沒有很好的介面。ELK（ElasticSearch、LogStash、Kibana）在這議題上可以給予一些幫助。例如，統一彙整之後，不必再各伺服器、各檔案目錄下，開啟各種雜亂的（有的超大，有的切很多，格式也不太統一）記錄檔。只要統一在瀏覽器中捲動、篩選，比較容易看，也比較能找到我們想要的資訊。
在一次觀察中，我們發現了一個重複出現的模式如下：
- [nginx][access] 172.16.78.90 - "GET /cas HTTP 1.1" 301 647
- [nginx][access] 172.16.78.90 - "GET /cas/ HTTP 1.1" 302 0
- [nginx][access] 172.16.78.90 - "GET /cas/login HTTP 1.1" 200 7008
因為這三行一組的多次頻繁出現，不禁令人想到：能否用較少的 Request 達到相同的目的呢？在了解 301 302 這兩個 HTTP status code 之後，其實它們的作用都是「重導」，也就是說，對方原始要求 /cas，第一次被我們的系統重導到 /cas/，第二次又被重導到 /cas/login。既然如此，我們可以與 172.16.78.90 要求端協調，是不是能直接發 /cas/login 過來就好？這麼一來就可以減少三分之二的要求數量。