监控 REST API 的最佳方式是什么? [英] What's the best way to monitor your REST API?

问题描述

我已经创建了一个基于 RESTful 模式的 API，我想知道监控它的最佳方法是什么?我可以以某种方式收集每个请求的统计信息以及我可以监控请求的深度吗?

I've created an API based on the RESTful pattern and I was wondering what's the best way to monitor it? Can I somehow gather statistics on each request and how deep could I monitor the requests?

另外，是否可以通过使用开源软件(也许构建我自己的监控服务)来完成，还是我需要购买第三方软件?

Also, could it be done by using open source software (maybe building my own monitoring service) or do I need to buy third party software?

如果可以使用开源软件实现，我该从哪里开始?

If it could be achieved by using open source software where do I start?

推荐答案

首先确定您认为监控可以解决的核心需求.试着回答两个问题我想知道什么?"和我想如何根据这些信息采取行动?".

Start with identifying the core needs that you think monitoring will solve. Try to answer the two questions "What do I want to know?" and "How do I want to act on that information?".

我想知道什么?"的例子

Examples of "What do I want to know?"

• 随着时间的推移表现
• 最大的 API 用户
• 最常用的 API 功能
• API 中出现错误

我想如何根据该信息采取行动?"的示例

Examples of "How do I want to act on that information?"

• 查看包含已知测量值的仪表板
• 在发生超出预期范围的变化时收到警报
• 跟踪导致该状态的执行
• 查看系统整个生命周期的测量值

如果您能回答这些问题，您可以找到合适的第三方解决方案来捕获您感兴趣的指标，或者将监控探针注入 API 的正确部分，以告诉您需要做什么知道.我注意到您主要是一个 Laravel 用户，所以很可能您想知道的许多指标都可以被捕获通过添加 before ( 在控制器上的过滤器之前注册 ) 和之后(注册后应用过滤器)与您的应用程序一起过滤，以测量响应时间和成功完成响应.这是第一组问题的答案最重要的地方(我想知道什么?")，因为它将指导您在应用中衡量的位置和内容.

If you can answer those questions, you can either find the right third party solution that captures the metrics that you're interested in, or inject monitoring probes into the right section of your API that will tell you what you need to do know. I noticed that you're primarily a Laravel user, so it's likely that many of the metrics you want to know can be captured by adding before ( Registering Before Filters On a Controller ) and after ( Registering an After Application Filter ) filters with your application, to measure time for response and successful completion of response. This is where the answers to the first set of questions are most important ( "What do I want to know?" ), as it will guide where and what you measure in your app.

一旦您知道可以在何处捕获数据，选择合适的工具就变成了在(大致)两类监控应用程序之间进行选择的问题:高度专业化的监控应用程序与您的应用程序的运行紧密相关，以及通用监控更类似于时间序列数据库的软件.

Once you know where you can capture the data, selecting the right tool becomes a matter of choosing between (roughly) two classes of monitoring applications: highly specialized monitoring apps that are tightly bound to the operation of your application, and generalized monitoring software that is more akin to a time series database.

没有流行的(据我所知)高度专业化的开源案例示例.然而，确实存在许多商业解决方案:NewRelic、Ruxit、DynaTrace 等.等等.它们的功能可以很容易地描述为类似于远程分析器，除此之外还有许多其他功能.(另外，不要忘记更传统的分析器可能对收集您需要的一些信息很有用 - 虽然它绝对不会取代对应用程序的监控，但即使在您走之前，也可以从分析中收集到许多有价值的信息到生产.)

There are no popular (to my knowledge) examples of the highly specialized case that are open source. Many commercial solutions do exist however: NewRelic, Ruxit, DynaTrace, etc. etc. etc. Their function could easily be described to be similar to a remote profiler, with many other functions besides. (Also, don't forget that a more traditional profiler may be useful for collecting some of the information you need - while it definitely will not supplant monitoring your application, there's a lot of valuable information that can be gleaned from profiling even before you go to production.)

总的来说，我个人知道还有更多的开源选项.寿命最长的是石墨(一个很好的介绍，可以在这里阅读:衡量一切，衡量一切)，这在许多人中非常普遍.然而，Graphite 远不是唯一的选择，如果您希望自己托管，您可以找到许多其他选择，例如 Kibana 和 InfluxDB.

On the general side of things, there are many more open source options that I'm personally aware of. The longest lived is Graphite (a great intro to which may be read here: Measure Anything, Measure Everything), which is in pretty common use amongst many. Graphite is by far from the only option however, and you can find many other options like Kibana and InfluxDB should you wish to host yourself.

这些开源选项中的许多选项还具有来自多个提供商的托管选项.此外，您会发现这个阵营中有许多完全商业化的选择(我是其中之一的创始人，事实上 :) - 器乐).

Many of these open source options also have hosted options available from several providers. Additionally, you'll find that there are many entirely commercial options available in this camp (I'm founder of one, in fact :) - Instrumental ).

大多数这些商业选项的存在是因为应用程序所有者发现在运行他们的实际应用程序之上运行他们自己的监控基础设施非常繁重；保持另一个分布式系统的可用性在许多运维人员的愿望清单上并不高.:)

Most of these commercial options exist because application owners have found it pretty onerous to run their own monitoring infrastructure on top of running their actual application; maintaining availability of yet another distributed system is not high on many ops personnel's wishlists. :)

这篇关于监控 REST API 的最佳方式是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！