Question

我正在使用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.了解发生的事情以及如何防止这种情况发生。

由于

Answer 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'功能之前，我已经找到了一个很酷的黑客'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 clone https://github.com/OpenTSDB/opentsdb.git

cd opentsdb

git checkout next

bash ./build.sh

#Wait for it to compile

＃到FSCK而不改变指标

build / tsdb fsck --full-scan --threads = 16

＃向FSCK解决重复/修复指标

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

祝你好运！

Answer 2

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

解决方案2 ：如果您已经将重复值写入Hbase（基础数据存储区），并且无法查询openTSDB - 请使用fsck实用程序：while { {1}}

特定查询：

opentsdb/build/

对于指标：

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

完整表格：Hbase＆＃39; tsdb＆＃39;中的所有数据table（一个表openTSDB存储数据）

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

有用的fsck标志：

./tsdb fsck --full-scan --threads=8 --fix-all --resolve-duplicates --compact - 设置所有修复标记，以尝试立即修复所有问题。请谨慎使用。
--fix-all 在维修期间压缩未压缩的行。
--compact 删除似乎已压缩但解析失败的列。如果列正确解析但值的最后一个字节未设置为0或1，则该列将保持不变。
--delete-bad-compacts 通过删除除最新或最旧数据点之外的所有数据点来启用重复数据点解析。另见--last-write-wins。
--resolve-duplicates 标记设置后，在解析重复项时删除除最近写入的数据点以外的所有数据点。如果配置值--last-write-wins设置为tsd.storage.fix_duplicates，则无论此值如何，都将保留最新数据点。未设置--last-write-wins
true 扫描整个数据表。注意：这可能需要很长时间才能完成。
--full-scan 整数执行完整扫描时要使用的线程数。默认值是CPU核心数的两倍。

Answer 3

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

tsd.storage.fix_duplicates = true

此处找到解决方案：https://github.com/OpenTSDB/opentsdb/issues/430

OPENTSDB fsck - 不修正重复点

3 个答案: