【Loki】最佳实践 - 基于LogQL的Metric

1. 前言

职业生涯一直都是在传统软件行业里，因此所接触到的系统多以单体为主，规模体量上限低，因此不论是团队技术氛围，还是实际的资源投入上，监控这一块都属于是年三十晚上打的兔子 —— 有你过年，没你也过年。

虽然一直缺乏实际的机会来实际体验监控在大型软件架构上的用途，但在平时的阅读理论熏陶，以及对于实际工作的刻意观察和思考之下，笔者一直也是尝试在推广自己对于监控的理解。

没有监控的应用运行如同闭眼开车，突出一个赌人品。
~
如果你不能测量它，你就无法优化它。所以监控应该是所有改良的起始步骤。
~
更重要的，也是需要不断普及的一个常识 —— 监控工具的使用与监控功能的实现和高效应用之间不是等价关系。监控的主要目：

1. 问题被报告时，辅助更为快速的定位问题，不断缩短问题的MTTR。（这是一个没有终点的工作）
2. 问题发生初始阶段，于客户之前先察觉问题，增强自身应对问题的灵活度。
3. 通过统计分析，料敌于先，为应用优化提供指导和方向。

本文重点关注以上的第三点 —— “通过统计分析，为应用优化提供指导和方向”。就我个人理解，这才是监控的最大价值所在，解决问题只是最初级的CMMI1级，能够预测问题至少也是CMMI4了。

2. 最佳实践

注意：以下功能只是引子，启发思维之用，最重要的是站在系统全局，站在研发和产品的视野上，换位思考之下自主分析总结出更多的指标。不断为了系统优化指明方向，将系统优化方向的指导权牢牢掌握在自己手上，化被动为主动。

正式开始前，先交代下背景。

1. 背景项目为微服务架构，其日志格式整体分两类：access log（访问日志）和 business log（业务日志），具体格式如下：

   # access log（系统访问日志，使用logback-access组件自动实现）
   [%t{yy-MM-dd HH:mm:ss.SSS}][%tid][%clientHost][%requestURL,%statusCode][%elapsedTime,%i{Referer}][%reqAttribute{client}][%i{User-Agent}][%reqAttribute{userId}][%reqAttribute{serviceName}][%reqAttribute{serviceSourceType}][%reqAttribute{serviceType}][%reqAttribute{serviceOwner}][#%requestContent#][#%responseContent#]
   
   # business log（业务代码中采用log.xxx()方式输出的日志）
   [%d{yy-MM-dd HH:mm:ss.SSS}][%X{tid}][pid:${PID:-}][tid:%15.15t][%-40.40logger:%line][%5p] %msg%n
   

2. promtail采集时，对日志进行了必须label标记：module（日志所属模块），job，filename。（遵从最佳实践，我们尽量减少了label的使用）
   2.1 对于module label，我们简单地按照既有模块进行标记。分为：api-gateway，xxx等。
   2.2 对于job label，我们则是将其划分为gatewayLog（网关模块的access log，独立出来是为了方面专门的统计），accessLog（其它微服务模块的access log），normalLog（info/warn级别日志），errorLog（error级别日志）。

以上背景下，截至目前我们总结了如下的Metric指标：

######################### 系统QPS-以api-gateway作为切入点（过去五分钟）
rate({module="api-gateway", job="gatewayLog"}  | drop filename[5m])

######################### 系统总访问量-以api-gateway作为切入点（过去2天）
count_over_time({job="gatewayLog"} | drop filename[2d])
 
######################### 系统错误率-以api-gateway作为切入点（过去五分钟）
rate({module="api-gateway", job="errorLog"} | drop filename[5m])
 
######################### 系统错误总数-以api-gateway作为切入点（过去五分钟）
count_over_time({module="api-gateway", job="errorLog"} | drop filename[5m])
 
######################### 系统各模块的错误总数（过去两天）
# 这个结果里反馈得很有意思，主要错误都发生在api-gateway和serve-manager两个模块
count_over_time({job="errorLog"} | drop filename[2d])
 
 
########################## 系统各模块的普通日志总数（过去两天）
# 搭配上面的"错误总数"，很容易发现一些有意思的统计信息：
# server-manager模块在过去的两天里： 错误日志数量42981, 普通日志数量117
# api-gateway依然是日志产生的最大源头，存在三个数量级的差异
count_over_time({job="normalLog"} | drop filename[2d])
 
 
########################## 系统各模块的所有日志总数（过去两天） ---- 以下两个任选其一
sum (count_over_time({module=~".+"}  | drop filename[2d])) by (module)
 
count_over_time({module=~".+"}  | drop filename,job [2d])
 
######################### url请求耗时的顺序排列
# 筛选出系统里请求最耗时的前十类url， 分析是否有进一步地优化空间
sort_desc(topk(10,quantile_over_time(0.99,
  {module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    | level = "ACCESS"
    | label_format requestUrl=`{{regexReplaceAll  "(.*)\\?.*" .requestUrl "${1}"}}`
    | requestUrl !~ ".*-proxy/.*"
    | unwrap elapsedTime [1h]) by (requestUrl)) by (elapsedTime))
 
 
sort_desc(topk(10,avg_over_time({module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    | level = "ACCESS"
    | label_format requestUrl=`{{regexReplaceAll  "(.*)\\?.*" .requestUrl "${1}"}}`
    | drop clientIp,filename,job,level,logtime,method,module,msg,protocol,referer,serviceName,serviceOwner,serviceSourceType,serviceType,statusCode,tid,userAgent,userName
    | unwrap elapsedTime [1h]) by (requestUrl)))
 
######################### 某个URL的请求耗时P99线
quantile_over_time(0.99,
  {module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    | level = "ACCESS"
    | label_format requestUrl=`{{regexReplaceAll  "(.*)\\?.*" .requestUrl "${1}"}}`
    | requestUrl = "/api/server-manager/xxx/yyy/zzz"
    | unwrap elapsedTime [1h]) by (requestUrl)
 
######################### 某个URL的平均请求耗时（过去一小时内）
# 将 avg_over_time 切换为 max_over_time, min_over_time可获得过去一小时内该请求的最大耗时与最小耗时
avg_over_time({module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    | level = "ACCESS"
    | label_format requestUrl=`{{regexReplaceAll  "(.*)\\?.*" .requestUrl "${1}"}}`
    | requestUrl = "/api/server-manager/xxx/yyy/zzz"
    | drop clientIp,filename,job,level,logtime,method,module,msg,protocol,referer,serviceName,serviceOwner,serviceSourceType,serviceType,statusCode,tid,userAgent,userName
    | unwrap elapsedTime [1h])
 
######################### 监控指标serviceName为空的情况排查
sum(count_over_time({module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    | label_format requestUrl=`{{regexReplaceAll  "(.*)\\?.*" .requestUrl "${1}"}}`
    | drop clientIp,filename,job,level,logtime,method,module,msg,protocol,referer,serviceOwner,serviceSourceType,serviceType,statusCode,tid,userAgent,userName
    |serviceName = ""[2d])) by (requestUrl)

######################### 某个接口是否存在被调用过，被调用的次数: 以筛选过期接口。
{module="gis-manager", job="accessLog"}
  | json
  | __error__ = ""
 #| level = "ACCESS"
  | label_format requestUrl=`{{regexReplaceAll "(.*)\\?.*" .requestUrl "${1}"}}`
  | requestUrl =~ ".*/services.*"

#====================== 非人工访问带来的请求量
sum(count_over_time({module="api-gateway", job="gatewayLog"}
    | json
    | __error__ = ""
    |userAgent = "fasthttp" or userAgent = "Apache-HttpClient/4.5.13 (Java/1.8.0_332)"[2d])
    )

# api-gateway异常日志统计 —— 统计每类异常的总数，对应的url，分析到底是哪些链接到底的问题数量最多，找出优化点。
sum(count_over_time({module="api-gateway", job="errorLog"}
    | drop filename
    !~ "(?s).*PreAuthFilter.*"
    |= "Exception"
    | json
    | __error__ = ""
    | label_format exceptionType=`{{regexReplaceAll  "(?s).+?\\s(.*?)Exception:.*" .msg "${1}Exception"}}`
    | drop msg [2h]
    )) by (exceptionType)

3. 后记

可以看出，以上其实都是在熟悉LogQL之后根据需求马上就能写出来的表达式，所以本文意为总结并且抛砖引玉，希望不断完全系统实时Metric库，延缓系统的腐坏速度。

过往很多时候的优化，虽然我们也是试图做全局通盘考虑，但确实全局视野的情况下，实际效果上看更多还是单点优化。

但在引入可观测性的Metric之后，情况就能发生根本性的改变 —— 现在有了一个时刻就绪的全局检验方法，随时验证/检查自己的思路是否发生偏移；用客观的全局视野和数据来判定当前系统的主要矛盾，而不是靠"感觉"来决定应该先去做哪方面的优化。

4. 参考

1. Office Site - LogQL: Log query language