概述

ELK、EFK，或者是其他类似工具网站可谓是Java后端开发必备神器。借助于这些工具，我们可以得知：应用是否正常，接口响应速度，报错堆栈日志等。能够很大程度上提升开发效率，减少bug等。

问题

某天在生产环境ELK，看到记录如下报错信息：

ERROR c.x.c.d.b.s.i.TableWarnServiceImpl - executeTableWarnJob error: 
java.lang.NumberFormatException: For input string: "57.97888386123681"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Long.parseLong(Long.java:589)
	at java.lang.Long.parseLong(Long.java:631)
	at com.johnny.cloud.datasetsubscript.business.service.impl.TableWarnServiceImpl.checkItem(TableWarnServiceImpl.java:180)

对应的报错代码片段：

private boolean checkItem(TableWarnParams params, Object result) {
    boolean bl = false;
    // 设置的阈值
    Long threshold = params.getCount();
    Long count = Long.parseLong(result.toString());
    switch (params.getWhere()) {
        case ">":
            if (count > threshold) {
                bl = true;
            }
        default:
            break;
    }
    return bl;
}

排查

在讲述问题排查过程和结论前，大致讲述一下这个功能的使用场景。

作为一款通用型大数据平台的数据监控模块，支持若干关系型数据库，如MySQL，Postgre SQL，也支持对接Impala、ClickHouse等OLAP数据源。选择数据源后，提供一个SQL编辑窗口，支持用户提交的各种类型的SQL。随后提供一个SQL计算结果期望的告警阈值设置下拉选项框。

举例来说，如果用户提交的SQL计算执行结果是1，【大于】设置的阈值【0】，则触发告警（短信，电话，邮件，企微等）。这在企业大数据平台日常运营中很具备意义，满足阈值设置条件，则说明某个数据源不正常，需要加以关注与处理。

最后，用户提交的SQL是通过cron表达式来定时调度执行。

回到报错的方法，该方法有2个入参：

TableWarnParams是一个POJO实体类，count表示设置的对比阈值，where表示设置的对比条件。
Object类型的result表示用户设置的SQL的执行结果。

通过上面的报错日志，可以得知是哪一个用户提交的SQL报错：

select round(afpi_loanlevel_total_cnt_his24mth_miss * 100, 0) as afpi_miss_58
from view_monitor_miss_rate 
order by list_day desc 
limit 1

将这个SQL拿到类似于ad hoc这种即时查询可视化平台查询得到的结果：

考虑到是线上应用，故而考虑将SQL取整，即使用impala提供的round(num, 0)函数，这个函数在可视化查询平台上面的执行结果如下：

但是，ELK仍然记录如下日志：

ERROR c.x.c.d.b.s.i.TableWarnServiceImpl - executeTableWarnJob error: 
java.lang.NumberFormatException: For input string: "58.0"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Long.parseLong(Long.java:589)
	at java.lang.Long.parseLong(Long.java:631)
	at com.johnny.cloud.datasetsubscript.business.service.impl.TableWarnServiceImpl.checkItem(TableWarnServiceImpl.java:180)

于是只好在本地测试环境尝试重现这个问题。

将报错SQL简化一下，替换到postman的requestBody里（省略其他非相关的json字段）：

{
	"sqlTmp": "select 57.97888386123681 as a, 11 as b;"
}

可见查询得到的是一个BigDecimal类型的数据。

使用round(num, 0)函数

本地无法复现问题。

没有办法，最后的解决方法：

Long count;
// 兼容round(num, 0)之后依然存在小数点的问题
if (result.toString().contains(".")) {
    count = Math.round(Double.parseDouble(result.toString()));
} else {
    count = Long.parseLong(result.toString());
}

附使用的hive-jdbc版本号：

<dependency>
    <groupId>org.apache.hive</groupId>
    <artifactId>hive-jdbc</artifactId>
    <version>1.1.0-cdh5.7.1</version>
</dependency>
<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-common</artifactId>
    <version>2.6.0-cdh5.7.1</version>
</dependency>