Day 3：让我看看你状态正不正常啊 - 架设 status page

昨天提到了有关监控的议题，监控服务的其中一个目的是为了在系统发生错误的时候可以即时的通知相关人员，其中一个常见的手法便是架设 status page。

什麽是 status page

那麽 status page 的作用是什麽呢？简单来说它就是一个告诉我们网站是否正常运作的一个服务。server 端会定期的对网站发出请求，并且依据收到的回覆来判断现在网站是否有正常在运作，可能的条件有 http 的 status code、回应时间或是回覆是否包含特定内容等。

而 server 在收到这些资讯之後会把他们收集下来，配合一个前端的页面让使用者方便浏览，只要打开浏览器就能看到服务在某段时间内的运作情形。有些甚至还会公告有关每次意外的说明，让使用者了解这些意外对他们造成的影响。现在市面上也许多服务皆有提供 status page，具体的例子有 GitHub、GCP 等等。

（GitHub 的 status page）

（GCP 的 status page）

（上图为针对 GKE 的一份意外报告，里面提供的说明包含影响的时间、原因跟范围，并且提供了暂时的解决方法，如果有的话）

如何架设 status page

该如何架设 status page，其实网路上可以找到不少现成的解决方案，像是 Atlassian 的 Statuspage、PagerDuty 等等，比起自己架设，使用这些云端的服务其实会更加可靠，毕竟 status page 对可用性的要求特别高，不然在故障发生时它自己也挂掉的话（如果把 status page 跟要监控的服务放一起或很近就很可能发生），我们就无法得知服务状态或是收到通知了。

今天我会挑选一个免费跟一个付费（但很便宜）的方案来展示，如何快速的帮自己的服务架设 status page。

Cloudflare Worker - Status Page

第一个选项是 Cloudflare Worker - Status Page，这名字还真够长的。它是透过 cloudflare worker 架设的，所以并不需要自己准备 server 来放，可以说是非常方便的选项了。

需求

GitHub 帐号：不是必要，但因为作者是使用 GitHub Actions 来自动部署 worker，所以使用 GitHub 存放 code 跟设定是最方便的选项。
Cloudflare Worker 帐号（按此注册）：毕竟网站就是使用 Cloudflare Worker，所以这帐号还是必要的。

如何架设

其实 README 里面就写得很清楚了，若是我这边写的不清楚请去参考它吧。

首先我们打开 GitHub repo，在 README 的 Getting started 区段应该可以看到一颗 Deploy with Workers 的按钮，放心地给他按下去。

之後会跳转到这个部署 worker 的页面，首先我们需要授权，让 Cloudflare 可以透过 GitHub Actions 来部署。

那个 Authorize Workers 的按钮戳下去之後，会要求你输入一次密码，然後跳回来之後你应该会看到以下画面。其实这边我很纳闷为什麽他就没有再接续刚刚上一张图的步骤了...如果读者知道为什麽的话请告诉我。我的作法就是...再按一次。

下个步骤是需要设定 Worker account id，打开你的 Workers dashboard，在画面右边应该可以看到 Account ID。

然後还需要 API token，打开你的 profile，点上面的 Create Token 按钮。之後需要设定这个 token 的权限，我是直接使用 Edit Cloudflare Workers 这个预设模板。

填妥之後，应该已经有一个 status page 的 repo 被 fork 到你的帐号底下了。把它 clone 下来之後打开专案根目录底下的 config.yaml，我们需要修改几个设定：

settings.url：如果有做 Slack 通知的话，需要修改这项设定，会是你 status page 的 URL，以我的为例，就会是 https://status-page-production.bogay.workers.dev，最前面是 worker 名称，後面是我的帐号设定的 sub domain。
monitors：这底下填需要监控的对象，至少填上 id、name 跟 url 就行，其中 name 是拿来显示在前端用的。

然後如果你是使用 free plan 的话，还需要修改 wrangler.toml 这个档案，降低 worker 监控的频率，才不会超过 Cloudflare 每天 1000 次的免费 KV 写入次数上限。

找到 cron 那行，把它的值改成 ["*/2 * * * *"]，这样它会每两分钟发一次请求，我的话是把它改成五分钟了。

另外，在同一个档案底下，name 这个值定义了 worker 的名称，预设是 cf-workers-status-page，我自己觉得太长所以也把它改掉了。改完之後前面几行会长这样：

name = "status-page"
workers_dev = true
account_id = ""
type = "webpack"
webpack_config = "node_modules/flareact/webpack"

[triggers]
crons = ["*/5 * * * *"]

按照原本 repo 里面 README，这时候 push 上去触发部署就可以了，但没意外的话你应该会看到以下错误：

Error:  Your configuration file is missing the field ["kv-namespace id"] which is required to publish your worker!
 Your configuration file is missing compatibility_date, so a distant past date is assumed. To get the latest possibly-breaking bug fixes, add this line to your wrangler.toml:

    compatibility_date = "2021-09-16"

 For more information about compatibility dates, see: https://developers.cloudflare.com/workers/platform/compatibility-dates

原来 Cloudflare 为了确保官方 runtime 的更新不要影响到已经部署下去的 worker，还需要我们设定 Compatibility Dates，帮助他判断要使用的版本（详细说明可以参照官方文件），因此，我们需要在 wrangler.toml 里面再新增一行 compatibility_date = "2021-09-17"，日期的部分填上部署当天的日期就行。

更新完之後，你的最前面几行应该会像这样：

name = "status-page"
workers_dev = true
account_id = ""
type = "webpack"
webpack_config = "node_modules/flareact/webpack"
compatibility_date = "2021-09-16"

这时候再 trigger 一次就应该会正常部署了，若是 GitHub Actions 都没有反应，请确定你是推到 main branch 上面，且有把 GitHub Actions 打开（预设应该是关闭的）。

接下来，连上你的 work，应该就能看到你的 status page 被架起来啦。