詹姆斯·特恩布尔
监控将系统和应用程序生成的指标转换为对应的业务价值。你的监控系统会将这些指标转换为衡量用户体验的依据，该依据为业务提供反馈，以确保为客户提供了所需的产品。同时该依据还提供了对技术的反馈，指出哪些组件不起作用或者导致服务质量下降。 实际上，监控系统有以下两个“客户”： ·技术 ·业务
你可以通过监控来了解技术环境状况，还可以帮助检测、诊断和解决技术环境中的故障和问题（尤其是在影响用户之前）。
监控提供了大量的数据，帮助洞察关键的产品和技术决策，并衡量这些项目是否成功。监控也是产品管理生命周期以及与内部客户关系的基础，有助于验证项目资金是否得到充分利用。如果没有监控，那么最好的情况是没有问题发生，最糟糕的情况则是问题发生了但没有被发现。
业务是监控系统的第二个客户。监控系统是为了支持业务，并确保业务持续开展。监控可以提供报告，使企业能够进行良好的产品和技术投资，还有助于企业衡量技术带来的价值。
监控是管理基础设施和业务的核心工具。监控也是必需的，应该和应用程序一起构建和部署。没有监控，你将无法了解你的系统环境、进行诊断故障、制定容量计划，也无法向组织提供系统的性能、成本和状态等信息。
这个反模式的一个常见形式是虽然监控了主机上的服务状态，但不够准确。例如，通过检查HTTP 200状态码可以监控Web应用程序是否正常运行，它会告诉你应用程序正在响应请求，但并不会反映出是否返回了正确的数据。
使用静态阈值——例如，如果主机的CPU使用率超过80%!就(MISSING)发出警报。这种检查通常是不灵活的布尔逻辑或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围，这种模式没有考虑到大多数复杂系统的动态性。
任何给定系统的阈值都是错误的，因为所有系统都略有不同，并且在任何给定时刻也都是错误的，因为系统在经历不断变化的负载和其他情况。
我们需要查看数据窗口，而不是静态的时间点，需要使用更智能的技术来分析指标和阈值。
Google的四个黄金指标来自Google SRE手册，它们采用与USE类似的方法，指定要监控的一系列通用指标类型。此方法中的指标类型主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分： ·延迟：服务请求所花费的时间，需要区分成功请求和失败请求。例如，失败请求可能会以非常低的延迟返回错误结果。 ·流量：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务。 ·错误：请求失败的速率，要么是HTTP 500错误等显式失败，要么是返回错误内容或无效内容等隐式失败，或者基于策略原因导致的失败——例如，强制要求响应时间超过30ms的请求视为错误。 ·饱和度：应用程序有多“满”，或者受限的资源，如内存或IO。这还包括即将饱和的部分，例如正在快速填充的磁盘。
要建立一个出色的通知系统，需要考虑以下基础信息： ·哪些问题需要通知 ·谁需要被告知 ·如何告知他们 ·多久告知他们一次 ·何时停止告知以及何时升级到其他人
最重要的是，你需要考虑通知内容。通常当出现问题或者有事件需要你注意时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要。让我们通过一个示例来看看通知内容为什么很重要。以下是Nagios关于磁盘空间的通知。
为通知添加上下文。通知应包含组件的其他相关信息。 ·仅发送有意义的通知。
Prometheus专注于现在正在发生的事情，而不是追踪数周或数月前的数据。它基于这样一个前提，即大多数监控查询和警报都是从最近的（通常是一天内的）数据中生成的。Facebook在其内部时间序列数据库Gorilla的论文中验证了这一观点。Facebook发现85%!的(MISSING)查询是针对26小时内的数据。Prometheus假定你尝试修复的问题可能是最近出现的，因此最有价值的是最近时间的数据，这反映在强大的查询语言和通常有限的监控数据保留期上。
Prometheus还有一个推送网关（push gateway），可用于接收少量数据——例如，来自无法拉取的目标数据（如临时作业或者防火墙后面的目标）。
冗余和高可用性侧重弹性而非数据持久性。Prometheus团队建议将Prometheus服务器部署到特定环境和团队，而不是仅部署一个单体Prometheus服务器。如果你确实要部署高可用HA模式，则可以使用两个或多个配置相同的Prometheus服务器来收集时间序列数据，并且所有生成的警报都由可消除重复警报的高可用Alertmanager集群来处理
DNS服务发现允许你指定DNS条目列表，然后查询这些条目中的记录以发现目标列表。它依赖于A、AAAA或SRV DNS记录查询。
Pushgateway接收指标，然后作为目标被抓取，以将指标提供给Prometheus服务器。你可以将其视为代理服务
我们可以利用Kubernetes DaemonSet[插图]控制器在集群中的每个节点上自动部署pod。
DaemonSet使用toleration（容忍）确保pod在所有节点上运行，可能也包含主节点。它非常适合监控或日志代理等项目。让我们看一下DaemonSet的元素。
hostNetwork、hostPID和hostIPC，以指定实例的网络、进程和IPC命名空间在容器中可用。这些都是潜在的安全风险，你必须考虑是否可以承担此风险。如果
readiness探针可确认应用程序正常运行。这意味着，在将容器标记为可用并发送流量之前，HTTP GET可以连接到端口9100上的/metrics路径。其余设置控制探针的行为，在检查准备就绪之前，它将等待10秒（initialDelaySecond），然后，它会每隔2秒（periodSeconds）检查一次。如果探针在10秒（timeoutSeconds）后超时超过5次（failureThreshold），则容器将被标记为Unready。
我们还会控制Prometheus仅抓取具有特定注解prometheus.io/scrape（设置为'true'）的端点。然后，我们使用内置的Kubernetes服务发现来查找端点，并将它们作为Prometheus的潜在目标返回。
Prometheus服务器在Kubernetes内部运行，因此我们能够以最少的配置自动获取与特定角色匹配的Kubernetes目标。节点、pod、服务和入口都有不同的角色，由参数role指定，我们要求服务发现返回所有Kubernetes端点。endpoints角色[插图]返回服务的所有已列出端点的目标，每个端点地址的每个端口都是一个目标。如果端点也是由pod提供，就像Node Exporter服务那样，那么任何其他容器端口也会作为目标被发现。在示例中，我们只暴露了9100端口。
有很多种方法可以监控Kubernetes本身，其中包括开源Kubernetes生态系统中的工具，如Heapster和Kube-state-metrics