You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2018/11/30 15:08:16 UTC
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>
Re: Introducing MicroMeter to JMeter
Posted by Philippe Mouawad <ph...@gmail.com>.
On Mon, Dec 3, 2018 at 11:03 AM Paulo Maia Borges <pm...@temenos.com>
wrote:
> Hi Philippe,
>
> """That’s the benefit of Apache license."""
>
> Actually, it's a common misconception that a Software being open source
> means that any modification needs to be made publicly available, unless the
> license has some kind of exclusion like in the Apache license. That's not
> true - "open source" means that whoever receives the software (the
> binaries) is also given access to the source code. Since we're not giving
> binaries to anyone, we wouldn't have to give anyone the source code, even
> if it was a license the likes of GPL.
>
Yes you are right. I had in mind redistribution and it was not applicable
here.
>
>
> """Still, IMO, since you’re using a OSS project in your business, I see no
> reason for not contributing back to community [...] You’d help others,
> you’d be cited, officially thanked and you’d get feedback on your code."""
>
> I agree, I'd like my contribution to «give back» and I'd like it to be
> openly advertised for others to see I'm capable of doing advanced things
> with JMeter. However, the source code I developed for my employer (those
> who give me money every month in exchange for the work I give them, a fair
> exchange) belongs to my employer - I'm not the one who decides on whether
> it gets shared with the public.
>
ok.
>
>
> """At least why not contribute with your ideas."""
>
> Which is why I'm taking the time to have these interactions. I've seen
> plenty of really expensive Performance Testing Software being used
> needlessly, and some of it actually worse than the free JMeter. So I also
> want to help make JMeter as best as it can be.
>
Thanks.
>
>
> """I developed with the team Backend Listener, Graphite integration and
> fixed issues in the Influx one."""
>
> Sorry if I ended up criticising your work, I didn't mean to.
No I didn't take it like this at all.
> But the truth is that I didn't find the resulting data structure optimal.
>
> If I remember well, one example was that the Virtual User count
> ("threads") was being checked upon receiving samples, instead of
> periodically (so a period of sampler inactivity wouldn't report VU counts).
There were bugfixes on it since the begining.
> Can't remember whether the accrued data was being shipped in batches upon
> size threshold or periodically (it makes more sense periodically)? I think
> it had lack of "active/started/etc threads" per Thread Group, only totals
> (though I'm under the impression my plugin also has the same shortcoming).
Ok
> Metrics being called "ok" and "ko" instead of the likes of
> "SuccessfulTransactions"/"FailedTransactions"
The purpose was to reduce traffic
. I also seem to remember there wasn't a proper separation of results
> between different Thread Groups and/or proper separation between "Sampler"
> results and "Transaction Controller" results? Having metrics for successful
> TXs, failed TXs but also for the sum of both (might be regarded as
> redundant).
>
ok.
>
> I suspect that's why another company, NovatecConsulting, created their own
> version of the same functionality:
> https://github.com/NovaTecConsulting/JMeter-InfluxDB-Writer.
Possibly
> That's what I don't want to happen again, hence me trying to get into the
> discussion and see if I can be of any help making things better this time.
>
Ok, please continue.
>
>
>
>
> Regards,
> Paulo Augusto Maia Borges
>
> -----Original Message-----
> From: Philippe Mouawad <ph...@gmail.com>
> Sent: 30 November 2018 19:32
> To: dev@jmeter.apache.org
> Subject: Introducing MicroMeter to JMeter
>
> Hello Paulo,
>
> Find my answers inline below.
>
>
>
> On Friday, November 30, 2018, Paulo Maia Borges <pm...@temenos.com>
> wrote:
>
> > 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.
>
>
> That’s the benefit of Apache license.
>
> Still, IMO, since you’re using a OSS project in your business, I see no
> reason for not contributing back to community since this development has
> IMU no « secret » that could not be OSSed.
> You’d help others, you’d be cited, officially thanked and you’d get
> feedback on your code.
>
> At least why not contribute with your ideas.
>
>
>
> > 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).
>
>
> Yes I know, I developed with the team Backend Listener, Graphite
> integration and fixed issues in the Influx one.
> But since you say It doesn’t suit you, and there are things we want to
> improve (see Felix PR), maybe Micrometer would in a second step be an
> answer.
>
> >
> >
> >
> > # (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.
>
>
> Yes, but my idea here is to take benefit of Micrometer to lower
> complexity of doing it.
> OOTB, jmeter would be exporting data on its health to influx as ling as
> the current other metrics.
> I’d also like to add a kind of health check system that would tell user,
> beware !:
> - cpu is over a threshold
> - there a big gc pauses
> ...
>
> >
> > 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).
>
> This is already available to Influxdb.
> But with micrometer we would add those metrics and user would configure
> the repository.
>
>
> >
> > 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?
>
> That what my proposal is about.
>
> >
> >
> > 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.
>
>
> You’re welcome to already share your critics or even better your code :)
> And if you contribute to new code, your ideas will be even more taken into
> consideration :)
>
>
>
> >
> >
> >
> >
> >
> >
> > Regards,
> > Paulo Augusto Maia Borges
> >
> > -----Original Message-----
> > From: Philippe Mouawad <p....@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.
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
> 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.
>
--
Cordialement.
Philippe Mouawad.
RE: Introducing MicroMeter to JMeter
Posted by Paulo Maia Borges <pm...@temenos.com>.
Hi Philippe,
"""That’s the benefit of Apache license."""
Actually, it's a common misconception that a Software being open source means that any modification needs to be made publicly available, unless the license has some kind of exclusion like in the Apache license. That's not true - "open source" means that whoever receives the software (the binaries) is also given access to the source code. Since we're not giving binaries to anyone, we wouldn't have to give anyone the source code, even if it was a license the likes of GPL.
"""Still, IMO, since you’re using a OSS project in your business, I see no reason for not contributing back to community [...] You’d help others, you’d be cited, officially thanked and you’d get feedback on your code."""
I agree, I'd like my contribution to «give back» and I'd like it to be openly advertised for others to see I'm capable of doing advanced things with JMeter. However, the source code I developed for my employer (those who give me money every month in exchange for the work I give them, a fair exchange) belongs to my employer - I'm not the one who decides on whether it gets shared with the public.
"""At least why not contribute with your ideas."""
Which is why I'm taking the time to have these interactions. I've seen plenty of really expensive Performance Testing Software being used needlessly, and some of it actually worse than the free JMeter. So I also want to help make JMeter as best as it can be.
"""I developed with the team Backend Listener, Graphite integration and fixed issues in the Influx one."""
Sorry if I ended up criticising your work, I didn't mean to. But the truth is that I didn't find the resulting data structure optimal.
If I remember well, one example was that the Virtual User count ("threads") was being checked upon receiving samples, instead of periodically (so a period of sampler inactivity wouldn't report VU counts). Can't remember whether the accrued data was being shipped in batches upon size threshold or periodically (it makes more sense periodically)? I think it had lack of "active/started/etc threads" per Thread Group, only totals (though I'm under the impression my plugin also has the same shortcoming). Metrics being called "ok" and "ko" instead of the likes of "SuccessfulTransactions"/"FailedTransactions". I also seem to remember there wasn't a proper separation of results between different Thread Groups and/or proper separation between "Sampler" results and "Transaction Controller" results? Having metrics for successful TXs, failed TXs but also for the sum of both (might be regarded as redundant).
I suspect that's why another company, NovatecConsulting, created their own version of the same functionality:
https://github.com/NovaTecConsulting/JMeter-InfluxDB-Writer. That's what I don't want to happen again, hence me trying to get into the discussion and see if I can be of any help making things better this time.
Regards,
Paulo Augusto Maia Borges
-----Original Message-----
From: Philippe Mouawad <ph...@gmail.com>
Sent: 30 November 2018 19:32
To: dev@jmeter.apache.org
Subject: Introducing MicroMeter to JMeter
Hello Paulo,
Find my answers inline below.
On Friday, November 30, 2018, Paulo Maia Borges <pm...@temenos.com>
wrote:
> 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.
That’s the benefit of Apache license.
Still, IMO, since you’re using a OSS project in your business, I see no reason for not contributing back to community since this development has IMU no « secret » that could not be OSSed.
You’d help others, you’d be cited, officially thanked and you’d get feedback on your code.
At least why not contribute with your ideas.
> 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).
Yes I know, I developed with the team Backend Listener, Graphite integration and fixed issues in the Influx one.
But since you say It doesn’t suit you, and there are things we want to improve (see Felix PR), maybe Micrometer would in a second step be an answer.
>
>
>
> # (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.
Yes, but my idea here is to take benefit of Micrometer to lower complexity of doing it.
OOTB, jmeter would be exporting data on its health to influx as ling as the current other metrics.
I’d also like to add a kind of health check system that would tell user, beware !:
- cpu is over a threshold
- there a big gc pauses
...
>
> 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).
This is already available to Influxdb.
But with micrometer we would add those metrics and user would configure the repository.
>
> 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?
That what my proposal is about.
>
>
> 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.
You’re welcome to already share your critics or even better your code :) And if you contribute to new code, your ideas will be even more taken into consideration :)
>
>
>
>
>
>
> Regards,
> Paulo Augusto Maia Borges
>
> -----Original Message-----
> From: Philippe Mouawad <p....@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.
>
--
Cordialement.
Philippe Mouawad.
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.
Introducing MicroMeter to JMeter
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Paulo,
Find my answers inline below.
On Friday, November 30, 2018, Paulo Maia Borges <pm...@temenos.com>
wrote:
> 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.
That’s the benefit of Apache license.
Still, IMO, since you’re using a OSS project in your business, I see no
reason for not contributing back to community since this development has
IMU no « secret » that could not be OSSed.
You’d help others, you’d be cited, officially thanked and you’d get
feedback on your code.
At least why not contribute with your ideas.
> 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).
Yes I know, I developed with the team Backend Listener, Graphite
integration and fixed issues in the Influx one.
But since you say It doesn’t suit you, and there are things we want to
improve (see Felix PR), maybe Micrometer would in a second step be an
answer.
>
>
>
> # (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.
Yes, but my idea here is to take benefit of Micrometer to lower complexity
of doing it.
OOTB, jmeter would be exporting data on its health to influx as ling as the
current other metrics.
I’d also like to add a kind of health check system that would tell user,
beware !:
- cpu is over a threshold
- there a big gc pauses
...
>
> 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).
This is already available to Influxdb.
But with micrometer we would add those metrics and user would configure the
repository.
>
> 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?
That what my proposal is about.
>
>
> 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.
You’re welcome to already share your critics or even better your code :)
And if you contribute to new code, your ideas will be even more taken into
consideration :)
>
>
>
>
>
>
> Regards,
> Paulo Augusto Maia Borges
>
> -----Original Message-----
> From: Philippe Mouawad <p....@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.
>
--
Cordialement.
Philippe Mouawad.
RE: Introducing MicroMeter to JMeter
Posted by Paulo Maia Borges <pm...@temenos.com>.
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....@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.