資訊專欄INFORMATION COLUMN
摘要：的運維追蹤技巧總結曾幾何時我開始運維公司的網(wǎng)站，經(jīng)過一段時間的摸爬滾打，也算是總結了不少在服務器下調試追蹤各種網(wǎng)站錯誤的方法。
LNMP的運維追蹤技巧總結
曾幾何時我開始運維公司的LNMP網(wǎng)站，經(jīng)過一段時間的摸爬滾打，也算是總結了不少在LNMP服務器下調試追蹤各種網(wǎng)站錯誤的方法。好記性不如爛筆頭，還是總結一下吧！
在開始我會梳理一下我所理解的一個web請求從發(fā)起到響應的各個階段服務器和瀏覽器分別做了什么。所以的用戶響應異常都是發(fā)生在這個流程中的，知道每個流程的細節(jié)可以通過不同的方法分別定位異常發(fā)生在哪個階段，從而更準確快速的定位錯誤。后面就是持續(xù)更新的我在被這個網(wǎng)站折磨中經(jīng)歷的各種錯誤，給自己做一個記錄，當然如果能幫到其他人，我也很榮幸。
一個Web請求過程中到底發(fā)生了什么？上圖是一個簡單的web請求全過程，嗯，畫的確實有點過于簡單，上圖中我隱藏了很多細節(jié)，下面一一說明，可能有沒涉及到的地方歡迎補充：
第一步用戶輸入url如http:www.baidu.com到瀏覽器，瀏覽器如chrom需要將其解析為ip地址才知道需要到哪里去訪問哪個服務器。瀏覽器解析DNS步驟如下：
搜索瀏覽器自身的dns緩存，這個緩存緩存時間短，緩存數(shù)目有限。
搜索操作系統(tǒng)的dns緩存
讀取host文件的dns映射(一般做本地開發(fā)映射都是修改這個文件來達到攔截瀏覽器請求到本地服務器的目的，從而使本地可以成功映射服務器地址)
先本地網(wǎng)卡配置里的dns服務器發(fā)起域名解析請求，這里好像還有一套運營商的處理流程就不在展開了。
下面好像還有一些流程，由于基本不會執(zhí)行到這一步，一般所以dns運營商的dns服務器都會搞定的。
解析失敗，以上任何一步成功都會返回一個成功的ip地址
第二步瀏覽器以一個隨機的端口享這個ip地址的特定端口(默認80)發(fā)起著名的TCP3次握手。關于一個http請求是如何到達nginx服務的流程大致如下：
st=>start: TCP請求 en=>end: 異常 op=>operation: Nginx模塊 cond1=>condition: 進入網(wǎng)卡？ cond2=>condition: 內核的TCP/IP協(xié)議棧？ cond3=>condition: 防火墻? st->cond1 cond1(yes)->cond2 cond1(no)->en cond2(yes)->cond3 cond2(no)->en cond3(no)->en cond3(yes)->op第三步
握手完成后的瀏覽器和服務器就可以愉快地發(fā)送http請求了，具體在nginx上流程如下：
st=>start: http請求 en=>end: response響應 op1=>operation: 第二步流程 op2=>operation: nginx進程 op3=>operation: 獲取http的頭部信息 op4=>operation: 匹配server_name，定位到站點的root op5=>operation: 進入代碼框架的路由 op6=>operation: 框架的路由解析器解析出php文件 op7=>operation: php進入fastcgi進程 op8=>operation: fastcgi進程將php填充成html文件 op9=>operation: html文件遞交給nginx并設置響應信息 st->op1->op2->op3->op4->op5->op6->op7->op8->op9->en第四步
瀏覽器根據(jù)服務器resopnse的響應頭和響應體渲染出可視化頁面
| 響應碼 | 說明 |
|---|---|
| 1xx | 信息性狀態(tài)說明 |
| 2xx | 成功狀態(tài)碼 |
| 3xx | 重定向狀態(tài)碼 |
| 301 | 永久重定向, Location響應首部的值仍為當前URL，因此為隱藏重定向 |
| 302 | 臨時重定向，顯式重定向, Location響應首部的值為新的URL |
| 304 | Not Modified 未修改，比如本地緩存的資源文件和服務器上比較時，發(fā)現(xiàn)并沒有修改，服務器返回一個304狀態(tài)碼,告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可 |
| 4xx | 客戶端錯誤 |
| 404 | Not Found 請求的URL資源并不存在 |
| 5xx | 服務器錯誤 |
| 500 | Internal Server Error 服務器內部錯誤 |
| 502 | Bad Gateway 前面代理服務器聯(lián)系不到后端的服務器時出現(xiàn) |
| 504 | Gateway Timeout 這個是代理能聯(lián)系到后端的服務器，但是后端的服務器在規(guī)定的時間內沒有給代理服務器響應 |
上面大致梳理了下一個http請求在LNMP服務端體系下的流程。心中有個整體流程的概念才可以更好的追蹤實際問題。下面就是針對上面幾個基本步驟中會出現(xiàn)的問題的定位和追蹤。
第一步和第二步出現(xiàn)問題，可以通過「端口可用性探測」來定位。ping www.baidu.com 檢測域名解析器是否異常
檢查域名解析是否錯誤
telnet 127.0.0.1 80 追蹤端口是否異常
檢查端口是否打開，防火墻是否過濾第三步出現(xiàn)的問題
這一步一般是網(wǎng)站出問題的主要地方，絕大部分問題都是出現(xiàn)在這個階段，同樣這個階段出現(xiàn)的問題也是最難定位和解決的。為了更好的處理這個階段的問題我們需要更深入地了解下一個web服務器與一個web程序直接的信息通信的模型與流程。
要說明這個問題，首先我們需要了解什么是大名頂頂?shù)腃GI協(xié)議、FASTCGI協(xié)議和PHP-FPM，以及它們之前的關系。
對于一個PHP的web程序來說，web服務器（如：nginx）要想與它通信需要通過CGI協(xié)議。當一個web請求觸達web服務器時，web服務器會創(chuàng)建一個CGI進程,CGI進程將web的請求按照固定的格式進行解析，然后寫入標準輸入(STDIN)和環(huán)境變量中，然后PHP啟動的CGI解析器會從標準輸入(STDIN)和環(huán)境變量中讀取http請求的數(shù)據(jù)，所以$_SERVER才會有數(shù)據(jù)，然后做出相應的邏輯處理，然后將處理結果放入標準輸出(STDOUT)，CGI進程從STDOUT中讀取響應數(shù)據(jù)然后傳輸給瀏覽器，這樣服務端就完成了一次http請求。
上面是CGI的實現(xiàn)流程，但是使用CGI協(xié)議的服務器在用戶每次訪問服務器的時候都需要fork/銷毀CGI進程，必然照成多余的系統(tǒng)開銷，所以FASTCGI就是為了解決這個問題的。
FastCGI會創(chuàng)建一個常駐的master進程和多個worker進程，master進程負責管理和為worker進程反派任務，worker進程負責內部嵌入了CGI解析器用于解釋php代碼。
PHP-FPM是一個FastCGI進程管理器，在LNMP體系中就是由它來實現(xiàn)FastCGI協(xié)議的。同樣，它也會創(chuàng)建一個常駐的master進程和多個worker進程，master進程負責監(jiān)聽端口和接收來自nginx的請求，指派任務給worker進程。worker進程的負責解釋php代碼。PHP-FPM可以通過配置預先啟動一定數(shù)量的worker進程，這樣當http請求觸達時就可以更快速的響應。
nginx與PHP-FPM之間的通信一般通過其ngx_http_fastcgi_module模塊來實現(xiàn)。其中fastcgi_pass用于設置fastcgi服務器的IP地址;fastcgi_param設置傳入fastcgi服務器的參數(shù)。這個模塊出現(xiàn)的配置問題一般集中在這一塊。
相對于并發(fā)狀態(tài)下出現(xiàn)的問題，一般也都集中在fastcgi服務器上，具體表現(xiàn)為fastcgi服務器為了應對大量的http請求必須不停的fork新的worker進程，這時就需要考慮服務器可支持的最大鏈接數(shù)和最大打開文件數(shù)（可通過ulimit -n查看）以及php-fpm配置里的最低開啟worker數(shù)和最高開啟worker數(shù)的限制。高性能服務器可以在這個方向上調優(yōu)。這也是我目前還在探索的地方，以后肯定也會寫一個總結。
第四步出現(xiàn)的問題這一步一般很少出現(xiàn)問題，出現(xiàn)問題也很容易定位，多是前端渲染問題，我也不是很懂。
未完分割線，后面我會總結一些各個階段可能發(fā)生的錯誤，這些錯誤在客戶端的表現(xiàn)，如何定位，以及如何解決。
CSDN傳送門
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/29016.html
摘要：的運維追蹤技巧總結曾幾何時我開始運維公司的網(wǎng)站，經(jīng)過一段時間的摸爬滾打，也算是總結了不少在服務器下調試追蹤各種網(wǎng)站錯誤的方法。 LNMP的運維追蹤技巧總結 曾幾何時我開始運維公司的LNMP網(wǎng)站，經(jīng)過一段時間的摸爬滾打，也算是總結了不少在LNMP服務器下調試追蹤各種網(wǎng)站錯誤的方法。好記性不如爛筆頭，還是總結一下吧！ 在開始我會梳理一下我所理解的一個web請求從發(fā)起到響應的各個階段服務器和...
摘要：作為骨灰級粉絲，一直以來對第三方監(jiān)控都是拒絕的。例如白屏時間首屏時間腳本錯誤網(wǎng)頁加載就緒時間各種瀏覽器的訪問情況，甚至能了解不同瀏覽器運營商地區(qū)用戶的訪問狀況。腳本錯誤在所難免，錯誤進一步導致網(wǎng)站部分功能無法使用。 作為 Zabbix 骨灰級粉絲，一直以來對第三方監(jiān)控（APM）都是拒絕的。一來覺得收費，二來擔心數(shù)據(jù)被人所知，三來覺得 Zabbix 牛逼到無可取代。但是，隨著 APM 市...
摘要：當云平臺出現(xiàn)網(wǎng)絡故障系統(tǒng)故障等問題，這對云租戶用戶有時甚至是致命的，所以不少是由高級別開發(fā)人員轉型而來。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨阿里華為等。 DevOps 全鏈路 下圖是我們熟知的軟件研發(fā)環(huán)節(jié)，在迭代頻率高的研發(fā)組織里，一天可能要經(jīng)歷多次如下循環(huán)。對于用戶群體龐大或者正在經(jīng)歷大幅業(yè)務擴張的企業(yè)研發(fā)組織，除了重點關注應用的快速上線之外，如何保障應用的高可...
摘要：于是選擇了作為項目的運維監(jiān)控系統(tǒng)。能做什么主要是用來網(wǎng)絡監(jiān)控系統(tǒng)監(jiān)控應用監(jiān)控等場景。搭建環(huán)境集成環(huán)境版本。但是如果你的系統(tǒng)沒有名叫的用戶，你需要創(chuàng)建一個用戶。系統(tǒng)默認的管理賬號是密碼是。解決辦法是修改文件的配置。 使用目的? 在公司項目中需要做一個日志監(jiān)控，最開始選擇的是efk，但是efk的資料相對較少并且之前對這幾個產(chǎn)品都沒接觸過，使用起來難度。于是選擇了zabbix作為項目的運維監(jiān)...
閱讀 925·2021-11-25 09:43
閱讀 1301·2021-11-17 09:33
閱讀 3026·2019-08-30 15:44
閱讀 3317·2019-08-29 17:16
閱讀 486·2019-08-28 18:20
閱讀 1645·2019-08-26 13:54
閱讀 558·2019-08-26 12:14
閱讀 2180·2019-08-26 12:14
