Exploring Loki Query Syntax

Overview of the Loki Query Syntax

As we mentioned earlier, LogQL is a slightly modified subset of the well-known PromQL many of us are using daily. That doesn't mean that we need to be an expert in PromQL to use it but rather that there's a similarity that some can leverage. Those with no prior knowledge should still have an easy time grasping it. It’s relatively simple.

That being said, teaching LogQL or PromQL is out of the scope of this course, so we suggest checking the documentation if that's a need. Our goal is to evaluate whether Loki might be the right choice for your needs, so we’ll explore it briefly without going into details, especially not on the query-language level.

Let’s take a look at the last expression and compare it to PromQL used by Prometheus.

First of all, there's no metric name we might be used to when working with Prometheus. Actually our beloved some_metric{foo="bar"} is just a shorthand for {__name__="some_metric", foo="bar"}. So, there isn't a really big difference there. We're selecting a log stream specifying labels just as we do with metrics in Prometheus.

That part of the query is called log stream selector. The usual equal and not equal operators (=, !=) are present, alongside their regex counterparts (=~, !~). What is notable in Loki is the job label. It's a convenience label that consists of a namespace and a replication controller name. Replication controllers are Deployment, StatefulSet, and DaemonSet. Basically, it's the name of the workload we want to investigate.

What's really different is the latter part (!= "GET request to /"), called a filter expression. The log exploration routine usually involves narrowing down the log stream to relevant parts.

In the good old days of Linux servers, we used to grep logs. For example, to get all problematic requests for example.com, we'd do something like the command that follows.

Note: Do not run the command that follows. It's ...