【问题标题】:Tool for monitoring QOS用于监控 QOS 的工具
【发布时间】:2014-04-28 11:52:32
【问题描述】:

在我的项目中

  1. 我们抓取 x 台服务器。
  2. 每个服务器的用户数从 1 到 n 不等。
  3. 我们为每个用户抓取 1 到 z 个项目。

目前我们正在使用石墨监控 QOS。我们正在存储抓取该项目所花费的时间。

x.time_taken

这种方法的问题是,如果只有单个用户受到影响,我们会收到有关 QOS 的错误警报。

回答/监控以下几点的正确工具/技术是什么:

  1. 仅当最少 k 个用户受到影响时才发出警报。 [不是事件数量]
  2. 受影响的用户列表。

我认为石墨和 statsd 不是正确的工具。回答这两个问题的更好工具是什么?

【问题讨论】:

    标签: monitoring graphite qos


    【解决方案1】:

    您所要求的通常称为服务监控。出于非常充分的理由,您想知道事件对服务的影响,而不仅仅是事件已经发生。

    这种方法的优势与您在要求中声明的完全一样 - 您可以专注于影响大部分用户群的事件,并且您会立即获得受影响的用户列表。

    恕我直言,主要缺点是服务监控通常比简单的性能或事件/警报监控复杂得多。它还经常依赖于服务模型,根据我的经验,这种模型很难构建,更难跟上时代。

    例如,如果您系统中的某台服务器出现明显的减速或故障,根据您的架构,这可能会影响所有使用依赖该服务器的服务的用户,或者可能会影响很小的子集,甚至不会影响最初,如果有负载平衡机制或冗余机制。

    您需要在服务监控模型中反映此架构,并在每次更新系统架构或部署时更改它。

    如果您的系统足够静态或足够关键以保证投资,那么这可能值得您花时间。如果不是,那么一个简单的折衷方案可能只是更新您正在执行的图形和警报,以在一定数量的用户或服务器上所有用户的平均响应时间显着增加时发出警报。

    这可能会给您带来您所追求的大部分好处,而无需投资于服务监控解决方案的额外复杂性。

    如果您确实希望扩展您的监控方法并希望坚持使用开源工具,那么如果您的重点是基础架构,或者有很多带有免费层的 Web 服务监控解决方案,我会先看看 NAGIOS作为pingdom:

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-05-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多