标签: graphite

据我所知，以下是主要区别：

1. 与预先确定数据库大小的Graphite不同，OpenTSDB不会随着时间的推移损坏数据。
2. OpenTSDB 可以每秒存储指标，而不是具有分钟间隔的 Graphite（我不确定这一点，Graphite 文档显示了每分钟存储指标的保留策略，但我不知道这是否是我们的最小时间单位可以一起玩）

我想就使用哪种工具来存储指标做出明智的决定，我是否错过了这两个系统中的任何其他差异？它们的性能/可扩展性如何？

额外问题：还有其他时间序列系统我应该看看吗？

我想设置 statsd/graphite，以便我可以记录在 HTML 设备上运行的 JS 应用程序（即不在包含的 LAN 环境中，并且可能有大量我无法直接控制的传入数据）。

我的限制：

• 入口点必须说 HTTP：这是通过一个简单的 HTTP-to-UDP-statsd 代理解决的（例如 github 上的 httpstatsd）
• 必须抵抗单个服务器的故障（与墨菲定律作斗争：）
• 必须是水平可扩展的：webscale，宝贝！:)
• 架构应该尽可能简单（和便宜）
• 我的服务器是虚拟机
• 数据文件将存储在文件管理器设备上（使用 NFS）
• 我可以使用 tcp/udp 硬件负载平衡器

总之，数据路径：[client] -(http)-> [http2statsd] -(udp)-> [statsd] -(tcp)-> [graphite] -(nfs)-> [filer]

到目前为止我的发现：

• 扩展 http2statsd 部分很容易（无状态守护进程）
• 缩放 statsd 部分似乎并不简单（我想我最终会在石墨中得到不连贯的值，例如 sum、avg、min、max ...）。除非 HTTP 守护进程进行一致的散列以对密钥进行分片。也许是一个想法......（但接下来是 HA 问题）
• 缩放石墨部分可以通过分片（使用碳继电器）来完成（但这也不能解决 HA 问题）。显然，多个耳语实例不应写入相同的 NFS 文件。
• 缩放文件管理器部分不是问题的一部分（但 IO 越少越好:)
• 扩展 webapp 似乎很明显（虽然我没有测试过），因为它们只读取共享的 NFS 数据

所以我想知道是否有人有经验和最佳实践可以分享一个可靠的 statsd/graphite 部署？

我正在尝试在我的 Mac OS X 10.7 lion 上设置石墨，我已经设置了 apache 以通过 WSGI 调用 python 石墨脚本，但是当我尝试访问它时，我从 apache 和错误日志中得到一个禁止.

 "client denied by server configuration: /opt/graphite/webapp/graphite.wsgi"

我已经检查了 httpd.conf 中允许的脚本位置以及文件的权限，但它们似乎是正确的。我需要做什么才能获得访问权限。下面是 httpd.conf，它几乎是石墨示例。

<IfModule !wsgi_module.c>
   LoadModule wsgi_module modules/mod_wsgi.so
</IfModule>
WSGISocketPrefix /usr/local/apache/run/wigs   
<VirtualHost _default_:*>
    ServerName graphite
    DocumentRoot "/opt/graphite/webapp"
    ErrorLog /opt/graphite/storage/log/webapp/error.log
    CustomLog /opt/graphite/storage/log/webapp/access.log common
    WSGIDaemonProcess graphite processes=5 threads=5 display-name='%{GROUP}' inactivity-timeout=120
    WSGIProcessGroup graphite
    WSGIApplicationGroup %{GLOBAL}
    WSGIImportScript /opt/graphite/conf/graphite.wsgi process-group=graphite application-group=%{GLOBAL}
    # XXX You will need to create this file! There is a graphite.wsgi.example
    # file in this directory that you can safely …

有没有人有任何公式，或者他们环境中的一些样本数据可以帮助我估计每个数据点石墨将使用多少磁盘空间？

我有一个柜台，stats.message.foo想把它移到stats.messages.foo。

我已经更新了我的代码来填充新的计数器，但是旧的仍然存在。

我已经阅读了从石墨中删除统计数据所需要做的所有事情就是删除磁盘上适当的耳语文件，但是似乎在删除后几秒钟内wsp它会重新生成（没有数据）。

如果我想重命名存储数据的密钥，这很麻烦，因为我需要记住哪个密钥是正确的。

有谁知道如何永久删除旧计数器？

我正在运行一组负载测试以确定以下设置的性能：

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

简而言之，node.js 测试套件每 x 秒向位于另一台服务器上的 StatsD 实例发送一定数量的指标。然后 StatsD 每秒将指标刷新到位于同一服务器上的 Graphite 实例。然后，我查看测试套件实际发送了多少指标以及 Graphite 接收了多少指标，以确定测试套件和 Graphite 之间的丢包率。

但是我注意到我有时会遇到非常大的丢包率（请注意，它是通过 UDP 协议发送的），范围为 20-50%。所以那是我开始调查这些数据包被丢弃的地方的时候，认为这可能是 StatsD 的一些性能问题。所以我开始记录系统每个部分的指标，以追踪发生这种下降的地方。这就是事情变得奇怪的地方。

我正在使用tcpdump创建一个捕获文件，在测试运行完成后我会检查该文件。但是每当我在运行 tcpdump 的情况下运行测试时，几乎不存在丢包！看起来 tcpdump 以某种方式提高了我的测试的性能，我无法弄清楚它为什么以及如何做到这一点。我正在运行以下命令来记录服务器和客户端上的 tcpdump 消息：

tcpdump -i any -n port 8125 -w test.cap

在一个特定的测试案例中，我发送 40000 个指标/秒。运行tcpdump的测试有4%左右的丢包，没有的时候有20%左右的丢包

两个系统都作为 Xen VM 运行，具有以下设置：

• 英特尔至强 E5-2630 v2 @ 2.60GHz
• 2GB 内存
• Ubuntu 14.04 x86_64

我已经检查过潜在原因的事情：

• 增加 UDP 缓冲区接收/发送大小。
• CPU 负载影响测试。（最大负载 40-50%，客户端和服务器端）
• 在特定接口而不是“任何”上运行 tcpdump。
• 使用“-p”运行 tcpdump 以禁用混杂模式。
• 仅在服务器上运行 tcpdump。这导致发生 20% …

我有一组运行 Carbon 和 Graphite 的机器，我需要扩展以获取更多存储空间，但我不确定是否需要向上扩展或向外扩展。

该集群目前包括：

• 1个中继节点：接收所有指标并转发到相关的存储节点
• 6 个存储节点：容纳所有 Whisper DB 文件

问题是当磁盘使用率接近 80% 时，性能似乎一落千丈。集群写入 IOPS 从近乎恒定的 13k 下降到更混乱的平均 7k 左右，IOwait 时间平均为 54%。

我已经查看了我们的配置存储库，自 4 月初以来没有任何更改，因此这不是配置更改的结果。

问：增加磁盘大小会控制IO性能，还是需要添加更多存储节点？

注意：这里没有 SSD，只有很多主轴。

相关图表：

统计和资料：

e2freefrag：

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free …

我们使用石墨来跟踪磁盘使用历史。当可用空间低于一定数量的块时，我们的警报系统会查看来自石墨的数据以提醒我们。

我想获得更智能的警报 - 我真正想要的是关心的是“在我必须对可用空间做一些事情之前我还有多长时间？”，例如，如果趋势表明在 7 天内我将用完磁盘空间然后引发警告，如果不到 2 天，则引发错误。

Graphite 的标准仪表板界面对于衍生品和 Holt Winters 置信度带非常智能，但到目前为止我还没有找到将其转换为可操作指标的方法。我也可以用其他方式处理数字（只需从石墨中提取原始数字并运行脚本来执行此操作）。

一个复杂的问题是图形不平滑 - 文件被添加和删除，但随着时间的推移，总体趋势是磁盘空间使用量增加，因此可能需要查看局部最小值（如果查看“磁盘空闲”指标） ) 并在低谷之间绘制趋势。

有没有人做过这个？

在过去的几天里，我一直试图了解我们的基础设施中发生的怪事，但我一直无法弄清楚我们的情况，所以我求助于你们给我一些提示。

我一直在 Graphite 中注意到，load_avg 的峰值大约每 2 小时发生一次，具有致命的规律性 - 不完全是 2 小时，但非常规律。我附上了一张我从 Graphite 中截取的截图

我一直在研究这个问题——这种规律性让我认为这是某种 cron 作业或类似的东西，但这些服务器上没有运行 cronjobs——实际上这些是在 Rackspace 云中运行的虚拟机。我正在寻找的是某种可能导致这些问题的迹象以及如何进一步调查。

服务器相当空闲 - 这是一个临时环境，因此几乎没有流量进入/应该没有负载。这些都是 4 个虚拟核心 VM。我可以肯定的是，我们大约每 10 秒采集一次 Graphite 样本，但如果这是造成负载的原因，那么我希望它会一直很高，而不是每 2 小时在不同服务器上的波次中发生一次。

任何有关如何调查此问题的帮助将不胜感激！

以下是来自 sar 的 app01 的一些数据——这是上图中的第一个蓝色尖峰——我无法从数据中得出任何结论。也不是您看到的每半小时（不是每 2 小时）发生的字节写入峰值是由于厨师客户端每 30 分钟运行一次。我会尝试收集更多数据，即使我已经这样做了，但也无法真正从这些数据中得出任何结论。

加载

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94 …

我们有一个 Graphite 服务器，通过 collectd、statsd、JMXTrans 收集数据……这几天以来，我们的数据经常出现漏洞。挖掘我们仍然拥有的数据，我们可以看到碳缓存大小的增加（从 50K 到 4M）。我们没有看到收集的指标数量增加（metricsReceived 稳定在 300K 左右）。我们的查询数量平均从 1000 次增加到 1500 次。

奇怪的是，当缓存大小增加时，cpuUsage 从 100%（我们有 4 个 CPU）略微下降到 50%。

再次奇怪的是，如果从磁盘读取八位字节，我们会看到数量增加，而写入的八位字节数量减少。

我们主要使用默认值配置 carbon：

• MAX_CACHE_SIZE = inf
• MAX_UPDATES_PER_SECOND = 5000
• MAX_CREATES_PER_MINUTE = 2000

显然，我们的系统中发生了一些变化，但我们不明白是什么，也不知道我们如何找到这个原因......

有什么帮助吗？