3

我正在使用 OPENTSDB，在查询时我得到了这个：

net.opentsdb.core.IllegalDataException: Found out of order or duplicate data: cell=Cell([-35, 87], [0, 0, 0, 0, 0, 8, -34, 65]), delta=3541, prev cell=Cell([-35, 87], [0, 0, 0, 0, 0, 12, -82, 106]), last_delta=3541, in row=[KeyValue(key=[0, 8, -96, 81, -7, -77, 16, 0, 0, 1, 0, -73, 83, 0, 0, 3, 0, 47, 57, 0, 0, 69, 0, 44, 99, 0, 0, 71, 0, 48, 79, 0, 0, 75, 0, 47, -53, 0, 0, 76, 0, 13, -24, 0, 0, 77, 0, 114, 14, 0, 0, 85, 0, -16, -50], family="t", qualifier="\xDDW", value=[0, 0, 0, 0, 0, 12, -82, 106], timestamp=1375323607530), KeyValue(key=[0, 8, -96, 81, -7, -77, 16, 0, 0, 1, 0, -73, 83, 0, 0, 3, 0, 47, 57, 0, 0, 69, 0, 44, 99, 0, 0, 71, 0, 48, 79, 0, 0, 75, 0, 47, -53, 0, 0, 76, 0, 13, -24, 0, 0, 77, 0, 114, 14, 0, 0, 85, 0, -16, -50], family="t", qualifier=[-35, 87, -35, -41, -34, 103, -32, 7, -32, -57], value=[0, 0, 0, 0, 0, 8, -34, 65, 0, 0, 0, 0, 0, 1, -122, -123, 0, 0, 0, 0, 0, 3, -22, 23, 0, 0, 0, 0, 0, 13, -10, -32, 0, 0, 0, 0, 0, 10, -27, 6, 0], timestamp=1375323057833)] -- run an fsck.

我尝试过使用 fsck --fix ，但这就是说没有发现错误。有没有办法： 1. 除了手动删除数据点之外解决这个问题 2. 了解发生了什么以及如何防止这种情况。

谢谢

4

3 回答 3

1

OpenTSDB 是一个非常特殊的由 HBase 支持的时间序列数据库。tsdb 中的数据必须按时间/日期顺序排列，不能重复。数据点超出时间/日期顺序可能是由 tcollectors 或系统主机上的过时系统时钟引起的。重复的数据通常是由 API 或 TCP 套接字上的手动 PUT 引起的。您的异常显示单元格 -35、87 重复。你是手动将这些数据提交到 TSDB 还是直接输入到 HBase 中？

要解决此问题，您可以尝试“tsdb fsck”。

'tsdb fsck --fix' 需要一个时间段、一个运算符和一个指标名称。如果 --fix 没有发现错误，则说明您没有提供包含重复数据的时间段或指标名称。

例如：

/usr/local/opentsdb/build/tsdb fsck --fix 9d-ago sum http.hits --config /usr/local/opentsdb/opentsdb.conf

从 1.0 版开始处理 TSDB，并且在 2014 年夏天添加了许多“fsck”功能之前，我想出了一个很酷的 hack 来“fsck”所有数据点。此 shell 脚本快速列出所有指标，然后将 shell 发送到 tsdb 以 fsck 该指标的所有数据点：

#!/bin/bash
list=`/usr/local/opentsdb/build/tsdb uid grep '' --config /usr/local/opentsdb/opentsdb.conf | cut -d" " -f2 | cut -d ":" -f1`
for i in $list
do
    echo "Fixing metric $i" && /usr/local/opentsdb/build/tsdb fsck --fix 9d-ago sum $i --config /usr/local/opentsdb/opentsdb.conf &
done

在 TSDB 2.1 中执行 fsck 要容易得多。不幸的是，截至 24AUG14，它尚未发布，只能通过“下一个”分支的代码控制签出获得：

git 克隆https://github.com/OpenTSDB/opentsdb.git

cd opentsdb

git checkout 下一个

重击 ./build.sh

#等待编译

# 到 FSCK 而不改变指标

构建/tsdb fsck --full-scan --threads=16

# 到 FSCK 解决重复/修复指标

构建/tsdb fsck --full-scan --threads=16 --fix --resolve-duplicates --compact

祝你好运！

于 2014-08-25T01:15:27.617 回答
1

解决方案 1：为避免从一开始就发生这种情况，请将tsd.storage.fix_duplicates标志设置true为opentsdb.conf.

解决方案 2：如果您已经将重复值写入 Hbase（底层数据存储），并且无法查询 openTSDB - 使用fsck实用程序：while insideopentsdb/build/

具体查询：

 ./tsdb fsck --fix-all 1h-ago now sum <metric-name> tag1=val1

对于公制：

./tsdb fsck --threads=2 --fix-all --resolve-duplicates 15d-ago sum <metric name>

Full Table : Hbase 的 'tsdb' 表中的所有数据（一张表 openTSDB 存储数据）

./tsdb fsck --full-scan --threads=8 --fix-all --resolve-duplicates --compact

有用的fsck标志：

  • --fix-all- 设置所有修复标志以尝试一次修复所有问题。谨慎使用。
  • --compact 在修复期间压缩未压缩的行。
  • --delete-bad-compacts 删除看似已压缩但解析失败的列。如果列正确解析但值的最后一个字节未设置为 0 或 1，则该列将被单独保留。
  • --resolve-duplicates通过删除除最新或最旧数据点之外的所有数据点来启用重复数据点解决方案。另请参阅 --last-write-wins。
  • --last-write-wins 标志 设置后，在解析重复项时删除除最近写入的数据点之外的所有数据点。如果配置值tsd.storage.fix_duplicates设置为true，则无论该值如何，都将保留最新的数据点。未设置 --last-write-wins
  • --full-scan扫描整个数据表。注意：这可能需要很长时间才能完成。
  • --threads 整数 执行完整扫描时使用的线程数。默认值为 CPU 内核数的两倍。
于 2017-05-03T10:24:42.863 回答
0

我无法让 fsck 修复我的重复项，但将其添加到配置文件并重新启动 OpenTSDB 确实对我有用：

tsd.storage.fix_duplicates = true

在这里找到的解决方案：https ://github.com/OpenTSDB/opentsdb/issues/430

于 2015-07-02T10:31:05.330 回答