Difference between revisions of "ESciDoc Monitoring"
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
: we use OpenNMS in MPDL. (Also one other System Management Framework at GWDG, but OpenNMS when we have the choice). Opennms already has a [http://www.opennms.org/wiki/JMX_Collector jmxcollector official documentation] and there is some more up-to-date user-supplied documentation [http://www.opennms.org/wiki/Tomcat_6_JMX_How-To Tomcat6 in OpenNMS JMS Howto]. | : we use OpenNMS in MPDL. (Also one other System Management Framework at GWDG, but OpenNMS when we have the choice). Opennms already has a [http://www.opennms.org/wiki/JMX_Collector jmxcollector official documentation] and there is some more up-to-date user-supplied documentation [http://www.opennms.org/wiki/Tomcat_6_JMX_How-To Tomcat6 in OpenNMS JMS Howto]. | ||
: For a first step, it's nice that they have this collector running locally (on the OpenNMS machine, not on the ESciDoc machine being monitored) because it's simple to setup and test, and it means no SNMP stack in the ESciDoc Java VM.. JMX-Remoting as described in this documentation is however not a good idea '''at all''' in terms of security. A local JMX Connector that is configurable to either log (via Log4J for example) or transmit the data that has been configured for collection out via SNMP would be much better. Security is something else I will be working on over the next year. | : For a first step, it's nice that they have this collector running locally (on the OpenNMS machine, not on the ESciDoc machine being monitored) because it's simple to setup and test, and it means no SNMP stack in the ESciDoc Java VM.. JMX-Remoting as described in this documentation is however not a good idea '''at all''' in terms of security. A local JMX Connector that is configurable to either log (via Log4J for example, just so long as there is then a way to import the logged performance data into a spreedsheet the log format is not something that bothers me) or transmit the data that has been configured for collection out via SNMP would be much better. Security is something else I will be working on over the next year. | ||
: As regards what should be monitored, here is my initial, brainstormed list. | : As regards what should be monitored, here is my initial, brainstormed list. | ||
| Line 21: | Line 21: | ||
# Lots more possible measurement within the ESciDoc application itself. I'm still climbing the learning curve and don't want to speculate. | # Lots more possible measurement within the ESciDoc application itself. I'm still climbing the learning curve and don't want to speculate. | ||
--[[User:Bourke|Bourke]] 09:48, 27 July 2011 (CEST) | : --[[User:Bourke|Bourke]] 09:48, 27 July 2011 (CEST) | ||
[[Category:eSciDoc|Monitoring]] | [[Category:eSciDoc|Monitoring]] | ||
Latest revision as of 09:51, 27 July 2011
Monitoring eSciDoc Infrastructure[edit]
For now it's not set how the monitored values are delivered to external systems. Of course SNMP seems to be a good options and an log4j snmp adapter could be used.
Which values are to monitor? We should define a prioritized list.
Which monitoring system do you currently use?
- we use OpenNMS in MPDL. (Also one other System Management Framework at GWDG, but OpenNMS when we have the choice). Opennms already has a jmxcollector official documentation and there is some more up-to-date user-supplied documentation Tomcat6 in OpenNMS JMS Howto.
- For a first step, it's nice that they have this collector running locally (on the OpenNMS machine, not on the ESciDoc machine being monitored) because it's simple to setup and test, and it means no SNMP stack in the ESciDoc Java VM.. JMX-Remoting as described in this documentation is however not a good idea at all in terms of security. A local JMX Connector that is configurable to either log (via Log4J for example, just so long as there is then a way to import the logged performance data into a spreedsheet the log format is not something that bothers me) or transmit the data that has been configured for collection out via SNMP would be much better. Security is something else I will be working on over the next year.
- As regards what should be monitored, here is my initial, brainstormed list.
- HeapFreePercent from JVM runtime
- FullGCs. Is there any way to gather the data on number of fullGCs and average duration of each FullGC? I should probably test it with VisualVM. It certainly can be graphed within that tool
- Per Threadpool Number of Idle Threads, number of active threads.
- If there is in JBoss a JMX-reachable parameter for what I know from my (BEA WebLogic) background as "Execute Queuelength", then I haven't found it, and I want to. (But I need to find and install a JBoss4-capable Adminserver eg EmbeddedJopr and double check that. "Execute QueueLength" is the number of requests accepted via sockets into JBoss and not yet dispatched to a free worker Thread in the Threadpool. I really find it difficult to believe that JBoss 4.2.x doesn't track that information, but I certainly never found it by clicking around in the JMX-Console. And the System Administration documentation of JBoss free edition is pretty limited, that sort of functionality is normally a cue for RedHat to talk to the customer about upgrading to the Enterprise Edition, I think :)
- jdbc connection pool to PostgreSQL number of free connections, number of active connections
- Lots more possible measurement within the ESciDoc application itself. I'm still climbing the learning curve and don't want to speculate.
- --Bourke 09:48, 27 July 2011 (CEST)