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 <[email protected]>
Sent: 30 November 2018 19:32
To: [email protected]
Subject: Introducing MicroMeter to JMeter
Hello Paulo,
Find my answers inline below.
On Friday, November 30, 2018, Paulo Maia Borges <[email protected]>
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 <[email protected]>
> Sent: 30 November 2018 15:08
> To: [email protected]
> 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.
