One of my pet peeves with all log searches is that it usually tries to throw you in the deep end of the the query language from the the get go… (This goes for most[if not all] log solutions, at least the few I had experience with. BetterStack probably being the least worse). If Quickwit can also solve for that, it would definitely put them many steps ahead IMO.
Any junior teammate, or just any person that is not their day-to-day work to search stuff on this very specific log query language, is usually just left very confused that they are searching for veeery basic things, and it doesn’t return what they want.
The peak bad experience is when everything usually “just works”, no one is very used to the specialized query langague, and once a quarter when you DO have an incident and NEED to jump on the logs to search something, it feels like they are working against you, while you are trying to search for the simplest thing to frantically extinguish a fire.
IMO, plaintext search is usually more than enough in most debug scenarios, the average user is completely oblivious to the specialized query language. Or something akin to splitting the plaintext on the space characters and search of all messages that have all the keywords… But I have no idea if that plays nicely with whatever index you have powering this.
Could also be 2 separate querying fields, one specifically saying “basic search”, and one “advanced search”… It could be just a fallback, to not try to do force the search as the query language, if it is simply not a valid query, and fallback to plaintext… IDK…
…
I work mainly with with Ruby, and one of the most common things for me to search for is for some error/message happening on/inside a specific class. My first instinct when opening the logs for the first time was, that I saw a few logs about one of these classes, and to search for that class name. Then it became a looong game of guessing how to query for it…
Here is an example log that I saw, and was expecting to find things similar to it:
2024-05-27T12:24:23.073Z pid=322 tid=c0ku class=Example::My::Class jid=ef21583701f2666ab06234534 INFO: started processing whatever, with id 12345
ˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆ
And my tentatives searches until finally it working:
Example::My::Class
→ Error, and saying “No data”
"Example::My::Class"
→ Error, and saying “No data”
'Example::My::Class'
→ Error, and saying “No data”
Example\:\:My\:\:Class
→ Error, and saying “No data”
"Example\:\:My\:\:Class"
→ Error, and saying “No data”
'Example\:\:My\:\:Class'
→
No error!, but also “No data”
- Gave up on trying it blindly, and had to search on Google about this Fly feature… found this topic, and found out that it was powered by Quickwit, went to their site, looked for the docs, took a minute to find the query language docs. Looks like the
message:
prefix may help; even though it feels like it should yield the same results as not adding the field prefix
…
message:Example::My::Class
→ Error, and saying “No data”
message:"Example::My::Class"
→ Error, and saying “No data”
message:'Example::My::Class'
→
Finally! Can see the results I would expect…
- Just for completion’s sake,
message:Example\:\:My\:\:Class
→ Error, and saying “No data”
…
Anyway, even if we disagree on all of the above; at a MINIMUM, on that Grafana page, you should have links to the Quickwit docs about the query language. Like this and this.
Hope this feedback is useful to make this feature one of the best out there
. Love it being integrated into the Fly solutions
. Would definitely pay extra for it.