Hi Marko,
----- Original Message -----
>
> >>>> [...] the mere installation of tools.jar would
> >> If you think it's a show-stopper then I guess we can drop the tools.jar
> >> dependency or use it alternatively/optionally.
> >
> > The latter sounds encouraging - any thoughts on how that'd be implemented?
>
> By adding one extra if-statement :-) So now when compiling you'll still
> need to provide tools.jar in classpath but thanks to lazy loading if
> using direct connections to JVMs (instead of automatic Attach API based
> connections) the classes from tools.jar are never used so no need for
> tools.jar in classpath in that case.
Sounds good to me.
> To recap, what is used from tools.jar is the Attach API [1,2] which
> provides means to automagically enable and connect JMX on local JVMs run
> by the same user so it's a nice zero-config alternative. (And sounds
> like starting with JDK 9 root should be able to connect to any JVM [3,4]
> so the same-user requirement might go away in the future.)
Got it, thanks.
> With the JSON PMDA I think we can also have an acceptable compromise
> here (do it Right but still leave some rope on the floor for those who
> are tempted to shoot themselves in the foot or can't / don't want to
> generate complete metadata e.g. for in-house/proprietary components).
+1
>
> Yeah, can't think of much value with config/mgmt data exporting but OTOH
> someone still needs to identify the relevant ones - below is one of the
> first hits when searching around this subject, it shows that the list of
> components supported by some well-known solutions is quite long so
> there's lots of items in play:
>
> https://www.appdynamics.com/solutions/appdynamics-java-monitoring/free-java-monitoring-tools/
Very handy (and long) list - thanks Marko - we certainly have our work
cut out for us.
> I'm thinking that we should (of course) aim for as complete and precise
> support in upstream as possible and in case there's no information
> available err on the safe side (i.e., ignore/skip the rest). But since
> there are in-house / proprietary components which we will never be aware
> of, provide some basic help/tools for users for creating the needed
> metadata files for them. For example, if using the JSON PMDA,
> PCPJMXConnector could easily spit out basic metadata for JMX metric it
> encountered which would then need to be updated to match reality. (And
Agreed.
> in case the need is urgent or they want to take a risk of things going
> wrong in the long term they can do it - but dealing with the fallout is
> completely up to them, nothing upstream needs to be even aware of.)
*nod*
> Since we already have data flowing thru pmdajmx.pl I'd assume it'd be
> easier to switch to the somewhat similar JSON PMDA than the MMV PMDA.
Yep - for MMV we'd need a small amount of new code to allow proxying too -
not tricky or difficult in any way, but I tend to agree that starting off
producing JSON output is a good idea.
> However, at some point it might indeed be worth checking out the
> estimated effort for MMV support - if JSON support is in the range of
> ~20 lines of code and MMV would not be radically different then it'd be
> insignificant cost for allowing additional flexibility for users.
+1
> Thanks, now I have parfait-agent.jar built.
Good stuff.
cheers.
--
Nathan
|