On Mon, Dec 3, 2018 at 11:03 AM Paulo Maia Borges <[email protected]>
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 <[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.
>
--
Cordialement.
Philippe Mouawad.
