-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Fellipe,
On 4/2/19 17:04, Fellipe Theophilo wrote: > Hi everyone, I'm trying to find a way to monitor metrics of > resources comsumption at context level. I've opened this thread: > https://stackoverflow.com/questions/55070370/monitoring-multiple-java- applications-at-once-with-one-zabbix-java-gateway > > But no one knows a solution. By using jConsole and Zabbix I can > check the value of some objects at context level, but none of them > is any metric. So I tried the Spring Actuator, which expose many > metrics through REST , returning a JSON. However, the call to > http://<tomcat_address>:8080/<context_name>/metrics give metrics > information of the JVM as a whole, even specifying the context > name. To prove this I ran an AB(Apache Benchmark) to do a stress > test and I've saw that memory usage grew together across the two > contexts I have for testing. So the conclusion is that the Spring > Actuator is not exposing metrics at context level. Do anyone know > if is there a way to get metrics at context level? The reason that no tool provides per-context memory consumption metrics is because it's not practical to actually measure that kind of thing. You'd basically need to walk the object tree from GC roots (like the GC does whenever it collects garbage) after determining what the list of "GC roots" is for each context -- such as the WebappClassLoader. The JVM treats memory as a shared resource. There is no memory isolation between contexts within an application server. If you really want to monitor your web applications separately, run them each in isolated JVMs. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyj6cMACgkQHPApP6U8 pFhcKBAAiAUUS9pchJB0JIjTrldg4VOAuLxyTOMQG7qiaffDq/eQCac7OAH4uoaf Z7gCV44QK+rIpRmKqSdHWEEccGZ0b0ywPnLM7GUUptynL2ZYB7qTH7/wjnzsEKPV pMdDp06d5eo5dAFyKiKSkT8bT2h6+wmbP/xrWkgL4DtyUPQzbPOIgRdjDPfihaxp 0l0xI8H/HYaqyNhxj0xDmEy7IbO2buNt5kUzrC2HmS+TC+rl4rlUDEUAISK9vz6a WTGaYnGCbbbDmAJc2NtRMSwCMrzt4Oz3yLJR1+HzFCidmKYasCVTOp3elBtctvzE BEUuKOgNIo9f1rte2HKj1nAoxrKOw4hlWfdqqxfIm3yBk3ThtGEjMAoa0enfKXnt kWObLMuL64c+XEmmqDMh4Q1AwpvzFeIQ1KgcxBGSGcgsmYZQQRY2LIE7TMI20Xp/ b4Xv19+0HoI6VqHVL8pXt8BWznjM+ygJb2mtUuO4nFRGuCYSLw6s2IqrL59p4Pld DtsBa5U5eehtIrYOlHi9qndQP5G9BtbSHe4HI5U3mkqC5i2f3oywzHKcE5/roTc0 19zMzkJL8ISDcnZ7EBUgV5Qx13q+nEQeu9gZfjQjQCMTTIcmWnyrvWcRjIUUZwb7 2cCG80EfB5iny3fR0gtozj/SDmx5TOxU3MMnMunBQVZOoqf7uyc= =uO0P -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
