我已经基于RESTful模式创建了一个API，我想知道监控它的最佳方法是什么？我可以以某种方式收集每个请求的统计信息以及我可以监控请求的深度吗？
此外，是否可以通过使用开源软件（可能建立我自己的监控服务）或我是否需要购买第三方软件？
如果可以通过使用开源软件实现，我从哪里开始？
答案 0 :(得分：26)
首先确定您认为监控将解决的核心需求。试着回答两个问题“我想知道什么？”和“我如何根据这些信息采取行动？”。
“我想知道什么？”的例子。
“我如何对该信息采取行动？”的例子。
如果您可以回答这些问题，您可以找到正确的第三方解决方案来捕获您感兴趣的指标，或者将监控探针注入API的正确部分，告诉您需要做什么知道。我注意到您主要是Laravel用户，因此可能会通过在（Registering Before Filters On a Controller）之前和之后（Registering an After Application Filter）过滤器添加来捕获您想知道的许多指标与您的应用程序，测量响应时间和成功完成响应。这是第一组问题的答案最重要的地方（“我想知道什么？”），因为它将指导您在应用中衡量的位置和内容。
一旦您知道可以捕获数据的位置，选择正确的工具就可以在（大致）两类监控应用程序之间进行选择：高度专业化的监控应用程序，它们与应用程序的操作紧密相关，以及通用监控软件更类似于时间序列数据库。
没有流行的（据我所知）开源的高度专业化案例。然而，确实存在许多商业解决方案：NewRelic，Ruxit，DynaTrace等等。它们的功能可以容易地描述为类似于远程分析器，除此之外还具有许多其他功能。 （另外，不要忘记更传统的分析器可能对收集您需要的一些信息很有用 - 虽然它肯定不会取代监控您的应用程序，但是在您去之前，可以从分析中收集到大量有价值的信息。生产。）
总的来说，还有很多我个人都知道的开源选项。最长寿的是Graphite（可以在这里阅读的一个很好的介绍：Measure Anything, Measure Everything），这在许多人中非常常见。然而，Graphite是唯一的选择，你可以找到许多其他选项，如Kibana和InfluxDB，如果你想自己托管。
其中许多开源选项还提供了多个提供商提供的托管选项。此外，你会发现这个阵营中有许多完全商业化的选择（我是其中一个的创始人，实际上是:) - Instrumental）。
这些商业选项大多存在，因为应用程序所有者发现在运行实际应用程序之上运行自己的监视基础结构非常繁重。保持另一个分布式系统的可用性并不是许多运营人员的愿望清单。 ：）
答案 1 :(得分：23)
（自从我共同创立Runscope后，我显然有偏见回答这个问题，我相信它是API监控领域的领导者，所以你可以把这一切都放在一边，或者相信我多年的工作经验有1000多个客户专门针对这个问题：）
我不知道任何特定于REST（ful）API监控的OSS工具。通用OSS指标监控工具（如Graphite）绝对可以帮助您监控API堆栈的各个部分，但不具备任何特定于API的功能。
商业指标监控工具（如Datadog）或应用程序性能监控（APM）工具（如New Relic或AppDynamics）具有一些特定于API用例的功能，但没有一个以它为中心。这些是我们称之为“分层监控方法”的有用部分：从高级API监控开始，并使用这些其他工具（异常跟踪器，APM，原始日志）在问题出现时深入研究。
那么，您应该在API监控工具中寻找哪些API特定的功能？我们根据您通常监控的三个因素对它们进行分类：正常运行时间/可用性，性能/速度和正确性/数据验证。
在基础级别，您需要知道您的API是否可供需要访问它们的客户端使用。对于“公共”（意思是，在公共互联网上提供，不一定公开 ......移动后端API是公共的，但不一定是公开的）API，您将要模拟调用它们的客户端越多越好。如果您有移动应用程序，则可能需要在全球范围内提供API。因此，您的API监控工具应该允许您从多个位置运行测试。如果无法从某个位置访问您的API，您将需要通过电子邮件，Slack等进行通知
如果您的API位于专用网络（公司防火墙，登台环境，本地计算机等）上，您也希望能够“看到”它。有多种方法（代理，VPN等）只需确保您使用IT部门签署的方法。
如果您是自托管，内部构建或使用OSS工具，则全球分发测试代理是一种昂贵的设置。您需要确保您设置的每个远程位置（最好在主群集之外）也是高度可用且完全受监控的。这很快就会变得昂贵且耗时。
一旦您确认您的API可以访问，那么您将需要开始测量它们的执行速度，以确保它们不会减慢使用它们的应用程序的速度。原始响应时间是您应该跟踪的最小指标，但并非总是最有用。考虑将多个API调用聚合到用户的视图中的情况，或者用户的操作生成可能尚未存在于缓存层中的动态或很少调用的数据的情况。使用APM或基于指标的工具可能难以监控这些多步骤任务或工作流，因为它们无法理解API调用的内容，只有它们的存在。
外部监控速度对于获得最准确的性能表示也很重要。如果监视代理程序位于代码内或同一服务器上，则不太可能考虑到实际客户端在进行呼叫时遇到的所有因素。诸如DNS解析，SSL协商，负载平衡，缓存等等。
如果API返回错误的数据，那么它有什么用呢？这种情况非常常见，最终会带来更糟糕的用户体验。人们理解“失败”......他们不明白为什么应用程序向他们显示错误的数据。一个好的API监控工具将允许您对来回的消息有效负载进行深入检查。需要JSON和XML解析，复杂断言，模式验证，数据提取，动态变量，多步监视器等，才能完全验证来回发送的数据是否正确。
验证客户端如何通过API进行身份验证也很重要。良好的API特定监控工具将了解OAuth，与客户端证书的相互身份验证，令牌身份验证等。
希望这能让您了解API监控与“传统”指标，APM和日志记录工具的不同之处，以及它们如何协同工作以全面了解您的应用程序正在执行。
答案 2 :(得分：4)
我正在为我的公司使用runscope.com。如果你想要一些免费的apicombo.com也可以做。 基本上，您可以为API端点创建测试，以验证有效负载，响应时间，状态代码等。然后，您可以安排测试运行。他们还提供了一些基本的统计数据。
答案 3 :(得分：1)
我已经尝试了几种应用程序和方法来做到这一点，最好的（对我的公司和我们的相关项目）是记录key = value对（原子条目包含与此操作相关的所有信息，如IP源，操作结果，已用时间等...在每个节点/服务器的特定日志文件上），然后使用Splunk进行监视。使用您的REST和json数据可能会使您的方法不同，但它也得到了很好的支持。
安装和设置非常简单。您可以监控（几乎）实时数据（响应时间，操作结果），发送事件通知和做一些DWH（以及许多其他事情，有很多插件）。
它不是开源的，但是如果你每天使用少于50MB的日志，那么你可以免费试用它（那是它之前的工作方式，因为现在我已经在企业许可证上了我不是百分百肯定的。）
这是一个小教程，解释如何实现您的目标：http://blogs.splunk.com/2013/06/18/getting-data-from-your-rest-apis-into-splunk/