jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Maia Borges <pmaiabor...@temenos.com>
Subject RE: Introducing MicroMeter to JMeter
Date Fri, 30 Nov 2018 17:12:26 GMT
Hi Philippe,

Regarding the vision/architecture,
I am a big fan and very knowledgeable of InfluxDB + Grafana - the benefits are amazing. Architecturally
I like your idea (I'm not really knowledgeable or have opinion on Micrometer itself specifically,
though).


There's 2 possibilities I take from your email:
a) ship metrics about the results of a test;
b) ship metrics about the internal status of JMeter;



# (a) ship metrics about the results of a test
We already have a JMeter Listener that listens to results and ships them to either Graphite
or InfluxDB.

However, I dislike that Listener so much that I developed our own plugin for my company (private
code, I'm afraid). The format of the data wasn't right and the aggregations weren't good either,
which is why I developed a new Listener.

I'd like to see a better way to ship results to Influx/Graphite/etc. But, I have to repeat
that such functionality already exists (even though I wish we had a better one).



# (b) ship metrics about the internal status of JMeter
This one is something that is almost completely missing (?).

Since JMeter is a JVM, it is by default possible to query MBeans with its status. And, by
default, lots of useful metrics are already available - generic JVM stats like Heap Size.

However it appears JMeter does not expose any JMeter-specific metrics as MBeans. One thing
that could be done would be to expose useful stats (ex: active user count, etc) as MBeans
that can then be queried/collected (ex: exposed with Jolokia, then collected with Telegraf,
then shipped to Graphite or Influx).

Finally, JMeter could have the possibility to actually ship those metrics directly to a DB
(Graphite, Influx, ElasticSearch, Solr, etc). I think this is mostly what you were referring
to?


I think it would be quite beneficial to exist:
1- Tracking of internal stats (already exists to some extent, right?);
2- Exposure of the internal stats as MBeans;
3- Ability to ship the stats periodically to ┬źdatabase┬╗ engines.

If any such a thing gets planned, I'd really like to be allowed input on which data gets collected
and the data structure / how it gets shipped to the DBs - I'd hate to see the data-structure
end up bad or sub-optimal.







Regards,
Paulo Augusto Maia Borges

-----Original Message-----
From: Philippe Mouawad <p.mouawad@ubik-ingenierie.com>
Sent: 30 November 2018 15:08
To: dev@jmeter.apache.org
Subject: Introducing MicroMeter to JMeter

Hello,
What do you think of introducing MicroMeter into JMeter:

   - It will allow us to provide monitoring Information about JMeter to
   output like:
      - log files
      - InfluxDB (http://micrometer.io/docs/registry/influx)
      - Prometheus
   - We could possibly deliver a Health Check based on some of the JVM
   Metrics:
      - http://micrometer.io/docs/ref/jvm
      - It would enable us in the future to send Live metrics using this
   way and possibly interface more systems than only InfluxDB/Graphite

It looks like a good OSS library with important support:

   - It is under Apache2 License
   - It is used in Spring Boot 2
   - It relies on HdrHistogram and LatencyUtils

Regards
Philippe M.
@philmdot

<https://www.openstreetmap.org/#map=18/50.69454/3.16455>

The information in this e-mail and any attachments is confidential and may be legally privileged.
It is intended solely for the addressee or addressees. Any use or disclosure of the contents
of this e-mail/attachments by a not intended recipient is unauthorized and may be unlawful.
If you have received this e-mail in error please notify the sender. Please note that any views
or opinions presented in this e-mail are solely those of the author and do not necessarily
represent those of TEMENOS. We recommend that you check this e-mail and any attachments against
viruses. TEMENOS accepts no liability for any damage caused by any malicious code or virus
transmitted by this e-mail.
Mime
View raw message