Tag: monitoring

Uptime Kuma：UptimeRobot 的 Open Source Clone

UptimeRobot 算是我自己還蠻喜歡用的監控服務，各種常見的類型都支援，像是 HTTP/HTTPS website 的監控，ICMP Ping 或是 TCP 的監控，另外也提供 SSL certificate 的監控。

前陣子找資料的時候找到 Uptime Kuma，這是香港的 Louis Lam 開發的 open source software，光看名字就懷疑是 UptimeRobot 的致敬版本，裝起來用過後就更確定...

差不多用了一個多月了，基本上功能還蠻完整的，我把他接到我自己的 Slack 以及 Pushover 上，就很方便的可以監控服務：

挑一個點：

用 GitHub Actions 做的監控服務 Upptime

是在 Twitter 上看到這個：

然後翻到 Upptime 這個 open source monitoring 工具，直接是用 GitHub Actions 提供的 schedule (cron job) 每五分鐘跑一次。這邊要注意的是，如果是 public repository 的話不受限制，如果是 private repository 的話會有機會把 quota 吃完：

Billing note: Upptime uses thousands of build minutes every month (approximately 3,000 minutes in the default setting). If you use a public repository, GitHub offers unlimited free build minutes, but if you use a private repository, you'll have to pay for this time.

依照說明是用 GitHub Actions、GitHub Issues、GitHub Pages 三個功能在運作：

  • GitHub Actions is used as an uptime monitor
  • GitHub Issues are used for incident reports
  • GitHub Pages are used for the status website

除了用這三個功能外，另外還是會每天塞一些資料回 git history 裡面：

We also record the response time once per day and commit it to git history. This way, we can graph long-term trends in your websites' response times by going through git commit history. We generate these graphs once every day, also using schedulers.

好像可以玩看看...

Amazon CloudWatch 推出 RUM (Real-User Monitoring) 的功能

看到 AWS 的 CloudWatch 推出 RUM (Real-User Monitoring) 的功能：「New – Real-User Monitoring for Amazon CloudWatch」。

從畫面截圖可以看到目前支援 javascript 的版本：

一定都會有的全站分析：

另外給了 client 端的一些情況：

然後可以針對比較慢的頁面進行了解：

然後有觀看頁面的記錄：

價錢是每 1M events 是 US$10，感覺不算便宜？

CloudWatch RUM is available now and you can start using it today in ten AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Stockholm), Asia Pacific (Sydney), Asia Pacific (Tokyo), and Asia Pacific (Singapore). You pay $1 for every 100K events that are collected.

功能上的競爭對手，可以想到 Datalog 有 RUM 產品，如果也是沒有 commit 的話是 US$0.65 (Per 1,000 sessions, per month)。

另外 New Relic 有 Browser Monitoring 的功能應該也是類似的東西，但價錢好像沒有單獨列出來。

Mixpanel 這邊 $25/month 的套餐可以吃 100K MTUs (monthly tracked users)，每個 MTU 可以吃 1K events，好像也可以做到類似的功能，隔壁 Amplitude 的話沒列出來...

不過就帳單的立場來說是方便不少...

AWS 區域間的連線測試

在 Hacker News 首頁上看到「AWS Latency Monitoring」這個，看起來是常態性在所有的機房都開機器一直測試蒐集資料，就可以直接拉出來看...

有常見的 p50 與 p99 資訊，對於在規劃架構的時候還蠻有用，在「mda590/cloudping.co」這邊可以看到他是用 Lambda 對 DynamoDB 的 endpoint 測試。

好像沒有 packet loss rate 的資訊，這個也蠻重要的...

AWS 推出 Grafana + Prometheus 服務

這兩則一起看比較順，AWS 推出了 Grafana 與 Prometheus 服務：「Announcing Amazon Managed Service for Grafana (in Preview)」、「Join the Preview – Amazon Managed Service for Prometheus (AMP)」，兩個都是 preview 等級，需要申請才能用。

Amazon Managed Service for Grafana 簡稱是 AMG，Amazon Managed Service for Prometheus 則是 AMP。

其中 Grafana 的部份是雙方合作，Grafana 這邊有發新聞稿出來：「Our new partnership with AWS gives Grafana users more options」。

主要還是方便為主，另外看起來也幫你搞定 HA + scalability 的問題了...

價錢的部份，AMG 是算人頭與 workspace，AMP 算空間與計算成本...

gp3 (Amazon EBS) 的 latency

昨天把手上所有的 Amazon EBS 從 gp2 換到 gp3 了：「Amazon EBS 的 gp3 可以用在開機磁碟了」，今天早上來看一下狀態，整體看起來是還 OK，不過有些地方值得注意的，像是標題寫到的 latency。

我抓了跑 GitLab 的機器來看，可以很明顯看到讀寫的 latency 都變高了：

但 AWS 又有提到這些數字資料有經過轉換，看起來是 gp2 與 gp3 的數字意義本來就不一樣，所以他必須想辦法轉換，所以也有可能是因為這個轉換導致的？

This graph has had transformations applied to it and will differ from what is natively found in CloudWatch. Due to this some functionality is reduced.

不過其他的數字倒是沒什麼變化，系統的負荷量其實也還好，就先丟著跑...

用 Monitorix 代替自己搞的 MRTG

先前我家裡的有線電視網路上我放了一顆 Raspberry Pi 跑各種分析，包括用 MRTG 抓流量與溫度，還有用 SmokePing 抓網路狀況。

前幾天系統掛了，本來以為是 SD 卡掛掉，換了一張上去發現還是開不了機，後來才發現是板子掛了，記得這張板子是當年還在 K 社時 zonble 送的，記得是當年一代剛出沒多久很紅，算了一下這台也跑了七八年了...

網路上找了一下找到了便宜的 Raspberry Pi 3，弄了回來後裝一裝，剛好最近接觸 Monitorix 後發現裡面已經有很多現成的設定設好，只要開起來就可以自己抓到...

現在的版本自帶 HTTP server，但我希望透過 nginx 轉進去 (包成 HTTPS)，這樣的話需要在 /etc/monitorix/monitorix.conf 裡加上：

url_prefix_proxy = https://rpi.gslin.com/

如果想要抓 Raspberry Pi 的電壓與溫度資訊，只要把檔案裡面的 raspberrypi = n 改成 raspberrypi = y 就可以了。

在 nginx 裡面把 /monitorix 與 /monitorix-cgi 轉進去，像是這樣的設髮：

    location /monitorix {
        proxy_pass http://127.0.0.1:8080/monitorix;
    }

    location /monitorix-cgi {
        proxy_pass http://127.0.0.1:8080/monitorix-cgi;
    }

比起自己搞 MRTG 設定一堆 shell script 簡單多了，cfgmaker 跟 indexmaker 用起來還是不順手。

不過 Ubuntu 上要 20.04 才有內建包進來，18.04 看起來沒有：「Ubuntu – Package Search Results -- monitorix」，目前還沒有在 18.04 上跑的需求，之後遇到再看看要怎麼處理...

AWS 在上個月推出的 CloudWatch Synthetics

AWS 在上個月推出的新功能，在 tab 上放的有點久：「New – Use CloudWatch Synthetics to Monitor Sites, API Endpoints, Web Workflows, and More」。

算是監控網站的服務，但不只是有沒有活著，而是包括整個網站 loading 的狀態。因為連 HAR 格式都支援了，所以可以抓很多特殊的時間點，從 screenshot 可以看出來：

價錢不算便宜，畢竟是要需要用瀏覽器抓出所有情境。如果以五分鐘跑一次來算，一個月就要 USD$10.3 左右的服務費用，另外還要加上 S3 與 Lambda 的成本 (不過這兩個服務的費用應該就只是零頭了)：

Pricing – As part of the AWS Free Tier you get 100 canary runs per month at no charge. After that, you pay per run, with prices starting at $0.0012 per run, plus the usual charges for S3 storage and Lambda invocations.

不過我記得類似的服務大概也都是這個等級的價錢，如果量夠大的話，我記得 HAR 的輸出有 open source solution 可以自己弄 EC2 instance 裝起來，應該會划算不少...

SoundCloud 推出的錯誤蒐集工具 Periskop

SoundCloud 推出的錯誤蒐集工具 Periskop，應該是取自捷克文的 Periskop (潛望鏡)：「Periskop: Exception Monitoring Service」。

與 Sentry 這類工具最大的差異在於是走 pull-based 架構，也就是跟 Prometheus 的設計相同 (Prometheus 也是 SoundCloud 發明的專案)。

就資源上來說，當 instance 上的錯誤滿天飛，而超過 log buffer 時，如果是以巨觀的角度來看，其實掉一些東西也沒關係：

另外也有提到一些缺點：

  • If a fatal exception occurs and the process dies, the exception won’t be collected. However, this can be mitigated by the reporting capabilities of orchestration services like Kubernetes or other forms of logging.
  • The pull model is not well suited for short-lived processes like scheduled jobs. This could be solved by the use of a push-based event gateway, although we haven’t yet had the need at SoundCloud, as it is usually more convenient to use logs to inspect failed jobs.

雖然 web (js) 與 mobile devices 的部份沒辦法被這個服務涵蓋，但一般來說會把面向使用者的服務另外拆開，所以不算是缺點... (像 Sentry 那樣通包，主要還是為了商業上的規劃)

目前看起來還缺一些東西 (就我想用的需求)，可以先觀察一下會怎麼發展，另外一邊 Sentry 也在朝 Python 3 進行，也可以嘗試看看...

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務，當有任何新的 SSL certificate 發出時就會通知：「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來：

Business 與 Enterprise 版本的可以設定要通知誰，Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的)：

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了，這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用)，可以搜尋有哪些 domain：「Certificate Transparency Monitoring」。