本文转载自微信公众号“黑光科技”，作者helight。转载本文请联系黑光科技公众号。前言对于API管理来说，做好API监控是非常重要的。前段时间看了一本Nginx社区出的API流量管理的书。感觉书里的内容还不错。结合自己在实际应用中的经验，今天整理一下API监控的一些方法。看完原文，感觉这些国外的技术人做事之前还是很有条理的。另外，我最近也在看一本关于社区管理的书，里面把社区研究的层次划分为3个层次：Frameworks，Theory（理论），Models。下面我来简单说明一下。感觉这个方法论很实用，感觉可以用在很多地方。框架指的是大方向，明确各个部分之间的关??系，让大家在这个框架下达成共识；理论是一个比框架更清晰的概念，是对框架下各个模块或子模块的进一步细化，或者是针对具体事物的技术性或原则性的解释和指导；模型更具体，解释和指导解决特定事件。研究人员使用模型来检验基于理论的各种假设，并且可以使用各种工具来开发模型，包括数学、统计技术等。这是一个做事的框架体系，每个人在思考和做事的时候都应该有这样一个模型。所以今天在梳理API监控的内容时，也是想遵循这样一个基本的思路。API管理的基础框架我觉得API管理有几个方面：API基础开发管理（API设计、接口元信息、调用管理、测试、限流、路由管理等）API基础监控（流量、时间-消耗、错误代码、可用性监控等）API安全控制（STL、认证、证书等）API高级特性（可扩展性、缓存、缩放、性能分析、流量放大分析等）来自于基础开发管理API到高级功能分层管理，从基础可用性到安全可控。API的基础设计也是一件很复杂的事情，想要设计好一个API并不是那么容易的。我打算以后写一个系列来介绍这部分。今天的重点是API的基本监控。API监控层面API监控也符合上述理论，具有理论框架。API的监控首先是分级的，就是为了实现监控。分层之后，很多东西就会清楚，无论是理解上，还是如何实现上。再看看API监控是怎么分级的。基础架构监控服务级别监控业务级别监控基础架构监控这里主要关注硬件cpu、磁盘、内存等的可靠性，以及操作系统、队列服务等组件的可靠性。上一篇也介绍了如何快速分析定位系统中的这些问题。这些是稳定服务运行的基础，因此监控这些设施是一种常见的做法。这不仅是在API监控上，如果要做完整的API监控，最后这一部分当然是少不了的。服务级别监控在服务级别监控中，主要关注服务组件是否健康可靠，如监控数据读写、文件创建、基本服务生存、服务调用延迟、服务性能等。业务级监控最终是业务级监控。不同的应用场景和业务有不同的监控内容。比如你想监控购买金额、登录用户数、发送消息数、收到礼物数、出行路线等，不同的业务场景需要监控的指标是不同的，以及这部分非常具体。API监控的常用监控指标虽然上面提到的第三层监控有很多特点，但是在监控内容上还是有一些共性的。所以这里介绍一些常用的监控指标类型。Rate速率是一个常用的监控指标，数据发送速率，增加速率，访问速率，调用速率等，这个指标是用来监控你的系统的服务能力的。一般来说，指标越大，服务能力越强。请求延迟指标往往与上述速率指标有关。一般来说，这个值越小，你的服务性能越好。这个指标一般可以在API网关上采集，也可以在客户端上采集。错误率和系统错误的监控对于一个系统来说是非常重要的，不同错误代码的统计和计数也是如此。有了这些指标的监控，系统的可用性监控也就有了。单纯看前两个指标也是有问题的，因为有的时候系统的访问速率和请求延迟会在系统出现故障时表现良好，但实际上有很多错误请求和错误返回，比如系统Fasterror返回，大量错误请求等。突然的配额过载也是一个需要监控的点。很多情况下，瞬时过载，也会暴露出一些系统潜在的问题。指标的平均值是监控系统稳定性、服务能力和服务特性所必需的。很多时候不仅是当前状态值，还有最近5分钟、10分钟、15分钟等服务指标的平均值。API监控常见的监控模型都是铺垫。这部分其实就是我今天要分享的内容。我认为这部分更有趣。上面列举了那么多指标类型，每种类型在实际执行的时候都会衍生出很多指标，那么问题来了，我们在分析系统问题的时候是不是一定要看所有的指标呢？这个估计很难，怎么办呢？说到这个问题，让我想起了股市中的一种做法：指数。说到这里，如果你知道所谓的指数，你应该知道我想说的是什么。股票指数通过对股票市场中一些圈定的股票指标，采用特殊的算法计算出一个值来表示股票市场的好坏。比如美国有纳斯达克综合指数，中国有上证综指和深证综指。所以我这里介绍的所谓监控模型也是类似的思路，只是这个模型目前是其他公司或者组织整理出来的，不是我原创的。USE模型这里介绍第一个模型：USE（Utilization、Saturation和Errors）。该模型由BrendanGregg最先提出，目前正在Netflix上架，作者是著名的?书，超过1300页的大部头。他提到，他提出这个模型是为了让大家能够快速定位和解决问题，而不至于被细节淹没。Gregg说通过问3个问题，你应该可以对你的系统有一个很好的了解：利用率是多少？饱和度如何？什么是错误或错误率？O等的利用率是多少，是否免费。饱和度是业务或请求等待系统处理的程度，表示是否超过当前系统的最大容量。ErrorsError或者错误率也比较好理解，就是系统在处理这些服务或者请求的时候发生的错误事件。关于这个模型更详细的解释，可以去他的个人网站：http://www.brendangregg.com/usemethod.html。其实也是这样的。在之前翻译的文章中，我介绍了如何定位Linux系统的问题。其实大部分方法都是这样的。也许你说这和API监控有关？Gregg最早的目标确实是系统指标分析，但实际上这种方法模型可以应用于系统线程分析和网络请求分析。但从根本上来说，它仍然是一个主要针对基础设施的监控模型。RED模型RED（Requests,Errors,andDuration），这个模型是TomWilkie在2015年提出的，它是USE模型的升级，USE模型在单机模型中会更容易使用，但是目前在分布式环境和微服务环境，其实很难快速定位问题，所以RED模型在复杂系统的健康评估上更有用。可以看到用到的指标不多，也和上面灵魂的三个问题一样：你的系统请求是多少？错误或错误率是多少？这些指标都用到了，但是我估计很多人都没有想过通过指标来建立一个模型来反映系统整体的稳定性和可靠性。而且尤其是对于微服务，这种模式还是很不错的。可以看出，这对应于上面的服务级别监控。RED模型是一种评估系统整体可用性的方法。通过对系统请求的全程监控（从请求开始到返回的全过程），并从中提炼出3个关键指标，来评估系统的可用性。RED模型一般用在API网关层面，可以监控服务。LETS模型LETS（Latency,Errors,Traffic,andSaturation），整个模型是谷歌在2003年提出来的。其实这个模型就是谷歌在提出他们的SRE时提出的模型。这4个指标在SRE书中被称为“TheFourGoldenSignals”。书中说，如果你只能关注4个指标，那就关注这4个：延迟、错误、流量和饱和度。“如果你只能衡量四个指标，那就关注这四个：延迟、错误、流量和饱和度。”该模型使用最小的一组焦点指标来评估系统可用性。通过关注这4个指标，你会发现系统中的大部分问题。它不像USE那么底层，它是一个服务可用性的监控和分析模型。综上所述，还是需要有一定的方法论来指导你。今天总结这篇文章的目的是梳理一下API的监控方面，梳理一下API监控的基础层次、常用指标和常用监控模型。对于API的监控模型，这里也做一下说明。不同的监控模型关注不同的问题，或者关注不同的监控级别。而在实际团队中，这项工作一般会分成几个组织共同完成。不同的团队有不同的关注点，因此您可以针对特定的关注点选择不同的模型。另外要说的是，对于API监控，虽然上面说的层级、指标、模型都是前人总结的。但是时代在发展，技术在进步。在实际场景中使用时，一方面要选择合适可用的机型。另一方面，你也要考虑可选机型是否适合当前场景。一个更好的选择是你是否可以为你自己的场景抽象和开发一个模型。让定制的模型准确反映自己系统的状态。一张图片胜过千言万语：
