前言
QueryId作为Druid区分查询的唯一标识,是我们定位查询问题有效的输入。用户查询有问题时,优先提供QueryId,如果在日志中捞不到的话,我们再根据dataSource名,interval以及查询装态来判断是哪条查询。
Druid Metrics
Druid 服务在运行时会将自身的一些metrics(指标信息)记录到日志文件中,也可以通过HTTP请求发送给其他的消息中间件,例如Apache Kafka。 默认情况下指标信息的记录是关闭的,需要在部署服务的时候手动开启。
在我们的集群中,Druid的指标信息是通过kafka实时落入Druid的一个dataSource中druid_metrics
。metrics记录的是全维度信息,通过service
维度来区分服务,通过metric
来取分指标,且指标对应的的指标值为value
。dataSource的schema可以入Druid的时候进行更改。不同服务对应的指标可以在官网查看[Druid Metrics](http://druid.io/docs/latest/operations/metrics.html。需要注意的是,有些指标是需要配置了相应的Monitor之后才可以记录的,具体信息可以在官网查看。
Superset
Superset 是一款由 Airbnb 开源的“现代化的企业级 BI(商业智能) Web 应用程序”,其通过创建和分享 dashboard,为数据分析提供了轻量级的数据查询和可视化方案。
Druid指标信息的可视化展示是通过Druid+Superset
来实现的。Druid提供数据查询来源,而Superset则将结果通过报表或者其他的方式展示出来。这样我们可以很轻松地查看和分析Druid的很多指标信息,包括:查询指标,集群状态,服务负载等等。
查询问题分析
现在我们认为用户的唯一输入是queryId,则可以将其作为过滤条件筛选出相应的指标。
确定查询语句
首先,最重要的是我们要获取到用户的查询语句,而查询是请求Broker的,所以据提的查询我们可以在Broker的日志中获取。但是,如果有多个Broker,我们如何确定是哪个Broker?一个一个查可以,也可以通过druid_metrics
查看。具体的查询语句如下: