一个小包装器，可以方便地将healthcheck服务器添加到sanic应用程序中
sanic-healthchecks的Python项目详细描述
SANIC健康检查
Sanic HealthChecks使您可以轻松地在 与实际的sanic应用程序不同的线程。
安装
pip3 install sanic-healthchecks
健康检查示例
fromsanicimportSanicfromsanic.responseimportjsonfromsanic_healthchecksimportstart_healthcheck_server,healthcheck_responseAPP=Sanic()asyncdefhealthcheck_handler(_):data={"status":"ok"}returnhealthcheck_response(data)@APP.route("/")asyncdefroot(_):returnjson({"example_of":"a very simple healthcheck"})if__name__=="__main__":start_healthcheck_server(healthcheck_handler)APP.run(host="0.0.0.0",port=8000)
SANIC应用程序现在将对另一个端口上的运行状况检查做出响应：
⇒ curl http://localhost:8000 -i
HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: 5
Content-Length: 17
Content-Type: application/json
{"hello":"world"}
⇒ curl http://localhost:8082 -i
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 16
Date: Sun, 03 Mar 2019 20:55:52 GMT
Server: Python/3.7 aiohttp/3.5.4
{"status": "ok"}
更改日志
许可证
但为什么呢？
为什么要在不同的线程上运行健康检查，而不是在实际的sanic服务器上创建另一个端点？
好问题，网络陌生人，我有几个答案。
通过分别进行健康检查，我们将 关注点。因为sanic是在一个线程上运行的，所以任何时候 响应健康检查，实际上您正在从 为应用程序所在的实际请求供电的事件循环 服务。同样，实际应用程序的状态也不会影响 健康检查。在这个问题上有一些争论。
有人说如果你的web服务不能响应你的 healthcheck probe，那么服务不应该被认为是健康的。我可以 完全理解并尊重这个观点，如果这就是你的感受， 那就没有必要用健康检查了。
另一方面，如果你和我一样，你已经说服自己 健康检查的目的不仅仅是确定服务是否能够响应，而且 以确定您的服务是否拥有下游所需的一切 依赖关系。如果您的请求花费了很长时间， 活性探针超时，这可能意味着你的服务不健康， 但它也可能是具有长时间运行请求的服务的症状。
因为我们可以在不同的web服务器上运行健康检查，所以 检查所有下游依赖项（如数据库）的能力 以及其他服务。这有助于缩小为什么 服务可能处于降级状态。
我甚至认为响应延迟的增加可能是 用于自动缩放服务的度量。把它当作 杀死实例的方法使得如何解释 延迟增加。
在另一台服务器上运行健康检查的另一个重要原因是 您可以为此新服务器分配不同的端口。这很有价值，因为 您的健康检查中可能包含不应该包含的调试信息 与能够消费 服务通过在不同的端口上进行健康检查，可以确保映射 not的负载平衡器包含此健康检查端口。
欢迎加入QQ群-->： 979659372
