有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java OPENTSDB fsck修复程序不更正重复点

我正在使用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.了解发生了什么以及如何预防

谢谢


共 (3) 个答案

  1. # 1 楼答案

    我无法让fsck修复我的副本,但将其添加到配置文件并重新启动OpenTSDB对我来说确实有效:

    tsd.storage.fix_duplicates = true
    

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

  2. # 2 楼答案

    OpenTSDB是一个由HBase支持的非常特殊的时间序列数据库。tsdb中的数据必须按时间/日期顺序排列,不得重复。数据点的时间/日期顺序不符可能是由t采集器或系统主机上的过期系统时钟造成的。重复的数据通常是由人工通过API或TCP套接字传输造成的。你的例外情况显示第35号和第87号单元格一式两份。您是手动将此数据提交给TSDB,还是直接将其输入到HBase

    要解决这个问题,您可以在尝试时使用“tsdb fsck”

    “tsdb fsck修复”需要一个时间段、一个运算符和一个度量名称。如果修复程序没有找到错误,则说明您没有提供包含重复数据的时间段或度量名称

    例如:

    /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脚本快速列出所有指标,然后将其发送到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
    

    在TSDB2.1中,执行fsck要容易得多。不幸的是,截至2014年8月24日,它尚未发布,只能通过“下一个”分支的代码控制签出来使用:

    git clone https://github.com/OpenTSDB/opentsdb.git

    cd opentsdb

    git checkout next

    bash ./build.sh

    #Wait for it to compile

    # To FSCK without altering the metrics

    build/tsdb fsck full-scan threads=16

    # To FSCK with resolving duplicate/to fix the metrics

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

    祝你好运

  3. # 3 楼答案

    解决方案1:为了避免这种情况从一开始就发生,请在^{中将tsd.storage.fix_duplicates标志设置为true


    解决方案2:如果您的Hbase(底层数据存储)中已经写入了重复的值,并且无法查询openTSDB,请使用fsck实用程序:在opentsdb/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>
    

    完整表:Hbase的“tsdb”表中的所有数据(openTSDB存储数据的一个表)

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

    有用的^{}标志:

    • fix-all-设置所有修复标志,尝试一次修复所有问题。小心使用
    • compact在修复期间压缩未压缩的行
    • delete-bad-compacts删除看似已压缩但解析失败的列。如果一列解析正确,但值的最后一个字节未设置为0或1,则该列将被保留
    • resolve-duplicates通过删除除最新或最旧数据点以外的所有数据点,启用重复数据点解析。还可以看到最后一次写入的胜利
    • last-write-wins设置标志后,在解析重复项时删除除最近写入的数据点以外的所有数据点。如果配置值tsd.storage.fix_duplicates设置为true,则不管该值如何,都将保留最新的数据点。未设置最后写入将获胜
    • full-scan扫描整个数据表。注意:这可能需要很长时间才能完成
    • threads整数执行完全扫描时要使用的线程数。默认值是CPU核心数的两倍