Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #10449] Livestatus log query - filter "class" yields empty results #3540
This issue has been migrated from Redmine: https://dev.icinga.com/issues/10449
Created by krausm on 2015-10-23 09:12:57 +00:00
A livetstatus log query with the "class" filter set yields only empty results:
Attached ist the debug log (nonworking.log.gz) with some additional output ("ADDITIONAL_DEBUG"), indicating that log_class is recognized during log parsing.
Executing the same query without the "class" filter yields results (attached file: working_results.gz):
Attached is the debug log (working.log.gz), but this shows no real differences.
Very interesting is the result of the working example:
The leading ";" indicates, that the column "class" is in fact empty. This would explain the empty result set when using the filter "class".
To summarize: either the filtering using "class" is not working or more probably the class is not stored correctly. My limited knowledge of C** hindered me, digging deeper into the second assumption.
2015-11-26 18:15:54 +00:00 by mfriedrich 3d4e48a
2015-11-26 18:18:05 +00:00 by mfriedrich bcb5eef
2015-12-02 09:08:01 +00:00 by (unknown) 5b7421a
2015-12-02 10:18:05 +00:00 by (unknown) 1ce8e64
2015-12-04 09:27:47 +00:00 by mfriedrich 55f804a
2015-12-04 09:28:02 +00:00 by mfriedrich 18b58a0
Updated by mfriedrich on 2015-10-27 20:25:58 +00:00
The parser stores log_type/class
Yet, the logentries are handed over as is
Changing the parser prefix for all log types and classes should fix it. Though I can't test my theory on my ipad now.
Updated by krausm on 2015-11-26 10:21:23 +00:00
at OSMC i had a short talk with Gunnar about that:
Do you have anyone, who could have a look on the code, or do you have a starting point / some code snippets for a c**-noob like me?
With the log parser working, we would have made a huge step for integrating Icinga2 in OMD Labs Edition: there would still exist some rough edges, but no real showstoppers.
Thanks & Greetings,
Updated by mfriedrich on 2015-11-26 18:16:48 +00:00
You should learn C** and join the team maintaining the Livestatus feature ;-)
Unfortunately the Livestatus protocol specification does not provide values for the "type" field, so this cannot be filtered by integer values (but is fixed as well).
Updated by krausm on 2015-11-27 15:16:59 +00:00
i can confirm, your "class" filter works. Ran your test "test/livestatus/queries/log/class" against a freshly checked out Icinga (branch: master).
But as i ran all your provided tests using run_queries, it seems, that the filter "type" is broken:
With some queries i found out, that no "type" filter works:
First using "time" and "class" restriction works:
But using EVERY "type" filter leads to an error message:
Notice the Error: Can't convert 'HOST ALERT' to a floating point number.
As already said, this happens with all other types as well.
Updated by krausm on 2015-11-27 16:10:46 +00:00
I did nothave a look at the docs, but seemingly Thruk uses this for its menu point "Alerts".
As already said also icinga2's own tests contain those filters already (see avail and avail_svc).
The type is set, as well as the class, for example:
Maybe i try with an older version in the next couple of days, as i wonder, why i did not see this error earlier, since clicking "Alerts" in Thruk when testing is quite normal, and i cannot imagine, that i haven't tried clicking it before...
Updated by mfriedrich on 2015-11-27 17:50:40 +00:00
Those "tests" were a manual attempt by myself in order to get some use cases and results. No need for being correct or complete. I'll happily purge them when I find the time to finish the boost tests for Livestatus.
If you think that "type" should be filtered, open a new issue. This one targets the "class" only which has been fixed.
Updated by krausm on 2015-12-02 08:35:32 +00:00
sorry for the late response and thank you for the clarification.
I started to dig into the issue to open a new issue, but then i discovered, that the type filtering may be a regression:
Livestatus query used is:
When testing that against Icinga2 2.3.11, the result is:
Testing it against Icinga2 master( 6a83703 ), the result is:
So it seems changing "log_type" to "type" caused some kind of regression. I will try to inspect that tonight.
My question is: do we track that regression here, or should i open a new issue?
Updated by krausm on 2015-12-02 09:06:40 +00:00
I reverted "type" to "log_type" in your changeset - that seems to do the trick:
now return results.
Patch file is attached.