当前位置:首页 > 公众号精选 > 架构师社区
[导读]LogQL在很大程度上受Prometheus的PromQL启发。但是,当涉及到在过滤海量日志时,我们就像面临在大海捞针一样复杂。LogQL是Loki特有的语句,在本文中,我们将提供LogQL的快速过滤器查询技巧,这些查询可以在几秒钟内过滤掉数TB的数据。在Loki中,我们可以使用...


LogQL在很大程度上受Prometheus的PromQL启发。但是,当涉及到在过滤海量日志时,我们就像面临在大海捞针一样复杂。LogQL是Loki特有的语句,在本文中,我们将提供LogQL的快速过滤器查询技巧,这些查询可以在几秒钟内过滤掉数TB的数据。

在Loki中,我们可以使用三种类型的过滤器:如何用LogQL在几秒内查询TB级的日志

Label matchers

Label matchers(标签匹配器)是你的第一道防线,是大幅减少你搜索的日志数量(例如,从100TB到1TB)的最好方法。当然,这意味着你需要在的日志采集端上有良好的标签定义规范。基本上,标签应该定义的类型包括,工作负载、集群、命名空间和容器等,这样你就可以在多个不同的维度上对数据进行切分。比如说

  • 一个应用在多个集群上运行
  • 落在多个k8s集群命名空间的开发环境
  • 生产环境的命名空间
一个有效的经验法则是:你至少需要一个=匹配器(例如,{cluster="us-central1"})。否则,你将不得不提取整个索引数据。

但有一个例外。如果匹配器包含一个或多个字元,比如{container=~"promtail|agent"},同时只有一个单一的regex匹配器,Loki可以自行优化查询

下面就是一些实用的样例:

好例子:

{cluster="us-central1"}

{container="istio"}

{cluster="us-central1", container=~"agent|promtail"}
坏例子:

{job=~".*/queue"}

{namespace!~"dev-.*"}

Line filters

Line filters(行过滤器)是您的第二个好朋友,因为它们执行过程超级快。它允许你过滤包含(|=)或不包含(!=)字符串的日志,你也可以使用正则来匹配(|~)或不匹配(!~)日志,但你应该把它们放在标签匹配器之后

现在,当我们将这些过滤器连起来使用时,要注意过滤器的顺序。先用那些能过滤最多日志的过滤器,然后再使用正则,它比=!=慢。

但有一个例外。|~ "error|fatal "可以被Loki优化掉 实际上这两个字符串被loki自动过滤掉了,所以不会执行正则匹配

一个好的方法是先添加一个符合你要找的东西的过滤器,例如,|= "err"。然后再添加越来越多的不等式来过滤你不想要的东西,直到最终得到类似于下面这样的结果

|= "err" != "timeout" != "cancelled" |~ "failed.*" != "memcached"
现在,如果你意识到你的大部分错误来自memcached,那么就把它移到第一个位置

!= "memcached" |= "err" != "timeout" != "cancelled" |~ "failed.*"
这样一来,后续过滤器的执行次数就会减少。

除此之外,行过滤器也很适合查找IP、TraceID、UUID等类型的日志。比如下面这个也一个很好的查询方式

{namespace="prod"} |= "traceID=2e2er8923100"
如果你想让这个traceID的所有日志都符合某个regex,可以在ID过滤器后面加上|~ "/api/v. /query",这样就不会对prod命名空间的每个pod中去添加查询。

Label filters

Label filters(标签过滤器)提供了更复杂的计算功能(duration,numerical等),但是它们通常需要先提取标签,然后再将标签值转换为另一种类型。这意味着它们通常是最慢的,因此我们应该最后使用它们

实际上我们可以在不提取标签的情况下使用标签过滤器(使用|json|logfmt等解析器)。标签过滤器也可以在索引标签上工作。例如,{job="ingress/nginx"}。| status_code >= 400 and cluster="us-central2"可以正常工作,但你真正应该问自己的是,你是否需要将 status_code 作为索引标签。一般来说,你不应该,但你可以考虑提取 status_code 作为标签,这可以将大批量的流(每秒超过一千行)分解成独立的流。

尽管| json| logfmt解析器很快,但是解析| regex却很慢。这就是为什么在使用解析器时,我总是在它前面加上一个行过滤器。例如,在我的Go应用程序(包括Loki)中,我的所有日志均支持显示文件名和行号(此处为caller=metrics.go:83)

level=info ts=2020-12-07T21:03:22.885781801Z caller=metrics.go:83 org_id=29 traceID=4078dafcbc079822 latency=slow query="{cluster=\"ops-tools1\",job=\"loki-ops/querier\"} != \"logging.go\" != \"metrics.go\" |= \"recover\"" query_type=filter range_type=range length=168h0m1s step=5m0s duration=54.82511258s status=200 throughput=8.3GB total_bytes=454GB
因此,当我们想过滤缓慢的请求时,应该先对记录文件和行号进行过滤,然后再进行解析,最后再将提取的标签进行比较。

{namespace="loki-ops",container="query-frontend"
|= "caller=metrics.go:83" 
| logfmt 
| throughput > 1GB and duration > 10s and org_id=29

结论

这三个过滤器(Label matchers,Line filters和Label filters)就像一个管道,将逐步处理日志。我们应该尝试在每个步骤上尽可能减少操作,因为对于每个行,每个后续步骤执行的速度都可能更慢。

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
关闭
关闭