贊助商連結

Cloudways的平台介面中,【Monitoring】是我每天一定都會打開來檢視的功能,它可以監測主機的使用量,包含了RAM、CPU、帶寬、儲存空間以及每個網站的使用量概覽;除此之外,還能監控不同時段的使用量曲線圖,最短可按1小時內的使用量監控,最長可監控6個月內的資料。

Cloudways的平台服務,提供圖形化的介面,不需要碰觸程式指令,也能將網站託管於VPS與雲端主機;節省大把的時間摸索主機設定,也不用擔心安全防護以及任何設定錯誤而產生停機的風險;一個月最低只要US$10,就能享受VPS主機的優越性能+全方位的圖形化操作介面與安全防護。

cloudways-post-2

為什麼要監控主機的使用量?

monitoring

❶因為VPS與雲端主機是按照主機規格計費。
❷時時監控主機的使用量,可以評估選購的主機規格是否合用。
❸即使主機的規格夠用,偶爾也因為某些外掛的例行工作或人為操作,而導致主機使用量暴漲,這時候我們就可以透過【Monitoring】去掌握在特定時段,是否因為操作了某些外掛,而大幅度地佔用了主機使用量,進而去調整外掛的例行工作,或者是調整使用外掛的時間。

在Cloudways檢視主機使用量

how-to-monitoring-final

在【Monitoring】的功能中,〔SUMMARY〕可以查看主機使用量的健康狀態,〔DETAILS〕則是可以查看更多類型的使用量,以及不同時段的用量曲線圖。

操作時間 1 minute

STEP 1|進入Monitoring介面

cloudways-monitoring-step1

點擊Cloudways首頁〔Login〕
輸入註冊Cloudways的Email、密碼,點擊綠色按鈕〔LOGIN NOW〕登入
在〔主機列表〕中,點擊需要設定的主機。
範例中的Cloudways帳戶只有一台主機。
在主機設定頁面中的左邊選單中,點擊〔Monitoring〕,進入主機監控頁面。

STEP 2|介面概覽-SUMMARY

cloudways-monitoring-step2

〔Monitoring〕的介面可分成三大區塊☞【SUMMARY】、【DETAILS】、【NEW RELIC】。
以下對應圖片中的編號詳細介紹:
❶【SUMMARY】主機使用量概覽,可以監控目前的使用狀態
❷【DETAILS】主機使用量明細,以曲線圖呈現。
包含RAM、CPU、帶寬、儲存空間、快取/緩存機制…等等,最小可監控1小時的用量起伏,最大可監控半年。
❸【NEW RELIC】可以監控網站使用情況的雲端服務。
透過Cloudways的後台可直接將網站設定給【NEW RELIC】進行監控,包含網站對資料庫的請求、調用、錯誤分析以及WordPress主題、外掛的掛鉤與性能。
但是Cloudways帳戶只能使用〔Lite〕免費版,無法訪問WordPress主題、外掛的掛鉤與性能的功能,除非要付費升級為〔Essentials〕才能使用。
❹【SERVER HEALTH】主機用量健康警示:
包含RAM、CPU、帶寬以及儲存空間。
點擊右邊的〔重新整理〕按鈕,可以檢視目前最新的狀態。
圖片中的數據條顯示都是〔綠色〕的健康狀態,表示目前主機的使用量都在可負荷的安全範圍內;當網站正在執行大量的工作時,可能會讓〔RAM〕與〔CPU〕的使用量暴增,這時候數據條就會變成橘色的,表示警示或爆表狀態。
如果不管它,當〔RAM〕與〔CPU〕的使用量持續維持在〔100%〕,WordPress後台可能會出現504錯誤,這時候建議先暫停所有的工作,讓〔RAM〕與〔CPU〕的使用量降下來之後,再繼續工作。
如果數據條經常處於〔橘色〕爆表狀態,是該好好調校WordPress的主題與外掛使用量,甚至是需要調高主機規格囉~
★延伸閱讀☞如何調整主機規格與方案
❺【RAM USAGE】RAM使用量:
我購買的主機規格的〔RAM〕為1GB,但是圖片中顯示我的可用的〔RAM〕只有1012MB。
其中已經有449MB被使用,是二個網站的加總使用量;截圖當下我自己並沒有在這二個網站的WordPress後台執行任何操作,這也意味著,即使我自己沒有使用,WordPress資料庫中的主題與外掛也會有自己的工作默默地在後台使用主機的〔RAM〕。
當我自己也在WordPress後台編輯或操作時,〔RAM〕的使用量也會再增加;無論如何使用,只要不是長時間處於〔橘色〕爆表狀態,都代表當前的規格方案都算足夠。
❻【CPU USAGE】CPU使用量:
我購買的主機規格的〔CPU〕為一核心,圖片中以〔%〕顯示,其中只有3%被使用,是二個網站的加總使用量;截圖當下我自己並沒有在這二個網站的WordPress後台執行任何操作;但是當我正在處理一些需要大量請求的工作時,比如說像是匯入超過1GB的資料庫,〔CPU〕可能也會爆表。
短時間的爆表不用太擔心,只要別再增加其他工作量,等它緩慢工作完,就會慢慢恢復成〔綠色〕的健康狀態。
❼【DISK USAGE】儲存空間的使用量:
在Cloudways的平台中,除了網站會佔用儲存空間之外,作業系統〔Operating System〕也會先佔用大約5~6 GB,接著架設網站之後,還會有一些元件以及日誌檔大約佔用1~2 GB。
假設主機規格的儲存空間為25 GB,扣掉作業系統以及其他的元件,實際上我們能夠用來架設網站的空間只會剩下大約17~19 GB。
我的主機方案為25GB(雖然圖片中顯示為24.6 GB);而我一共架設了2個網站,但是這2個網站實際只佔用了2.624 GB(後面編號❾會說明),但是數據條中卻顯示我已經使用了10.31 GB,這就是因為其中有7.686 GB被作業系統與其他的日誌檔案所佔用了。
❽【BANDWIDTH USAGE】頻寬使用量:
這是每個月的頻寬使用量,月初會重新計算。
我購買的主機方案為每個月可擁有1TB的頻寬使用,圖片中顯示目前已使用12GB的頻寬流量,截圖當時為該月份的第18天;即使該月的頻寬使用量還會陸續增加,但是可能網站的訪客流量極低,所以距離限額的1TB來說,其實還天差地遠,完全不用擔心會超量(到底該開心還是難過?)
❾【APPLICATION WISE DETAILS】網站用量概覽:
右邊的〔▬〕展開後可以看網站的使用量。
圖中顯示一共有2個網站。
❿【CPU %】☞個別網站的CPU使用量
⓫【MEMORY】☞個別網站的RAM使用量:
當主機的〔CPU〕或〔RAM〕呈現〔橘色〕爆表狀態時,可以從這裡找到是哪一個網站造成用量暴漲,便能針對性地去網站的WordPress後台調整或停止工作。
⓬【DISK USAGE】個別網站的儲存空間使用量:
這裡可以看到每一個網站的資料庫與所有檔案的加總尺寸。
圖片中顯示〔MiriamMibao〕佔用了2 GB,而〔we-in〕則是624 MB,這二個網站加總也才佔用2.624 GB。
但是在〔編號❼〕主機儲存空間的使用量卻顯示已使用了10.31GB,這就是因為其中有7.686 GB被作業系統與其他的日誌檔案所佔用了。

STEP 3|DETAILS-詳細用量曲線圖

cloudways-monitoring-step3

點擊【DETAILS】進入主機詳細用量曲線圖。
這裡的用量資訊每五分鐘會自動更新一次,所以最近能查詢到前五分鐘的用量資訊。
以下對應圖片中的編號詳細介紹:
❶選擇要檢視的用量類型
【Idle CPU】、【Free Disk】、【Free memory】、【APC Fill Ratio】、【APC Hit rate】、【Monthly Bandwidth】、【Memcached Fill Ratio】、【Memcached Hit Rate】、【Varnish Hit rate】、【Varnish Nuked】、【Auto-healing Restarts】
後面會詳細介紹這些選項以及曲線圖中的數值所代表的意義。
TIP:
如果在可檢視的選項中,沒有看到【Memcached Fill Ratio】、【Memcached Hit Rate】、【Varnish Hit rate】、【Varnish Nuked】,可以在【Manage Services】的選單中啟用Memcached以及Varnish,並且在WordPress後台中使用緩存外掛正確配置。
❷選擇要檢視的時段區間:
【1 Hour】、【12 Hours】、【1 Day】、【7 Days】、【1 Month】、【6 Months】
❸【用量曲線圖】:
〔X軸〕為日期與時間,〔Y軸〕為用量或剩餘量,將滑鼠放在指定的時間與用量交會點,會出現詳細的時間與數值。
❹點擊【重新整理】可產生最新的曲線。

如何解讀Monitoring曲線圖

下面會詳細解釋這些可查看用量的選項到底代表了什麼?曲線圖中的數據又代表著什麼意義?

【Idle CPU】是什麼?

cloudways-Idle-CPU

這裡顯示的是閒置的CPU剩餘量,〔Y軸〕是以〔%〕顯示剩餘用量,〔X軸〕是以5分鐘為間隔顯示日期與時間。〔Y軸〕的〔%〕越低,就表示CPU的使用量越高,主機越忙碌!
在圖片中,查看的是〔1 Months〕的CPU剩餘量,其中,有3個時間點的CPU剩餘量只剩下〔0%〕(紅色框框),另外,有3個時間點則是低於〔20%〕(綠色框框)。也就是說,在該月份中,一共有6個時間點的CPU剩餘量低於〔20%〕,對於整個月份來說,這樣的CPU剩餘量曲線圖還算是理想。
雖然說不用擔心偶發性的低剩餘量,但是當CPU的剩餘量長期連續都低於〔20%〕的時候,要嘛嘗試調整網站的使用情形,要嘛就是調高主機規格囉!

【Free Disk】是什麼?

cloudways-Free-Disk

顯示的是儲存空間剩餘量。
其實這裡很少需要查看,因為它是以〔GB〕作為單位,除非是刪除或增加一個尺寸超過1 GB的網站,否則通常不會出現太大的起伏。
圖片中查看的是〔半年內〕的儲存空間剩餘量。因為我的主機是2020.1.31才購入,所以撰寫這篇文章的時候,還可以查得到購入時的儲存空間用量:我購買的方案為25 GB的儲存空間,但是開通主機的當下,即使還沒有架設任何網站,儲存空間就只剩下16GB,這也就是前面在【STEP 2】的〔編號❼〕所說的,因為作業系統以及其他的元件就先佔用了9 GB,所以實際上我能使用的儲存空間只有16GB。

【Free memory】是什麼?

cloudways-Free-memory

顯示的是記憶體〔RAM〕的剩餘量,單位以〔MB〕計算。
當記憶體剩餘量越高的時候,網站的運作就會越順暢;反之,當記憶體的剩餘量越低的時候,網站就會很卡,如果長時間處於低剩餘量的狀態,網站可能還會崩潰。
比如說,如果連續超過5分鐘的時間,記憶體的剩餘量都低於100MB,這時候網站可能會因為記憶體不足而被迫停止工作,接著監控系統可能還會自動重啟網站,在這個過程中可能會影響訪客的瀏覽。
圖片中顯示的是〔一個月內〕的記憶體剩餘量:我的主機規格的RAM為1GB。記憶體的剩餘量大多介於400~600MB之間,只有5/17這一天的剩餘量低於200MB,整體來說,主機的規格還算是堪用。
如果記憶體剩餘量長期都低於100MB,就該考慮升級主機方案,否則網站會不斷地自動重啟,而經常處於崩潰狀態!
後面會介紹的【Auto-healing Restarts】,就是可以查看網站被自動重啟的時間以及次數。

【APC Fill Ratio】與【APC Hit rate】是什麼?

cloudways-APC-Fill-Ratio-Hit-rate

APC是一種PHP加速器,它可以將PHP程式碼編譯之後所產生的bytecode暫存在共享記憶體內重複使用,以提升PHP的執行效率。
但是我們需要在WordPress安裝可配置的外掛,才能在網站與伺服器之間啟用APC加速。所以圖片中【APC Fill Ratio】與【APC Hit rate】的曲線圖都是空白,是因為我沒有在WordPress設置APC服務。
然而,真實的原因是因為,比起APC,會比較推薦使用後面會介紹的Memcached,或者是在【Settings & Packages】的選單中安裝〔Redis〕,作為伺服器端的加速機制。

【Monthly Bandwidth】是什麼?

cloudways-Monthly-Bandwidth

這是每個月使用的頻寬加總,〔Y軸〕是以〔GB〕為單位,顯示頻寬用量。
因為頻寬的使用是每天不斷加總,所以最低點一定會在每個月的1號,最高點則是每個月的最後一天。
所以我們只需要看每個月的最後一天,也就是每個月的加總,只要加總的用量在主機規格上限內,都不用擔心超量。
圖片中顯示的是〔半年內〕的頻寬用量:我的主機規格的頻寬為1TB。在每個月初的時候,頻寬使用量都是從〔0〕開始,到了月底,會加總達到30GB上下,這樣的用量距離1TB的上限來說,簡直是綽綽有餘。
當然,我們也可以檢視〔7 Days〕的用量,了解一週內是否有哪一天上升的幅度較大;另外,檢視〔1 Months〕的用量,也可以了解當月的曲線上升幅度。


接下來要介紹的是Memcached。
通常在WordPress所安裝的緩存/快取外掛,只能緩存網站前端的〔靜態頁面〕;而Memcached則是在伺服器端快取資料庫的〔動態內容〕,比如說像是購物網站、註冊、登入…等等的工作。
如果要讓網站能夠使用伺服器端的Memcached,除了在Cloudways中啟用Memcached之外,還要在網站中正確配置Memcached設定。
最容易的方式就是在WordPress安裝可配置Memcached的快取外掛,像是免費的W3 Total Cache、或者是付費的WP Rocket。

【Memcached Fill Ratio】是什麼?

Memcached-Fill-Ratio

〔Fill Ratio〕是Memcached空間的使用率,以〔%〕顯示已使用的緩存/快取空間。
如果使用率長期維持在90%以上,就代表Memcached的空間長時間都處於滿載狀態,這時候就要與Cloudways客服聯繫,請它們協助調校。
圖片中的Memcached空間的使用率始終都維持在〔0%〕,這表示雖然在主機端已啟用Memcached的服務,但是在網站中並沒有配置連結到主機端的Memcached,所以主機端的Memcached空間都沒有被使用。

【Memcached Hit Rate】是什麼?

Memcached-hit-Rate

〔Hit Rate〕是Memcached觸及數量,這個數量是越高越好,就表示資料庫中的動態內容被快取的數量越多,網站就不用總是向主機請求資料,因為Memcached已經將這些資料都儲存起來,可以更快速地交付給網站端使用,如此一來,WordPress後台與前端的加載速度都會更快。
和前面的〔Fill Ratio〕一樣,圖片中的Memcached觸及率也是〔0〕,這是因為我沒有在網站中配置Memcached,所以主機端的Memcached無法快取任何網站的內容。


接下來要介紹的Varnish,是另一種更快速、更穩定、更高性能的網頁加速器;它同時也是反向代理,作為伺服器與網站之間橋樑,攔截網站前端的HTTP請求,保護後端伺服器的加密與安全;還可以快取/緩存網頁文件,像是html,js,css,圖像…等等,除了讓資料傳輸更快速之外,同時也降低了後端伺服器的工作量。
如果要在網站中使用Varnish,要先在Cloudways的【Manage Services】啟用【Varnish】,接著在WordPress後台安裝能夠啟用Varnish的緩存外掛,比如說,Cloudwyas自家的Breeze外掛就能夠快速在WordPress後台中設定與主機連結的Varnish配置。

  • WordPress的快取負責網站前端的靜態頁面。
  • Varnish是在網站與伺服器之間作為反向代理,保護伺服器安全,也快取HTTP請求,減少伺服器工作量。
  • Memcached則是在伺服器端快取資料庫的動態內容,減少資料庫反覆查找的頻率。

【Varnish Hit rate】是什麼?

cloudways-Varnish-Hit-rate

這是Varnish的觸及數量,和前面的【Memcached Hit Rate】一樣,都是越高越好,最好都能維持在80%以上,這樣就代表了網站前端有80%的請求被Varnish儲存後並且直接交付給前端的訪客使用,不需要每一次訪問都向主機討資料,如此便能減少主機負荷、也能加速網頁開啟。
如果在曲線圖中發現觸及率為〔0〕,請檢查是否在主機已啟用Varnish,以及在WordPress網站中是否正確配置Varnish。
圖片中顯示在過去一個月內,只有某一週(4/27~5/2)的Varnish觸及率有達到最佳的80%以上,其餘時間都低於80%,雖然觸及率表現不理想,但未必是壞事,因為這往往取決於網站的狀態、內容型態,或者是使用了其他的CDN內容交付所產生的影響。
比如說,可能因為網站瀏覽量較低、網站經常更新、使用Cloudflare…等等的因素。
以下幾種情況會使得Varnish的觸及數量經常低於80%:
❶網站流量較低
因為Varnish所快取的內容將保存4小時,但是在瀏覽量較低的網站中,這些內容可能還沒有被交付使用就過期清除了,於是Varnish便會反映出較低的觸及率。
❷大多為POST請求
因為Varnish不快取POST請求,如果網站中的POST請求較多,也會反映出較低的觸及率。
通常會發生在建構中的低流量網站,因為這時候網站的更新較為頻繁,而瀏覽量卻相對地低。
TIP❝可以把POST請求想像成前端的〔登入〕、〔提交表單〕、〔上傳內容〕…等等的操作。
❸經常更新網站內容
因為Varnish所快取的內容只保存4小時,當網站瀏覽量低、經常更新,都會使得這些內容還沒有被使用就被清除了。
❹非必要Cookie
除了不快取POST請求之外,網站中埋置的追蹤碼也會產生大量的Cookie,以及訪客瀏覽所提交的Cookie,都不會被Varnish緩存,這也會使Varnish反映出較低的觸及率。
❺其他的CDN代理
如果有使用其他的CDN交付網站內容,比如說Cloudflare,也會使降低Varnish的觸及率。

以上資料來自於Cloudways的文檔。

【Varnish Nuked】是什麼?

cloudways-Varnish-Nuked

類似前面提到的【Memcached Fill Ratio】,可以把它想像成Varnish的可用空間,但是這裡的〔Y軸〕單位不是空間,而是被迫刪除的數量!
因為可用空間不足,所以被迫刪除已經快取但是還沒到期的內容數量,為的是騰出空間去快取新請求。
所以說,這裡的數量最好都維持〔0〕,代表沒有任何已經被快取的內容因為空間不足而被刪除
如果發現持續有內容被迫刪除,也就是曲線圖的〔Y軸〕經常大於〔0〕,建議聯繫Cloudways客服,請它們協助調整。
圖片中顯示過去半年內的〔Y軸〕數量為〔0〕,代表可緩存的空間相當足夠,未曾發生被迫刪除的情形。

【Auto-healing Restarts】是什麼?

cloudways-Auto-healing-Restarts

這裡顯示的是網站被自動重啟的數量,〔X軸〕代表日期/時間,〔Y軸〕代表重啟次數。
這是Cloudways的網站自動重啟機制,通常會發生在網站對主機資料庫的大量請求,導致剩餘記憶體不足時,會觸發自動重啟機制,強制暫停網站運作之後再重啟。
雖然自動重啟能夠恢復網站的工作,但是在重啟之後,原本還沒完成的工作還是會繼續發出大量的請求,於是就會不斷地自動重啟,直到那項工作完全結束為止,在這個過程中,其實網站可能已經自動重啓了數十次。
如果在極短時間內不斷地觸發自動重啟,也是會導致網站崩潰,這時候如果正在使用網站,就真的會504的各種錯誤囉~
圖片中顯示了〔半年內〕以及〔一天內〕的自動重啟數量:
〔半年內〕☞〔X軸〕以〔天〕為單位,2020/1/31那天,也是開始使用Cloudways的那天,因為同時將二個網站搬到Cloudways,當天自動重啟數量加總將近200次!
除此之外,其中還有2天的自動重啟次數介於50~100次之間,在我的使用情況中,通常是因為執行Staging Site或新增測試網站、匯入主題…等等這種相當消耗記憶體的工作;另外還有9天也有觸發自動重啟機制,不過次數都低於50次,這通常會發生在反覆地測試外掛、更新網站設定…等等需要不斷清除緩存甚至是停用緩存的情況。
整體來看,這半年內,也就只有13天有觸發自動重啟機制,其餘100多天的次數都是〔0〕,可說是偶發性的暫時記憶體不足,不至於需要調升主機方案。
〔一天內〕☞〔X軸〕以〔30分鐘〕為單位,顯示在這一天內的不同時段裡,重啟次數為〔0〕。

有時候只是偶發性的單一外掛或程序所造成的記憶體不足,即使觸發自動重啟,我們自己在WordPress後台可能也不會察覺。
倘若長時間都處於經常需要數十次甚至上百次的觸發自動重啟,那網站就會崩潰,直到那些工作徹底結束。
這時候最好暫停所有工作,等待記憶體恢復正常的使用量,可在前面提到的【SERVER HEALTH】主機用量健康警示檢查,等待它恢復成〔綠色健康狀態〕之後,再繼續使用WordPress後台。
如果經常觸發自動重啟機制,建議安裝Memcached或Redis緩存機制,再不行就要考慮調升主機的記憶體規格囉。

閱讀更多Cloudways相關教學:

Cloudways的Monitoring功能就介紹到這裡了!如果有任何問題,歡迎在下方的留言板討論指教囉~

好嘛好嘛…臨走前幫我拍拍手嘛
如果你願意免費幫助我,請在下方圓形按鈕幫我拍拍手,最多可以按5下,那就幫我按5下吧!算我求你啦啦啦~~~謝謝你、我愛你❤
臉書或Google帳號都可以快速登入喲…

facebook留言板|文章相關問題歡迎留言討論唷~
IMG_2349-miriammibao-100px

▍關於作者|MiriamMibao温唯

2019.02.11,我開始了這裡…
不懂css、不懂php,當然-也不知道誰是Nginx、誰又是Apache…
硬要WordPress架站,一切自己來,所有的細節,從0開始,自己架站會遇到的問題,遇到了才知道!這一路走來,跌跌撞撞,摸索過國內外能夠解決問題的資料…
是不是該好好紀錄這一段跌跌撞撞的探索日記?或許,也能帶給你們一些幫助...

咖啡贊助計畫

buy me a coffee-icon

我願意《將我所知道的一切,仔細地、真實地分享給你》
你願意《請我喝咖啡》嗎?
你的一杯咖啡,是我最溫暖的支持❤
用實際行動支持我創作更多好作品吧