为短期流命名统计指标

时间：2014-03-26 00:56:19

标签： monitoring graphite statsd

我正在尝试将统计信息建模为提交给statsd / graphite。然而，我正在监控的是＆＃34; session＆＃34;中心。例如，我有一个实时播放的游戏。在服务器上有多个活动的游戏实例。每个游戏都有多个（和可变数量的）参与者。每个游戏的每个实例都有一个唯一的ID，就像每个玩家一样。 我想跟踪（和绘制）每个玩家的统计数据，然后针对整个实例滚动指标，然后针对游戏的所有实例滚动指标。例如，在给定时间可能存在两个活动的实例。让我们说每个游戏中有两个玩家

GameTitle.RealTime.VoiceErrors.game_instance_a.player_id_1 10
GameTitle.RealTime.VoiceErrors.game_instance_a.player_id_2 20
GameTitle.RealTime.VoiceErrors.game_instance_b.player_id_3 50
GameTitle.RealTime.VoiceErrors.game_instance_b.player_id_4 70

其中game_instances和player_ids是128位数

我希望能够看到game_instance_a的所有语音错误的值都是30 而整个系统的所有语音错误都是150

鉴于此，我有三个问题

  1. 您在命名指标时有什么指导。
  2. 拥有＆＃34; dynamic＆＃34;的指标是否犹豫不决？标识符作为名称的一部分
  3. 他们对此有何规模限制。如果我有一个100K的游戏实例 如果说游戏中有多达1000名玩家，这会杀死statsd / graphite吗？

    4. 谢谢！

1 个答案:

答案 0 :(得分：1)

您在指定指标时会给出什么指导？

Graphite推荐"Volatile path components should be kept as deep into the hierarchy as possible"。这实际上意味着，如果您可以推送通常唯一的指标部分，那么＆＃34; bucket＆＃34;在不影响分组查询的情况下，您应该尝试这样做。

以下是使用Graphite的great post，其中包含命名建议。这里是来自Jason Dixon的another one with additional info（石墨材料的一般来源）。

拥有具有＆＃34; dynamic＆＃34;的指标是犹太的吗？标识符作为名称的一部分？

我通常会尝试避免使用度量标准名称中的标识符，除非它们的数量非常少（<100）。由于 Graphite将为每个度量标准名称存储.wsp文件，如果您决定更改配置，则很难重新调整大小或调整存储设置。此外，Graphite UI将有一个＆＃34;文件夹＆＃34;对于每个度量标准名称，您可以轻松地使UI不可用。

在你的情况下，我可能会描绘游戏实例总数，玩家总数和错误数量（按类型）等。此外，我可能会尝试跟踪每个实例的玩家（通常）并且可能每个实例的错误（再次不知道实际的实例。例如GameTitle.RealTime.PerInstance.VoiceErrors）如果我有这种能力（即我的应用程序中每个实例存储的状态）。

Logstash，Elastic Search，Kibana

我建议使用实例和播放器ID记录此错误信息，并使用logstash将日志发送到elastic search and kibana。然后我会观察Graphite的实时错误和健康异常检测，并使用Kibana（以及下面的弹性搜索）深入挖掘。

对此有何规模限制。如果我在游戏中有一个100K的游戏实例，多达1000个玩家，这会杀死statsd / graphite吗？

Statsd应该没有问题，因为它只是一个极其愚蠢的聚合器。虽然它确实在内部维持一些状态，但我不会预料到问题。

我认为您内部的Graphite Whisper Storage本身存在问题，因为它只是使用文件和文件夹。但是，正如我上面提到的，Graphite Web UI将无法使用，我认为您还会面临其他可管理性问题的风险。

摘要

将易失性（动态）指标桶保留在名称的末尾，避免超过其中的几百个。

相关问题
最新问题