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

2023-11-11 15:12
文章标签 最佳 实践 loki metric logql

本文主要是介绍【Loki】最佳实践 - 基于LogQL的Metric,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

    • 1. 前言
    • 2. 最佳实践
    • 3. 后记
    • 4. 参考

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(日志所属模块)jobfilename。(遵从最佳实践,我们尽量减少了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

这篇关于【Loki】最佳实践 - 基于LogQL的Metric的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/390960

相关文章

Linux进程CPU绑定优化与实践过程

《Linux进程CPU绑定优化与实践过程》Linux支持进程绑定至特定CPU核心,通过sched_setaffinity系统调用和taskset工具实现,优化缓存效率与上下文切换,提升多核计算性能,适... 目录1. 多核处理器及并行计算概念1.1 多核处理器架构概述1.2 并行计算的含义及重要性1.3 并

全面掌握 SQL 中的 DATEDIFF函数及用法最佳实践

《全面掌握SQL中的DATEDIFF函数及用法最佳实践》本文解析DATEDIFF在不同数据库中的差异,强调其边界计算原理,探讨应用场景及陷阱,推荐根据需求选择TIMESTAMPDIFF或inte... 目录1. 核心概念:DATEDIFF 究竟在计算什么?2. 主流数据库中的 DATEDIFF 实现2.1

Spring WebFlux 与 WebClient 使用指南及最佳实践

《SpringWebFlux与WebClient使用指南及最佳实践》WebClient是SpringWebFlux模块提供的非阻塞、响应式HTTP客户端,基于ProjectReactor实现,... 目录Spring WebFlux 与 WebClient 使用指南1. WebClient 概述2. 核心依

MyBatis-Plus 中 nested() 与 and() 方法详解(最佳实践场景)

《MyBatis-Plus中nested()与and()方法详解(最佳实践场景)》在MyBatis-Plus的条件构造器中,nested()和and()都是用于构建复杂查询条件的关键方法,但... 目录MyBATis-Plus 中nested()与and()方法详解一、核心区别对比二、方法详解1.and()

Spring Boot @RestControllerAdvice全局异常处理最佳实践

《SpringBoot@RestControllerAdvice全局异常处理最佳实践》本文详解SpringBoot中通过@RestControllerAdvice实现全局异常处理,强调代码复用、统... 目录前言一、为什么要使用全局异常处理?二、核心注解解析1. @RestControllerAdvice2

Spring事务传播机制最佳实践

《Spring事务传播机制最佳实践》Spring的事务传播机制为我们提供了优雅的解决方案,本文将带您深入理解这一机制,掌握不同场景下的最佳实践,感兴趣的朋友一起看看吧... 目录1. 什么是事务传播行为2. Spring支持的七种事务传播行为2.1 REQUIRED(默认)2.2 SUPPORTS2

Java中的雪花算法Snowflake解析与实践技巧

《Java中的雪花算法Snowflake解析与实践技巧》本文解析了雪花算法的原理、Java实现及生产实践,涵盖ID结构、位运算技巧、时钟回拨处理、WorkerId分配等关键点,并探讨了百度UidGen... 目录一、雪花算法核心原理1.1 算法起源1.2 ID结构详解1.3 核心特性二、Java实现解析2.

MySQL 中 ROW_NUMBER() 函数最佳实践

《MySQL中ROW_NUMBER()函数最佳实践》MySQL中ROW_NUMBER()函数,作为窗口函数为每行分配唯一连续序号,区别于RANK()和DENSE_RANK(),特别适合分页、去重... 目录mysql 中 ROW_NUMBER() 函数详解一、基础语法二、核心特点三、典型应用场景1. 数据分

深度解析Spring AOP @Aspect 原理、实战与最佳实践教程

《深度解析SpringAOP@Aspect原理、实战与最佳实践教程》文章系统讲解了SpringAOP核心概念、实现方式及原理,涵盖横切关注点分离、代理机制(JDK/CGLIB)、切入点类型、性能... 目录1. @ASPect 核心概念1.1 AOP 编程范式1.2 @Aspect 关键特性2. 完整代码实

MySQL 用户创建与授权最佳实践

《MySQL用户创建与授权最佳实践》在MySQL中,用户管理和权限控制是数据库安全的重要组成部分,下面详细介绍如何在MySQL中创建用户并授予适当的权限,感兴趣的朋友跟随小编一起看看吧... 目录mysql 用户创建与授权详解一、MySQL用户管理基础1. 用户账户组成2. 查看现有用户二、创建用户1. 基