LNMP的運維追蹤技巧總結

XboxYan 發布于2019-07-25 14:22 / 2211人閱讀

摘要：的運維追蹤技巧總結曾幾何時我開始運維公司的網站，經過一段時間的摸爬滾打，也算是總結了不少在服務器下調試追蹤各種網站錯誤的方法。

LNMP的運維追蹤技巧總結

曾幾何時我開始運維公司的LNMP網站，經過一段時間的摸爬滾打，也算是總結了不少在LNMP服務器下調試追蹤各種網站錯誤的方法。好記性不如爛筆頭，還是總結一下吧！

在開始我會梳理一下我所理解的一個web請求從發起到響應的各個階段服務器和瀏覽器分別做了什么。所以的用戶響應異常都是發生在這個流程中的，知道每個流程的細節可以通過不同的方法分別定位異常發生在哪個階段，從而更準確快速的定位錯誤。后面就是持續更新的我在被這個網站折磨中經歷的各種錯誤，給自己做一個記錄，當然如果能幫到其他人，我也很榮幸。

一個Web請求過程中到底發生了什么？

上圖是一個簡單的web請求全過程，嗯，畫的確實有點過于簡單，上圖中我隱藏了很多細節，下面一一說明，可能有沒涉及到的地方歡迎補充：

第一步

用戶輸入url如http:www.baidu.com到瀏覽器，瀏覽器如chrom需要將其解析為ip地址才知道需要到哪里去訪問哪個服務器。瀏覽器解析DNS步驟如下：

搜索瀏覽器自身的dns緩存，這個緩存緩存時間短，緩存數目有限。

搜索操作系統的dns緩存

讀取host文件的dns映射(一般做本地開發映射都是修改這個文件來達到攔截瀏覽器請求到本地服務器的目的，從而使本地可以成功映射服務器地址)

先本地網卡配置里的dns服務器發起域名解析請求，這里好像還有一套運營商的處理流程就不在展開了。

下面好像還有一些流程，由于基本不會執行到這一步，一般所以dns運營商的dns服務器都會搞定的。

解析失敗，以上任何一步成功都會返回一個成功的ip地址

第二步

瀏覽器以一個隨機的端口享這個ip地址的特定端口(默認80)發起著名的TCP3次握手。關于一個http請求是如何到達nginx服務的流程大致如下：

st=>start: TCP請求
en=>end: 異常
op=>operation: Nginx模塊
cond1=>condition: 進入網卡？
cond2=>condition: 內核的TCP/IP協議棧？
cond3=>condition: 防火墻?

st->cond1
cond1(yes)->cond2
cond1(no)->en
cond2(yes)->cond3
cond2(no)->en
cond3(no)->en
cond3(yes)->op

第三步

握手完成后的瀏覽器和服務器就可以愉快地發送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

第四步

瀏覽器根據服務器resopnse的響應頭和響應體渲染出可視化頁面

響應碼	說明
1xx	信息性狀態說明
2xx	成功狀態碼
3xx	重定向狀態碼
301	永久重定向, Location響應首部的值仍為當前URL，因此為隱藏重定向
302	臨時重定向，顯式重定向, Location響應首部的值為新的URL
304	Not Modified 未修改，比如本地緩存的資源文件和服務器上比較時，發現并沒有修改，服務器返回一個304狀態碼,告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可
4xx	客戶端錯誤
404	Not Found 請求的URL資源并不存在
5xx	服務器錯誤
500	Internal Server Error 服務器內部錯誤
502	Bad Gateway 前面代理服務器聯系不到后端的服務器時出現
504	Gateway Timeout 這個是代理能聯系到后端的服務器，但是后端的服務器在規定的時間內沒有給代理服務器響應

上面大致梳理了下一個http請求在LNMP服務端體系下的流程。心中有個整體流程的概念才可以更好的追蹤實際問題。下面就是針對上面幾個基本步驟中會出現的問題的定位和追蹤。

第一步和第二步出現問題，可以通過「端口可用性探測」來定位。

ping www.baidu.com 檢測域名解析器是否異常

檢查域名解析是否錯誤

telnet 127.0.0.1 80 追蹤端口是否異常

檢查端口是否打開，防火墻是否過濾

第三步出現的問題

這一步一般是網站出問題的主要地方，絕大部分問題都是出現在這個階段，同樣這個階段出現的問題也是最難定位和解決的。為了更好的處理這個階段的問題我們需要更深入地了解下一個web服務器與一個web程序直接的信息通信的模型與流程。

要說明這個問題，首先我們需要了解什么是大名頂頂的CGI協議、FASTCGI協議和PHP-FPM，以及它們之前的關系。

對于一個PHP的web程序來說，web服務器（如：nginx）要想與它通信需要通過CGI協議。當一個web請求觸達web服務器時，web服務器會創建一個CGI進程,CGI進程將web的請求按照固定的格式進行解析，然后寫入標準輸入(STDIN)和環境變量中，然后PHP啟動的CGI解析器會從標準輸入(STDIN)和環境變量中讀取http請求的數據，所以$_SERVER才會有數據，然后做出相應的邏輯處理，然后將處理結果放入標準輸出(STDOUT)，CGI進程從STDOUT中讀取響應數據然后傳輸給瀏覽器，這樣服務端就完成了一次http請求。

上面是CGI的實現流程，但是使用CGI協議的服務器在用戶每次訪問服務器的時候都需要fork/銷毀CGI進程，必然照成多余的系統開銷，所以FASTCGI就是為了解決這個問題的。

FastCGI會創建一個常駐的master進程和多個worker進程，master進程負責管理和為worker進程反派任務，worker進程負責內部嵌入了CGI解析器用于解釋php代碼。

PHP-FPM是一個FastCGI進程管理器，在LNMP體系中就是由它來實現FastCGI協議的。同樣，它也會創建一個常駐的master進程和多個worker進程，master進程負責監聽端口和接收來自nginx的請求，指派任務給worker進程。worker進程的負責解釋php代碼。PHP-FPM可以通過配置預先啟動一定數量的worker進程，這樣當http請求觸達時就可以更快速的響應。

nginx與PHP-FPM之間的通信一般通過其ngx_http_fastcgi_module模塊來實現。其中fastcgi_pass用于設置fastcgi服務器的IP地址;fastcgi_param設置傳入fastcgi服務器的參數。這個模塊出現的配置問題一般集中在這一塊。

相對于并發狀態下出現的問題，一般也都集中在fastcgi服務器上，具體表現為fastcgi服務器為了應對大量的http請求必須不停的fork新的worker進程，這時就需要考慮服務器可支持的最大鏈接數和最大打開文件數（可通過ulimit -n查看）以及php-fpm配置里的最低開啟worker數和最高開啟worker數的限制。高性能服務器可以在這個方向上調優。這也是我目前還在探索的地方，以后肯定也會寫一個總結。

第四步出現的問題

這一步一般很少出現問題，出現問題也很容易定位，多是前端渲染問題，我也不是很懂。

未完分割線，后面我會總結一些各個階段可能發生的錯誤，這些錯誤在客戶端的表現，如何定位，以及如何解決。

CSDN傳送門

云服務器 GPU云服務器技巧總結應用技巧總結云服務的運維云計算的運維

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/40019.html

LNMP的運維追蹤技巧總結

摘要：的運維追蹤技巧總結曾幾何時我開始運維公司的網站，經過一段時間的摸爬滾打，也算是總結了不少在服務器下調試追蹤各種網站錯誤的方法。 LNMP的運維追蹤技巧總結曾幾何時我開始運維公司的LNMP網站，經過一段時間的摸爬滾打，也算是總結了不少在LNMP服務器下調試追蹤各種網站錯誤的方法。好記性不如爛筆頭，還是總結一下吧！在開始我會梳理一下我所理解的一個web請求從發起到響應的各個階段服務器和...

Cristalven 2019-07-01 10:18 評論0 收藏0
OneAPM 云監控部署與試用體驗

摘要：作為骨灰級粉絲，一直以來對第三方監控都是拒絕的。例如白屏時間首屏時間腳本錯誤網頁加載就緒時間各種瀏覽器的訪問情況，甚至能了解不同瀏覽器運營商地區用戶的訪問狀況。腳本錯誤在所難免，錯誤進一步導致網站部分功能無法使用。作為 Zabbix 骨灰級粉絲，一直以來對第三方監控（APM）都是拒絕的。一來覺得收費，二來擔心數據被人所知，三來覺得 Zabbix 牛逼到無可取代。但是，隨著 APM 市...

Tecode 2019-05-28 16:54 評論0 收藏0
他山之石——運維平臺哪家強？

摘要：當云平臺出現網絡故障系統故障等問題，這對云租戶用戶有時甚至是致命的，所以不少是由高級別開發人員轉型而來。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨阿里華為等。 DevOps 全鏈路下圖是我們熟知的軟件研發環節，在迭代頻率高的研發組織里，一天可能要經歷多次如下循環。對于用戶群體龐大或者正在經歷大幅業務擴張的企業研發組織，除了重點關注應用的快速上線之外，如何保障應用的高可...

mylxsw 2019-05-28 17:13 評論0 收藏0
Lnmp搭建zabbix運維監控系統

摘要：于是選擇了作為項目的運維監控系統。能做什么主要是用來網絡監控系統監控應用監控等場景。搭建環境集成環境版本。但是如果你的系統沒有名叫的用戶，你需要創建一個用戶。系統默認的管理賬號是密碼是。解決辦法是修改文件的配置。使用目的? 在公司項目中需要做一個日志監控，最開始選擇的是efk，但是efk的資料相對較少并且之前對這幾個產品都沒接觸過，使用起來難度。于是選擇了zabbix作為項目的運維監...

oysun 2019-07-01 13:59 評論0 收藏0