New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #10449] Livestatus log query - filter "class" yields empty results #3540
Comments
Updated by mfriedrich on 2015-10-27 20:25:58 +00:00 The parser stores log_type/class https://github.com/Icinga/icinga2/blob/master/lib/livestatus/livestatuslogutility.cpp#L104 https://github.com/Icinga/icinga2/blob/master/lib/livestatus/livestatuslogutility.cpp#L149 Yet, the logentries are handed over as is https://github.com/Icinga/icinga2/blob/master/lib/livestatus/logtable.cpp#L179 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 mfriedrich on 2015-11-25 16:07:26 +00:00
|
Updated by krausm on 2015-11-26 10:21:23 +00:00 Hi Michi, 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 ;-) Not fixed
Fixed
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 mfriedrich on 2015-11-26 18:17:08 +00:00
Applied in changeset 3d4e48a. |
Updated by mfriedrich on 2015-11-26 18:18:10 +00:00
|
Updated by krausm on 2015-11-27 15:16:59 +00:00 Hi Michi, 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. Many greetings, |
Updated by mfriedrich on 2015-11-27 15:33:09 +00:00 I can't find any reference of filtering for the "type" attribute in the MK live status docs, so I assume you can't do that. |
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... Greetings, |
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. Kind regards, |
Updated by krausm on 2015-12-02 08:35:32 +00:00 Hi Michi, 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? Many Greetings, |
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: Both queries
and
now return results. Patch file is attached. Many greetings, |
Updated by mfriedrich on 2015-12-02 10:17:52 +00:00 Ah ok, thanks. Merged. |
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
Assignee: mfriedrich
Status: Resolved (closed on 2015-11-26 18:17:08 +00:00)
Target Version: 2.4.2
Last Update: 2015-12-02 10:17:52 +00:00 (in Redmine)
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.
Greetings, Michael
Attachments
Changesets
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
The text was updated successfully, but these errors were encountered: