Please have a look into the documentation here and check the alert creating process with it?
For the Metric Value Threshold [Actual Free Memory > 1023.0 KB] it works perfect.
Please do not hesitate to come back if you have further questions.
Thanks for the link to documentation. I read through all the documentation regarding the alerts and verified that I have created the alert definitions as instructed. My alert definitions look fine and they are listed and enabled, but they still never fire even when their conditions are met.
Do you have any ideas what could be the reason?
1 of 1 people found this helpful
this is very strange. Have you seen any "anomalies" in the server log? $RHQ_HOME/logs/rhq-server-log4j.log
Yes, there seems to be lots of lines like this:
ERROR [org.rhq.enterprise.server.measurement.MeasurementCompressionManagerBean] Unable to compress data from [RHQ_MEAS_DATA_NUM_R11] to [RHQ_MEASUREMENT_DATA_NUM_1H] at 8/8/12 2:00:00 PM: java.sql.SQLException:Incorrect syntax near the keyword 'SELECT'.[SQLException=Incorrect syntax near the keyword 'SELECT'. -> Incorrect syntax near ')'.(error-code=102,sql-state=42000)]
I don't know if this could be the reason. At least there are no errors appearing to the log constantly every minute, although my measurements should be collected every minute.
I don't what is the reason for these errors. In rhq-server.properties I have
This work was done a couple years ago and, while most worked as a proof-of-concept, it was never completed (thus why the big red box says don't use SQL Server as your backend in a production environment).
As I understand it, SQL Server doesn't support MVCC and that caused a lot of problems, some of which weren't solved, and it had some weird locking (something about it only does table locking with some kind of special row locking only being introduced in MSSQL 2005 via some database setting?? I don't know the details, this is based on memories several years old ). SQL Server is just not as good a DB to work with compared with Oracle or Postgres (I've not worked with it personally, but that's what I gathered to be the case listening to Joe complain almost daily when he was working on this )
Thus, the recommended solution: switch to Postgres or Oracle.
Executing "ALTER DATABASE rhq SET READ_COMMITTED_SNAPSHOT ON" solved this problem.