I was interested in doing this at one point in the past. A solution that I found that was useful...
If you have control of the code for your application, review it. Where in the code are you allocating resources of significance? For my purposes, I decided to disregard thread/request/connection handling since the values are essentially the same across contexts. My main memory driver was a managed cache of objects .. images, text, and encoded audio. Based on some database metadata, I was able to count the bytes of data in any object read from the database automatically in few lines of code, giving me a really nice representation of the bytes used by the cache at any given time. Database objects cached was my memory driver, so I measured that specifically (granted, using some techniques that I've developed over the years to automate database heuristics, inspired by, but not limited to, OMG.org). Then, I can access the statistics on a classloader/instance/context basis, segmented by deployment URL for my most important memory driver. Nothing better than just taking a weekend to make it through critical sections in code to understand the answers to questions like this. Can't stress that enough if you aren't already doing that. :) Be the John Henry of software code, John On 4/2/19, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
