绝对神器,用 SQL查 Linux日志,查询效率高到飞起
大家好,我是小富~
最近发现点好玩的工具,迫不及待的想跟大家分享一下。
大家平时都怎么查Linux
日志呢? 像我平时会用tail
、head
、cat
、sed
、more
、less
这些经典系统命令,或者awk
这类三方数据过滤工具,配合起来查询效率很高。但在使用过程中有一点让我比较头疼,那就是命令参数规则太多了,记的人脑壳疼。
那查日志有没有一种通用的方式,比如用SQL查询,毕竟这是程序员都比较熟悉的表达式。
今天分享的工具q,就实现了以写SQL的方式来查询、统计文本内容,一起看看这货到底有什么神奇之处。
搭个环境
q是一个命令行工具,允许我们在任意文件或者查询结果,比如可以在ps -ef
查询进程命令的结果集上,直接执行SQL语句查询。
宗旨就是文本即数据库表,额~,当然这句话是我自己理解的,哈哈哈
它将普通文件或者结果集当作数据库表,几乎支持所有的SQL结构,如WHERE
、GROUP BY
、JOINS
等,支持自动列名和列类型检测,支持跨文件连接查询,这两个后边详细介绍,支持多种编码。
安装比较简单,在Linux CentOS
环境,只要如下三步搞定,Windows
环境更是只需安装个exe
就可以用了。
wget https://github.com/harelba/q/releases/download/1.7.1/q-text-as-data-1.7.1-1.noarch.rpm #下载版本 sudo rpm -ivh q-text-as-data-1.7.1-1.noarch.rpm # 安装 q --version #查看安装版本
语法
q支持所有SQLite
SQL语法,标准命令行格式q + 参数命令 + "SQL"
q <命令> "<SQL>"
我要查询myfile.log
文件的内容,直接q "SELECT * FROM myfile.log"
。
q "SELECT * FROM myfile.log"
q不附加参数使用是完全没有问题的,但利用参数会让显示结果更加美观,所以这里简单了解一下,它的参数分为 2种。
input
输入命令:指的是对要查询的文件或结果集进行操作,比如:-H
命令,表示输入的数据包含标题行。
q -H "SELECT * FROM myfile.log"
在这种情况下,将自动检测列名,并可在查询语句中使用。如果未提供此选项,则列将自动命名为cX,以c1起始以此类推。
q "select c1,c2 from ..."
output
输出命令:作用在查询输出的结果集,比如:-O
,让查询出来的结果显示列名。
[root@iZ2zebfzaequ90bdlz820sZ software]# ps -ef | q -H "select count(UID) from - where UID='root'" 104 [root@iZ2zebfzaequ90bdlz820sZ software]# ps -ef | q -H -O "select count(UID) from - where UID='root'" count(UID) 104
还有很多参数就不一一列举了,感兴趣的同学在官网上看下,接下来我们重点演示一下使用SQL如何应对各种查询日志的场景。
玩法贼多
下边咱们一起看几个查询日志的经常场景中,这个SQL该如何写。
1、关键字查询
关键字检索,应该是日常开发使用最频繁的操作,不过我个人认为这一点q
并没有什么优势,因为它查询时必须指定某一列。
[root@iZ2zebfzaequ90bdlz820sZ software]# q "select * from douyin.log where c9 like '%待解析%'" 2021-06-11 14:46:49.323 INFO 22790 --- [nio-8888-exec-2] c.x.douyin.controller.ParserController : 待解析URL :url=https%3A%2F%2Fv.douyin.com%2Fe9g9uJ6%2F 2021-06-11 14:57:31.938 INFO 22790 --- [nio-8888-exec-5] c.x.douyin.controller.ParserController : 待解析URL :url=https%3A%2F%2Fv.douyin.com%2Fe9pdhGP%2F 2021-06-11 15:23:48.004 INFO 22790 --- [nio-8888-exec-2] c.x.douyin.controller.ParserController : 待解析URL :url=https%3A%2F%2Fv.douyin.com%2Fe9pQjBR%2F 2021-06-11 2
而用grep
命令则是全文检索。
[root@iZ2zebfzaequ90bdlz820sZ software]# cat douyin.log | grep '待解析URL' 2021-06-11 14:46:49.323 INFO 22790 --- [nio-8888-exec-2] c.x.douyin.controller.ParserController : 待解析URL :url=https%3A%2F%2Fv.douyin.com%2Fe9g9uJ6%2F 2021-06-11 14:57:31.938 INFO 22790 --- [nio-8888-exec-5] c.x.douyin.controller.ParserController : 待解析URL :url=https%3A%2F%2Fv.douyin.com%2Fe9pdhGP%2F
2、模糊查询
like
模糊搜索,如果文本内容列有名字直接用列名检索,没有则直接根据列号c1、c2、cN。
[root@iZ2zebfzaequ90bdlz820sZ software]# cat test.log abc 2 3 4 5 23 24 25 [root@iZ2zebfzaequ90bdlz820sZ software]# q -H -t "select * from test.log where abc like '%2%'" Warning: column count is one - did you provide the correct delimiter? 2 23 24 25
3、交集并集
支持UNION
和UNION ALL
操作符对多个文件取交集或者并集。
如下建了test.log
和test1.log
两个文件,里边的内容有重叠,用union
进行去重。
q -H -t "select * from test.log union select * from test1.log" [root@iZ2zebfzaequ90bdlz820sZ software]# cat test.log abc 2 3 4 5 [root@iZ2zebfzaequ90bdlz820sZ software]# cat test1.log abc 3 4 5 6 [root@iZ2zebfzaequ90bdlz820sZ software]# q -H -t "select * from test.log union select * from test1.log" Warning: column count is one - did you provide the correct delimiter? Warning: column count is one - did you provide the correct delimiter? 2 3 4 5 6
4、内容去重
比如统计某个路径下的./clicks.csv
文件中,uuid
字段去重后出现的总个数。
q -H -t "SELECT COUNT(DISTINCT(uuid)) FROM ./clicks.csv"
5、列类型自动检测
注意:q会理解每列是数字还是字符串,判断是根据实数值比较,还是字符串比较进行过滤,这里会用到-t
命令。
q -H -t "SELECT request_id,score FROM ./clicks.csv WHERE score > 0.7 ORDER BY score DESC LIMIT 5"
6、字段运算
读取系统命令查询结果,计算/tmp
目录中每个用户和组的总值。可以对字段进行运算处理。
sudo find /tmp -ls | q "SELECT c5,c6,sum(c7)/1024.0/1024 AS total FROM - GROUP BY c5,c6 ORDER BY total desc" [root@iZ2zebfzaequ90bdlz820sZ software]# sudo find /tmp -ls | q "SELECT c5,c6,sum(c7)/1024.0/1024 AS total FROM - GROUP BY c5,c6 ORDER BY total desc" www www 8.86311340332 root root 0.207922935486 mysql mysql 4.76837158203e-06
7、数据统计
统计系统拥有最多进程数的前 3个用户ID,按降序排序,这就需要和系统命令配合使用了,先查询所有进程再利用SQL筛选,这里的q命令就相当grep
命令。
ps -ef | q -H "SELECT UID,COUNT(*) cnt FROM - GROUP BY UID ORDER BY cnt DESC LIMIT 3" [root@iZ2zebfzaequ90bdlz820sZ software]# ps -ef | q -H "SELECT UID,COUNT(*) cnt FROM - GROUP BY UID ORDER BY cnt DESC LIMIT 3" root 104 www 16 rabbitmq 4 [root@iZ2zebfzaequ90bdlz820sZ software]# ps -ef | q -H -O "SELECT UID,COUNT(*) cnt FROM - GROUP BY UID ORDER BY cnt DESC LIMIT 3" UID cnt root 110 www 16 rabbitmq 4
我们看到加与不加-O
命令的区别就是否显示查询结果的标题。
8,连文件查
一般情况下,我们的日志文件会按天分割成很多个固定容量的子文件,在没有统一的日志收集服务器的情况下,如果不给个报错时间区间去查一个关键词,那么无异于大海捞针。 如果可以将所有文件内容合并后在查就会省事很多,q支持将文件像数据库表那样联合查询。
q -H "select * from douyin.log a join douyin-2021-06-18.0.log b on (a.c2=b.c3) where b.c1='root'"
总结
看完可能会有人抬杠:q
写这么多代码直接用awk
不香吗?额~ 介绍这个工具的初衷并不是说要替换现有哪种工具,而是多提供一种更为便捷的查日志方法。
我也有在用awk
确实很强大没得说,但这里边涉及到一个学习成本的问题,琳琅满目的命令、匹配规则想玩转还是要下点功夫的。而对于新手程序员稍微有点数据库经验,写SQL问题都不大,上手q
则会容易的多。
整理了几百本各类技术电子书,送给小伙伴们。关注公号回复【666】自行领取。和一些小伙伴们建了一个技术交流群,一起探讨技术、分享技术资料,旨在共同学习进步,如果感兴趣就加入我们吧!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
TiDB 容器化部署面面观丨「能量钛」圆桌论坛回顾
近日,由 TiDB 社区重磅策划的「能量钛」圆桌论坛活动圆满落幕。本次论坛特邀云原生社区创始人宋净超老师担任主持,与来自支流科技、360、58 集团、汽车之家、PingCAP 的五位资深技术大咖,围绕 “当数据库遇上 Kubernetes” 主题,探讨了他们对数据库容器化部署及运维的实践与思考。 视频回顾:https://www.bilibili.com/video/BV16q4y1j7UZ 嘉宾介绍: 主持:宋净超,Tetrate 布道师,云原生社区创始人。 特邀嘉宾: 张晋涛,支流科技云原生技术专家。Kubernetes 及 Docker 等众多开源项目贡献者,专注于 Apache APISIX Ingress 及 Service Mesh 等领域。 代晓磊,360 数据库运维高级专家。10 年数据库运维开发经验,开源爱好者,TUG MVA / 顾问,TiDB in action 作者之一。热爱总结和分享,喜欢挑战新技术。 刘春雷,58 集团高级 DBA。负责 58 同城 MySQL、TiDB 数据库、DorisDB 运维,TUG MOA、内容组 leader,拥有丰富的数据库开发...
- 下一篇
前端之变(五):王者归来
本周继续就前端之变阐述自己的思考。 这是本系列的第五篇,前四篇为: 前端之变(一): 技术的变与不变 前端之变(二): "不变"的前端 前端之变(三):变革与突破 前端之变(三):进击的前端 前面几篇文章我已经分析过前端的变化了。豪无疑问,前端的变化是"质变"而非"量变",它不是递进式的出现一个新的技术语言或框架,从根本上说它是一种模式颠覆性的取代另一种模式。 本篇我就来探讨与分析一下,究竟是谁给前端带来了如此巨大的改变,前端这些年究竟发生了什么事情? 我还是从前端的发展历史开始说起吧. 前端发展史 上面这个图用时间线的方式浓缩的讲述了前端重要技术的一个发展史。这个图中有几个比较重要的时间点: 2006年 JQuery发布 2008年 Chrome&V8发布 2009年 NodeJS发布,同年ES5发布 2012年 Typescript发布 2013年 React发布 2014年 Vue发布 这几个节点是值得参考的时间点。 如同我在前面的文章所阐述的,JQuery与React,Vue完全不能类比。 JQuery是『前』前端时代最有名的框架,而React与Vue则是『后』前端时代...
相关文章
文章评论
共有0条评论来说两句吧...