Bug #34188 | Core advisors can be altered, but this prevents monitoring from working properly | ||
---|---|---|---|
Submitted: | 31 Jan 2008 8:03 | Modified: | 8 Dec 2008 21:12 |
Reporter: | Valeriy Kravchuk | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Enterprise Monitor: Advisors/Rules | Severity: | S3 (Non-critical) |
Version: | 1.x, 2.x | OS: | Any |
Assigned to: | Sloan Childers | CPU Architecture: | Any |
[31 Jan 2008 8:03]
Valeriy Kravchuk
[22 Feb 2008 19:51]
Gary Whizin
Will consider preventing user from making a change like this that has unexpected, negative consequences.
[26 Jun 2008 23:28]
Sloan Childers
I don't think we should deny editing these special rules. The real problem is that unscheduling the agent_not_reachable (0f8ed31d-2655-4848-af39-9069a5076653) and/or the agent_not_communicating_with_mysqld (f6801cf3-a3f9-4eea-88b5-9639b0659e7c) rules and replacing them with customized rules breaks random status display indicators in the user interface. We could either ask the RuleContainer at the JSP layer whether or not a rule is unschedulable and gray out the appropriate controls OR I suppose the server back end could deny the request and throw an exception for these two special rules.
[5 Dec 2008 20:29]
Sloan Childers
This scenario works in 2.0 if you changing the expression as follows: (CURTIME() NOT BETWEEN '02:00:00' AND '05:30:00' && %agent.reachable% = THRESHOLD) You *must* also add a string "" for the warning threshold or the evaluation fails.
[8 Dec 2008 21:05]
Sloan Childers
This scenario works in 1.3.3 if you changing the expression as follows: (CURTIME() NOT BETWEEN '02:00:00' AND '05:30:00' && %agent.reachable% = THRESHOLD)
[8 Dec 2008 21:12]
Sloan Childers
If we also see customer issues with these rules just being unscheduled, please open a bug/feature that is specific to that problem.