03 - Uptime - 掌握系统的生命徵象 (1/4) - 我们要观测的生命徵象是什麽？

Uptime - 掌握系统的生命徵象 系列文章

• (1/4) - 我们要观测的生命徵象是什麽？
• (2/4) - 使用 Heartbeat 收集系统生命徵象数据
• (3/4) - 透过 Kibana 观看心电图及设定警报
• (4/4) - 使用合成监控 (Synthetics Monitor) 从使用者情境验证服务的运作状态

本篇学习重点

• 我们要监控系统的 uptime 时，我们的目的是什麽？什麽是系统的生命徵象？
• 在开始设定 Heartbeat 来设定监控之前，我们要考虑的面向有哪些？

系统的生命徵象

当我们要观察系统的生命徵象时，Elastic Stack 的解决方案中，可以使用 Heartbeat 周期性的检查系统的可用性 (availability)，不过在这边我们要先想一下，什麽是系统的生命徵象？代表的意义是什麽？以下一边透过以"人的生命徵象"来想像，另一边对应到"系统的生命徵象"来思考：

• 还有没有心跳： 也就是系统的主机是不是活着？是不是 ping 了之後能得到回应，当得到回应时，代表系统的主机是活着。
• 心跳的速率是否正常： ping 系统时，回应的速度如何？是否在我们接受的合理范围之内？有没有发生 timeout？
• 还有没有意识能回话： 要能回话代表服务要能正常运作，所以我们应该透过应用程序所提供的 health check API 来进行确认，以认服务是否能正常的回应。
• 回话的速度： 透过 health check API 时，我们可以观察 response time，也就是系统的回覆速度，是不是符合我们的期待？
• 回话是否正常： 我们对於 health check API 的回应结果，是否符合我们的预期？如果只是 HTTP 200 的话，其实有机率不代表是我们系统的回覆，(乔叔就曾经发生网路设定被误改，因此请求被导到别的服务上，拿到的回应是 HTTP 200，但是 response 内容并非我们预期的)，回应的内容应该要是我们期待的结果。
• 其他活着的定义： 每个人对於活着的定义其实多少会有不同，有些人认为行屍走肉不算活着 XD，这边提供一个思考的观点，这个系统提供的是什麽服务，这个服务哪些部份是最重要的，一但这些功能停摆时，代表这个服务是死的了，因此这边可以想像一下，如果是个有相依於 Database 的服务，如果 DB connection 无法正常连线的时候，这个服务算是活着的吗？另外也应该要回归商业面，是否有哪些最重要的功能，如果这些功能无法正常运作时，可以判定服务是死的？例如 auth service，如果他提供 issue token 或是 validate access token 的 API 是死的，是不是代表整个服务其实就是死的了呢？这个议题其实是 health check API 的设计方式，你要 check 的东西到底是什麽，是不是要包含到第三方相依服务的状态？这个题目在这边不会深入探讨，但是绝对会是你们团队在建立 uptime monitor 之前会要考虑清楚的 (其实是服务开发时就要定义好的)。

监控系统生命徵象时，你应该要考虑的面向

部署的方式，是不是够安全可靠？

首先部署 Heartbeat 的最主要原则：当系统挂掉的时候，负责监测的 Heartbeat 不应该跟着挂掉。

因此官方文件就有直接提出，不建议使用 sidecar 的这种方式来部署 heartbeat，建议要部署成为独立的服务，以降低主要的系统发生问题时，Heartbeat 也同时出问题的可能性。[1]

什麽是 sidecar?

sidecar 的中文是『边车』，也就是把程序以另外的 process 挂载在主要的 process 或是 container 旁边，避免直接运作在主 process 之中，一方面是可以更好的模组化、布署的方式也能更容易标准化并重覆利用，另一方面是减少与主程序的相依性，不过实际运作上还是会有一些资源是共用的，例如安装在同一台主机上、使用同样的 disk，使用同样的 network 环境…等。

监控不只从最外面的 Internet 来监控，从 client 端一路到服务所运作的服务器，这条路线中你还要从哪一层切入？

一般我们要监控服务时，最直接会想到从外层，也就是 Internet 去监控，但试想，如果今天外层发现服务不通的时候，但你从服务的 local 端发现是好的时候，中间的这些网路问题，要如何能更有效的盘查与找出问题呢？

我们重新检视从 Client 端，一路到服务运作的 Server 主机中，网路会经过哪些路径，对外的服务一般来说会经过 CDN，若是内部的服务也可能跨过多个 VPN，因此在这样有多段网路环境的路线当中，建议的做法是：CDN 内、外都要架设 heartbeat，不同 VPN 的网段内也要有各自的 heartbeat，透过一层一层的记录，能够最快速的帮我们在发生问题的当下，判断是在网路的哪一层发生问题。

是否已盘查清楚系统运作的网路架构，你要从哪些地方监控才足够？

当我们的服务对外有经过 CDN 时，CDN 的架构上会透过许多的 POPs (points of presence) 也就是散落在世界各地的节点，来处理快取，并且让 client 能最近、也就会最快速的取得需要的内容，所以如果有使用 CDN 时，一般也就会建议要在多个不同的地区布建 Heartbeat，收集各个不同地点是否能正常的存取服务的数据。

是否有布署在另一个 Data Center 的备援服务？在多个 Data Center 时，除了监控自己，也应该互相监控。

如果有不同的 Data Center时，除了建议一定要在各个 Data Center 内部布署自己的 Heartbeat，另外在设定监控时，除了监控自己 Data Center 的服务之外，也应该顺便监控另个 Data Center 的服务，这样跨 Data Center 时的网路环境会多透过 Internet，也会是出问题时能作为交互比对的参考资讯。

以上是建立监控之前，需要先思考及评估的部份，在经过这些评估及规划之後，下一篇我们将透过 Elastic heartbeat 的设定，来收集这些我们需要取得的资料。

参考资料

1. Elastic 官方文件 - Ingest uptime data

查看最新 Elasticsearch 或是 Elastic Stack 教育训练资讯: https://training.onedoggo.com
欢迎追踪我的 FB 粉丝页: 乔叔 - Elastic Stack 技术交流
不论是技术分享的文章、公开线上分享、或是实体课程资讯，都会在粉丝页通知大家哦！