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