Hi
We are working on project and wanted monitor APM related monitoring in Nagios.
We are using check_jmx plugin to monitor the APM related metrics.
https://assets.nagios.com/downloads/nag ... ios-XI.pdf
We are trying to test it for ( websphere, jboss, tomcat, weblogic ) applications.
For IBM Webspere application we were able to make the connection successfully. But we are not able to identify objects and MBEANs from the target app.
Below is the command which is there in the document for GarbageCollection. This is not giving any results.
Is there any command to fetch all the MBEAN details from the check_jmx plugin
-U service:jmx:rmi:///jndi/rmi://127.0.0.1:7199/jmxrmi -O
java.lang:type=GarbageCollector,name=ConcurrentMarkSweep -A LastGcInfo -K
duration -u ms -vvvv -w xxx -c yyy
Thanks
Deepan.
Nagios JMX metrics Monitoring
Re: Nagios JMX metrics Monitoring
What version of Websphere are you using?
Please re-run the command but add -vvv onto the end of the command and send us the command with arguments and the full output.
I do not see an easy way to list all mbeans, you'll need to reach out to your websphere admins and have them do something like this:
https://rmoff.net/2018/09/19/exploring- ... h-jmxterm/
Please re-run the command but add -vvv onto the end of the command and send us the command with arguments and the full output.
I do not see an easy way to list all mbeans, you'll need to reach out to your websphere admins and have them do something like this:
https://rmoff.net/2018/09/19/exploring- ... h-jmxterm/
Re: Nagios JMX metrics Monitoring
Hi Ssax
We are able to achieve the monitoring using check_jmx. We had updated the jmx settings on the target server and used the service url in Nagios to fetch the app metrics to monitor it worked.
[nagios@linux8 ~]$ /usr/local/nagios/libexec/check_nrpe -H 172.99.95.94 -t 30 -c check_jmx -a '-U service:jmx:rmi:///jndi/rmi://linux2:49000/jmxrmi -O java.lang:type=Threading -A ThreadCount -w 2456 -c 4567'
JMX OK ThreadCount=230 | JMX OK ThreadCount=230
We are looking for similar solution for .net applcation, basicaly the windows box.
We really trying to push this thorugh nagios. Is there by default NCPA or NRPE agents have the provision to monitor the application metrics like jvm thread count, garbage collection, memory pool
We are able to achieve the monitoring using check_jmx. We had updated the jmx settings on the target server and used the service url in Nagios to fetch the app metrics to monitor it worked.
[nagios@linux8 ~]$ /usr/local/nagios/libexec/check_nrpe -H 172.99.95.94 -t 30 -c check_jmx -a '-U service:jmx:rmi:///jndi/rmi://linux2:49000/jmxrmi -O java.lang:type=Threading -A ThreadCount -w 2456 -c 4567'
JMX OK ThreadCount=230 | JMX OK ThreadCount=230
We are looking for similar solution for .net applcation, basicaly the windows box.
We really trying to push this thorugh nagios. Is there by default NCPA or NRPE agents have the provision to monitor the application metrics like jvm thread count, garbage collection, memory pool
Re: Nagios JMX metrics Monitoring
Yep, that's what you'd need to use to grab them (check_jmx) for Java.
Most of the .net metrics would likely be accessible via a performance counters (which NCPA or NSClient++ should support):
https://docs.microsoft.com/en-us/dotnet ... e-counters
https://support.nagios.com/kb/article/p ... s-779.html
If you need further help, please create a new forum post/ticket for it, we like to keep to one issue per post/ticket by policy to stop never ending forum posts/tickets and to reduce the confusion when referring back to them in the future (we do this a lot).
Let us know when we're okay to lock this up and mark it as resolved.
Thank you!
Most of the .net metrics would likely be accessible via a performance counters (which NCPA or NSClient++ should support):
https://docs.microsoft.com/en-us/dotnet ... e-counters
https://support.nagios.com/kb/article/p ... s-779.html
If you need further help, please create a new forum post/ticket for it, we like to keep to one issue per post/ticket by policy to stop never ending forum posts/tickets and to reduce the confusion when referring back to them in the future (we do this a lot).
Let us know when we're okay to lock this up and mark it as resolved.
Thank you!