LNMP的運維追蹤技巧總結

LNMP的運維追蹤技巧總結

曾幾什麼時候我開始運維公司的LNMP網站,通過一段時間的摸爬滾打,也算是總結了很多在LNMP服務器下調試追蹤各類網站錯誤的方法。好記性不如爛筆頭,仍是總結一下吧!php

在開始我會梳理一下我所理解的一個web請求從發起到響應的各個階段服務器和瀏覽器分別作了什麼。因此的用戶響應異常都是發生在這個流程中的,知道每一個流程的細節能夠經過不一樣的方法分別定位異常發生在哪一個階段,從而更準確快速的定位錯誤。後面就是持續更新的我在被這個網站折磨中經歷的各類錯誤,給本身作一個記錄,固然若是能幫到其餘人,我也很榮幸。html

一個Web請求過程當中到底發生了什麼?

簡單的web請求

上圖是一個簡單的web請求全過程,嗯,畫的確實有點過於簡單,上圖中我隱藏了不少細節,下面一一說明,可能有沒涉及到的地方歡迎補充:前端

第一步

用戶輸入url如http:www.baidu.com到瀏覽器,瀏覽器如chrom須要將其解析爲ip地址才知道須要到哪裏去訪問哪一個服務器。瀏覽器解析DNS步驟以下:nginx

  1. 搜索瀏覽器自身的dns緩存,這個緩存緩存時間短,緩存數目有限。
  2. 搜索操做系統的dns緩存
  3. 讀取host文件的dns映射(通常作本地開發映射都是修改這個文件來達到攔截瀏覽器請求到本地服務器的目的,從而使本地能夠成功映射服務器地址)
  4. 先本地網卡配置裏的dns服務器發起域名解析請求,這裏好像還有一套運營商的處理流程就不在展開了。
  5. 下面好像還有一些流程,因爲基本不會執行到這一步,通常因此dns運營商的dns服務器都會搞定的。
  6. 解析失敗,以上任何一步成功都會返回一個成功的ip地址

第二步

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

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服務端體系下的流程。心中有個總體流程的概念才能夠更好的追蹤實際問題。下面就是針對上面幾個基本步驟中會出現的問題的定位和追蹤。緩存

第一步和第二步出現問題,能夠經過「端口可用性探測」來定位。

  1. ping www.baidu.com 檢測域名解析器是否異常
檢查域名解析是否錯誤
  1. 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傳送門

相關文章
相關標籤/搜索