监控微小的 Web 服务!

监控微小的 Web 服务!插图

最近开始运行更多的服务器 (nginx playground,搞砸了dns,dns查找),所以我一直 考虑监控。

最初对我来说,如何监控这些网站并不完全清楚,所以我 想快速写下我是怎么做到的。

我不打算谈论如何监控大型严重任务关键型 网站,只有很小的不重要的网站。

目标:在运营上花费大约 0 时间

我希望这些网站大部分都能正常工作,但我也想花费大约 0% 的 我在正在进行的操作上的时间。

我最初对运行服务器非常谨慎,因为在我的上一份工作中,我 在一个247一些关键服务的待命轮换,在我看来“是 负责服务器“的意思是”凌晨 2 点起床修理服务器“和 “有很多复杂的仪表板”。

所以有一段时间我只做静态网站,这样我就不必思考了 关于服务器。

但最终我意识到,我将要编写的任何服务器都将是 赌注非常低,如果他们偶尔下降 2 小时,这没什么大不了的,而且 我可以设置一些非常简单的监控来帮助它们保持运行。

没有监控很糟糕

起初,我根本没有为我的服务器设置任何监控。这有 极其可预测的结果 – 有时网站坏了,我没有找到 直到有人告诉我!

第 1 步:正常运行时间检查器

第一步是设置正常运行时间检查器。有很多这样的 在那里,我现在使用的是 updown.io 和正常运行时间机器人。我更喜欢updown的用户界面和定价结构(它是按请求而不是月费),但正常运行时间 机器人有一个更慷慨的免费套餐。

这些

  1. 检查网站是否已启动
  2. 如果它出现故障,它会给我发电子邮件

我发现电子邮件通知对我来说是一个很好的水平,我会发现很漂亮 如果网站宕机,但它没有吵醒我或任何东西,很快就会。

第 2 步:端到端运行状况检查

接下来,让我们谈谈“检查网站是否正常运行”的实际含义。

起初,我只是将我的一个运行状况检查端点设置为无论如何都会返回的函数。200 OK

这有点有用——它告诉我服务器已打开!

但不出所料,我遇到了问题,因为它没有检查 API 实际上正在工作 – 有时健康检查成功了,即使 服务的其余部分实际上已经进入了糟糕的状态。

因此,我更新了它以实际发出真正的 API 请求并确保它 成功。

我所有的服务都很少做一些事情(nginx playground 只有 1 endpoint),因此设置实际运行的运行状况检查非常容易 通过服务应该执行的大多数操作。

下面是 nginx playground 的端到端运行状况检查处理程序的外观 喜欢。这是非常基本的:它只是(对自己)发出另一个 POST 请求,并且 检查该请求是成功还是失败。

func healthHandler(w http.ResponseWriter, r *http.Request) {
	// make a request to localhost:8080 with `healthcheckJSON` as the body
	// if it works, return 200
	// if it doesn't, return 500
	client := http.Client{}
	resp, err := client.Post("http://localhost:8080/", "application/json", strings.NewReader(healthcheckJSON))
	if err != nil {
		log.Println(err)
		w.WriteHeader(http.StatusInternalServerError)
		return
	}
	if resp.StatusCode != http.StatusOK {
		log.Println(resp.StatusCode)
		w.WriteHeader(http.StatusInternalServerError)
		return
	}
	w.WriteHeader(http.StatusOK)
}

运行状况检查频率:每小时

现在,我每小时进行一次大部分健康检查,有些每 30 次进行一次 纪要。

我每小时运行一次,因为 updown.io 的定价是按健康检查计算的,我是 监控 18 个不同的 URL,我想保持我的健康检查预算漂亮 最低为 5 美元/年。

花一个小时来发现其中一个网站已经关闭似乎是可以的 我——如果有问题,不能保证我会解决所有问题 反正很快。

如果可以更频繁地运行它们,我可能会每 5-10 分钟运行一次。

步骤 3:如果运行状况检查失败,则自动重启

我的一些网站在 fly.io 上,fly有一个非常标准的功能,其中 我可以为服务配置 HTTP 运行状况检查,并在 运行状况检查开始失败。

“经常重启”是一个非常有用的策略,可以掩盖我没有的错误 开始修复 – 有一段时间,nginx playground 有一个过程 泄漏,进程未终止,因此服务器保持 RAM 不足。nginx

通过运行状况检查,其结果是每天左右都会发生以下情况:

  • 服务器 RAM 不足
  • 运行状况检查开始失败
  • 它重新启动
  • 一切都很好
  • 几个小时后再次重复整个传奇

最终,我开始实际修复流程泄漏,但很高兴 有一个解决方法,可以在我的时候让事情保持运行 拖延修复错误。

这些运行状况检查用于决定是否更频繁地重新启动服务:每 5 分钟左右运行一次。

这不是监控大型服务的最佳方式

这可能是显而易见的,我一开始就已经说过了,但是“写 一个 HTTP 运行状况检查“不是监控大型综合体的最佳方法 服务。但我不会深入探讨,因为这不是这篇文章的内容。

到目前为止,它运行良好!

我最初是在 3 个月前的 <> 月写这篇文章的,但我等到现在 发布它以确保整个设置正常工作。

它产生了很大的不同——在我遇到一些非常愚蠢的事情之前 停机问题,现在在过去的几个月里,这些站点一直在运行 99.95%的时间!

© 版权声明
THE END
喜欢就支持一下吧
点赞13赞赏 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容