监控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中出现错误
- Performance over time
- Largest API users
- Most commonly used API features
- Error occurrence in the API
我如何对该信息采取行动？的例子。
Examples of "How do I want to act on that information?"
- 查看已知测量的仪表板
- 当某些变化超出预期范围时收到警报
- 导致该状态的跟踪执行
- 查看系统整个生命周期的测量结果
- Review a dashboard of known measurements
- Be alerted when something changes beyond expected bounds
- Trace execution that led to that state
- Review measurements for the entire lifetime of the system
如果你能回答这些问题，那么你可以找到正确的第三方解决方案来捕获您感兴趣的指标，也可以将监控探针注入API的正确部分，告诉您需要了解的内容。我注意到您主要是 Laravel 用户，因此很可能会捕获您想知道的许多指标之前添加（在控制器上过滤器之前注册）之后（注册应用程序后过滤器）过滤您的应用程序，测量响应时间和成功完成响应。这是第一组问题的答案最重要的地方（我想知道什么？），因为它将指导您在应用中衡量的位置和内容。
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（这里可以阅读一个很好的介绍：衡量一切，衡量一切），这在许多人中非常普遍。 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屋！
