-
Notifications
You must be signed in to change notification settings - Fork 492
add lookup function that leverages tags in given series #690
Conversation
|
note: i couldn't get the thing to work where when you load the rule in the Rule tab, it also provides the lookup table. i was debugging the parse tree it uses in conf/conf.go to catch the lookupSeries statement but it didn't appear |
|
on @mjibson 's request, here's my alerting rule: |
cmd/bosun/conf/conf.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should stay the same, at least for now.
|
Could you also post the code where you tried to get it working in the rule page? I'd like to see that attempt. |
|
is this what you mean? |
|
Your logic is wrong, should be:
|
|
ok but printing all the nodes as we iterate over them didn't even show any lookupSeries ? |
|
i can confirm that if i change it to |
|
Err, my comment was wrong. I think your logic was right. Hold on, checking. |
|
i think my lookupSeries doesn't show up in the parse tree because it's not used in any of the computations that make up the warn or crit outcome i tried to work around it by adding an note i had to split up the macro in 2 macro's because $importance is used in the warn/crit, but to set $importance, via lookupSeries, we need access to a series which is created in the beginning of the macro. this results in: I did some debugging, so we can see with what output the function breaks. like so: the result is: i'm hoping this is enough for @mjibson to understand what's going on and help me fixing this :) |
|
I just realized, the solution we came up with yesterday (including all lookup tables from config into generated config upon rule execution, with the tables specified via web ui overriding them) works for executing the rules without missing lookup table errors, but it still doesn't address the main problem: the lookup tables that are "implicitly" used by the template are not shown in the web ui, which is an omission because i typically want to at least see, and often modify them, along with my alerting rules and template. I think that the proper solution is scanning the template for lookup table names (or perhaps i should say variables that come from lookup tables) so that we can include them. |
55ad0b6 to
9c4dc47
Compare
|
I found the cause of the panic, it was because i was using the same taglookup for both the current lookup function and the new lookupSeries. but interestingly that faulty code path was not being invoked if i only had 1 macro, and everything worked well (including the lookupSeries itself) with the faulty code. (the rule execution, template rendering etc all worked well!) the other problem still applies (loading up the rule in the web ui doesn't bring up the needed lookup tables) and the workaround i thought of (including the var from the lookuptable in the warn/crit expression) doesn't actually work though (perhaps because i'm going through a macro). but let's just merge this (the lookupSeries stuff works) and i'll open a new ticket for the problems with lookuptables. |
9c4dc47 to
57d5945
Compare
add lookup function that leverages tags in given series
and clarify lookup() lookupsSeries was implemented in #690 but not documented yet.
also gave the old lookup function a new name to clearly distinguish the two.