您好！最近又开始跑一些服务器（nginxplayground,messwithdns,dnslookup），所以一直在思考监控的问题。最初我并不完全清楚如何监控这些网站，所以我想我会尽快写下我是如何做到的。我根本不打算谈论如何监控大型、严肃的关键任务网站，只讨论微小的不重要的网站。目标：几乎不花时间在运营上我希望网站大部分时间都在运行，但我也不希望在持续运营上花时间。我最初对运行服务器非常谨慎，因为在我的上一份工作中，我正在为一些关键服务进行24/7轮班，我的印象是“服务服务器”意味着“在凌晨2:00被叫到修复服务器”和“有很多复杂的仪表板”。所以有一段时间我只做静态站点，所以我不必担心服务器。但最后我意识到，我要编写的任何服务器的风险都很低，即使它们偶尔宕机2小时也没什么大不了的，我只需要设置一些非常简单的监控来帮助保持他们跑。没有监控很糟糕起初，我根本没有为我的服务器设置任何监控。这样做的结果是可以预见的：有时网站会崩溃，直到有人告诉我我才发现！第1步：正常运行时间检查器第一步是设置正常运行时间检查器。那里有很多这样的东西，我目前正在使用updown.io和uptime机器人。我更喜欢updown的UI和定价结构（它是按请求而不是按月收费），但是uptimebot有一个更慷慨的免费层。他们将：检查网站是否正常运行，如果出现故障，它会通过电子邮件通知我我发现电子邮件通知对我来说是一个很好的通知级别，如果网站出现故障，我会很快发现，但不会唤醒我起床或做其他事情来打扰。第二步：端到端的健康检查接下来，我们来谈谈“检查网站是否健康”是什么意思。起初，我只是将我的一个健康检查端点变成了一个无论如何都会返回200OK的函数。这非常有用-它告诉我服务器已启动！但不出所料，我遇到了问题，因为它没有检查API是否确实在工作——有时健康检查成功，即使服务的其他部分实际上已进入不良状态。所以我更新了它以实际发出API请求并确保它成功。我所有的服务都做的很少（nginxplayground只有一个端点），所以很容易设置一个运行状况检查，它实际上运行了大部分服务应该做的事情。这是nginx游乐场的端到端健康检查处理程序的样子。它非常基本：它只是（向自己）发出POST请求，并检查该请求是成功还是失败。funchealthHandler(whttp.ResponseWriter,r*http.Request){//以`healthcheckJSON`为主体向localhost:8080发起请求//如果成功，返回200//如果失败，返回500客户端:=http.Client{}resp,err:=client.Post("http://localhost:8080/","application/json",strings.NewReader(healthcheckJSON))iferr!=nil{log.Println(错误）w.WriteHeader（http.StatusInternalServerError）返回}如果resp.StatusCode！=http.StatusOK{log.Println（resp.StatusCode）w.WriteHeader（http.StatusInternalServerError）返回}w.WriteHeader（http.StatusOK）}健康检查频率：每小时一次现在，我的大部分健康检查每小时运行一次，有些是每30分钟一次。我每小时运行一次，因为updown.io的定价是根据健康检查的数量来计算的，我正在监控18个不同的URL，并且我希望将我的健康检查预算保持在至少5美元/年的水平。我可以花一个小时来发现其中一个站点已关闭-如果出现问题，我不能保证很快就会修复它。如果我可以更频繁地运行它们，我可能会每5-10分钟运行一次。第3步：第3步：如果健康检查失败，自动重启我的一些站点在fly.io上，fly有一个相当标准的功能，我可以在其中为服务配置HTTP健康检查，如果健康，如果检查失败，则重新启动服务。“经常重启”是一个非常有用的策略来覆盖一个我还没有修复的错误，有一段时间nginxplayground有一个进程泄漏，nginx进程没有被杀死，所以服务器一直在内存不足。通过了健康检查，结果，这种情况每隔一天左右就会发生一次：服务器内存不足健康检查开始失败它重新启动一切正常，几个小时后整个故事再次重复最终，我开始实际上修复它进程泄漏，但很高兴有一个解决方法来在我拖延修复错误时保持运行。这些用于决定是否重启服务的健康检查运行得更频繁：大约每5分钟一次。这不是监控大型服务的最佳方式可能很明显，我在一开始就说过，但是“编写HTTP健康检查”并不是监控大型复杂服务的最佳方式。但我不会深入讨论，因为那不是本文的主题。到目前为止效果很好！我最初在3个月前的4月写了这篇文章，但我等到现在才发布它以确保整个设置正常工作。这产生了巨大的变化——在我遇到一些非常愚蠢的停机问题之前，该网站在过去几个月中的正常运行时间达到了99.95%！
