Home » Posts tagged "smokeping"

當 Daemon 死掉時自動重新跑起...

以前確保 daemon 掛掉時會重新跑起來大概有幾個方式,像是用 Monit 顧,然後再用 /etc/inittab 確保 Monit 不會掛掉...

systemd 的年代,因為 systemd 已經被保護起來,而重跑這個功能在 systemd 裡就有支援,不需要用 Monit 這類程式了。

manual 裡搜尋 restart 可以看到幾個參數:

  • Restart=
  • RestartForceExitStatus=
  • RestartPreventExitStatus=
  • RestartSec=

這次是遇到 SmokePing 的 FastCGI daemon 每隔幾天會自己死掉,導致 nginx 丟出 503 然後被 UptimeRobot 偵測到而拋出警告。

但這個問題只有在一台伺服器會發生,而 log 裡也沒翻到可以繼續 debug 的錯誤訊息,試著猜測一些情境去搜尋引擎找也沒翻到... 就決定先 workaround 來處理,然後就發現現在已經不太需要用 Monit 來處理這個問題了。

HiNet 與 DigitalOcean、Linode、Vultr 的封包情況

先說結論,綜合網路與 CPU 的情況,我剛好跟下面提到的文章給出相反的選擇 (i.e. 完全不會選 DigitalOcean)。如果是需要 latency 低的品質我會選 Linode 的東京新機房 Tokyo 2,如果不需要 latency 的我會選 Vultr 的 USD$2.5/month 方案 (目前只在邁阿密與紐約有)。

看到「2018/06 台灣 5USD 虛擬主機網路延遲測試」這篇就來推廣一下 SmokePing 這個工具。這個工具可以做很多事情,但最常看到的用途還是做網路品質監控,先前在 K 社的時候就有個做個公開的站台可以看,後來接手的人也繼續維護著 (畢竟看這些圖有種治癒感?):「smokeping.kkbox.com.tw」。

不過 K 社的 SmokePing 裡面大多數是從固網機房端監控,而固網機房端的 Internet 品質一般來說都會比家用型的好很多,尤其是國際頻寬的部份。所以我也在我家裡用 PPPoE 版本的固定 IP 做了一份:「https://home.gslin.org/smokeping/」,這邊的設定檔放在 GitHub 上的 gslin/smokeping-config.d 上。

而我剛好有把這三家 VPS 的 SmokePing 都做起來:「SmokePing Latency Page for DigitalOcean」、「SmokePing Latency Page for Linode」、「SmokePing Latency Page for Vultr」。

我這邊看到的情況是這樣。以各家離台灣最近的點來看:

  • 第一張圖的 DigitalOcean 沒有東京的點,而新加坡的 latency 在這幾個月其實變差不少,現在大約要 90ms (扣掉光世代的 10ms)。
  • 第二跟第三張圖的 Linode (分別是 Tokyo 1 與 Tokyo 2) 其實可以看到新機房 Tokyo 2 的 latency 比舊機房 Tokyo 1 還好。
  • 第四張圖的 Vultr 則是狀況變化很多,但不管怎麼走,latency 大致上都還是比新加坡好。

另外第五張的 Vultr 則是紐約的點,latency 超高 (畢竟繞了半個地球),但 packet loss 不高,品質還算穩定。


speedtest-sgp1.digitalocean.com (DigitalOcean Singapore 1)


speedtest.tokyo.linode.com (Linode Tokyo)


speedtest.tokyo2.linode.com (Linode Tokyo 2)


hnd-jp-ping.vultr.com


nj-us-ping.vultr.com

另外是之前有痛到的部份,先前因為需求而需要在 PHP 5.6 上跑 WordPress,真的實際跑起來後發現超慢 (畢竟這兩個要快得想不少辦法),去找問題後發現 DigitalOcean 機器的 CPU 真的太慢,後來把這組需求搬去 Linode (在 CPU 與網路之間取個合理的平衡點)。

在各家 VPS 上用 Ubuntu 16.04 跑 openssl speed md5 可以看出一些資料:

DigitalOcean:

Doing md5 for 3s on 16 size blocks: 5465798 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3761125 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 1835218 md5's in 2.99s
Doing md5 for 3s on 1024 size blocks: 582162 md5's in 2.96s
Doing md5 for 3s on 8192 size blocks: 102995 md5's in 2.97s
Doing md5 for 3s on 16384 size blocks: 47177 md5's in 2.99s

Linode:

Doing md5 for 3s on 16 size blocks: 11510700 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 8361353 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 3751929 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1169457 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 157678 md5's in 2.99s
Doing md5 for 3s on 16384 size blocks: 78874 md5's in 3.00s

Vultr (這是 USD$2.5/month 的方案):

Doing md5 for 3s on 16 size blocks: 14929209 md5's in 2.97s
Doing md5 for 3s on 64 size blocks: 9479563 md5's in 2.97s
Doing md5 for 3s on 256 size blocks: 4237907 md5's in 2.98s
Doing md5 for 3s on 1024 size blocks: 1320548 md5's in 2.98s
Doing md5 for 3s on 8192 size blocks: 161940 md5's in 2.96s
Doing md5 for 3s on 16384 size blocks: 86592 md5's in 2.98s

然後補一個 AWS 的 t2.nano (在還有 CPU credit 可以全速跑的情況下),不過這不公平,參考用而已:

Doing md5 for 3s on 16 size blocks: 19257426 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 11168752 md5's in 2.99s
Doing md5 for 3s on 256 size blocks: 4959879 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 1518690 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 203910 md5's in 3.00s
Doing md5 for 3s on 16384 size blocks: 102321 md5's in 2.99s

合併 RRD 資料的工具

昨天把跑在 Raspberry Pi 上的 SmokePing 資料改用統一版本 (我在 GitHub 上公開的 smokeping-config.d 這個),但有些節點的 naming 改變了,所以會需要將資料整在一起。

在透過 Google 搜尋後,用的工具是「A very simple script to merge multiple RRD files, since none of those available seem to work.」這個,是一隻 Python 的程式。另外可以從程式碼裡面看到他使用了 rrdtool 這個 CLI 工具 (SmokePing 用了 RRD 格式儲存資料),所以使用這隻程式前需要先安裝 rrdtool 這個套件:

$ sudo apt install rrdtool

接下來就是照說明來轉換。由於 rrdtool 這隻程式沒有對 filename 做特殊處理 (i.e. 把 - 當作 stdin),所以會使用到 /dev/stdin 這種特殊方式來當作 input:

./simple-rrd-merge.py input-a.rrd input-b.rrd | rrdtool restore /dev/stdin output.rrd

當然,要記得先把 SmokePing 停掉再跑會比較好 XD

生出的 RRD 檔案再覆蓋回去 (我是先備份起來,以免有意外...),然後再把 SmokePing 跑起來就可以了。

CloudFront 持續擴建:香港

Amazon CloudFront 在香港又增加機房了,這樣就是香港的第三個機房... 畢竟還是亞洲區頻寬成本相較起來比較低的地方 (也是很多東南亞國家會交換的地區),有對應的需求就可以擴充:「Announcing Third Edge Location in Hong Kong for Amazon CloudFront」。

不過話說回來,台灣 PoP 其實主要還是卡中華的頻寬,像這樣三個圖可以理解為那個瞬間 HiNet 與 CloudFront 之間的頻寬滿了 (分別是從 HiNet、TFNFET 去 ping AWS 官網自己用的 d36cz9buwru1tt.cloudfront.net,取自 smokeping.kkbox.com.tw 這邊):

不過還是有時候可以看到全部導走,是 capacity 突然滿掉嗎?這就有點奇怪了...

HiNet (Colocation) 對 CloudFlare 的速度

昨天才找人做完 CloudFlareSmokePing 資料,今天看到資料的時候覺得還蠻特別,跟一般預想的情況不太一樣...

CloudFlare 在台灣使用的人應該是 Plurkimages.plurk.com (透過 CNAME 指過去,應該是企業付費用戶) 以及一堆 Content Farm。

上面的圖是我們家在 HiNet 三重重新機房端 (203.69.67.x) 對 www.cloudflare.com.cdn.cloudflare.net 做出來的資料,這種 pattern 很上班時間用的網站的感覺?

多觀察幾天看看好了...

Archives