On Mar 16, 2015, at 4:02 PM, Lukas Krejci <lkrejci@redhat.com> wrote:
On Monday, March 16, 2015 15:07:10 John Sanda wrote:
For monitoring purposes, do we really need to write an agent? Should we just
leverage existing tools/libraries? I previously cited three common
architectures for monitoring agents,
1) embedded, in-process
2) separate process but co-located on same host
3) remote monitoring from different host
I think re-using existing stuff is desirable but 1 question needs to be
addressed first:
How are we going to configure these tools? We could just say that that is out
of the scope for Hawkular, but I don't find that too user friendly. Things
like collection intervals or disabling/enabling should be configurable from
inside Hawkular if the external tool has such capability.
Configuration is an open question, but I think it is a question that applies equally whether we are talking integration with existing tools or our own, custom monitoring agent(s). I agree that stuff like collection intervals and enabling/disabling metrics should be configurable via Hawkular. On one end of the spectrum, the integration could be completely exposed. This places the largest burden on the user because the user has to understand the various tools used in/by Hawkular. For users familiar with those tools though, it provides benefits because it gives them greater flexibility in how to set up and configure things. At the other end of the spectrum, the integration is an implementation detail to the greatest extent possible. Users only need to know how to set up/configure Hawkular. This is more along the lines of the approach we took with integrating Cassandra into RHQ. I think that answer should be somewhere in the middle so that we can give users the flexibility when they want it, but at the same time not force it on users.
Let’s consider monitoring the JVM and applications running on it. Coda Hale
Metrics is a widely used metrics library that is becoming ubiquitous. It
provides reporters for exporting metrics that are collected. The core
metrics library provides several reporters, console, JMX, CSV, to name a
few. There are plenty of 3rd party reported as well, like the Graphite
reporter. We could implement a hawkular reporter which then makes it very
easy then for any application, library, etc. that uses Coda Hale Metrics to
collect and report to hawkular.
The in-process collector might not always be possible or desirable. For
those situations the co-located agent is a better fit. jmxtrans could be an
excellent option. It can query and collect metrics from external JVMs and
then write them to other systems like Graphite, Ganglia, Open TSDB, and
more. We could implement a hawkular metrics writer.
Maybe we take a similar approach for platform metrics with collectd for
example. We are already doing something similar by seeing how we can
integrate more directly with cadvisor. Is it worth considering doing the
same with some of the tools/libraries that are already in wide spread use?
On Mar 16, 2015, at 4:13 AM, Gary Brown <gbrown@redhat.com> wrote:
This embedded 'agent' would also be useful for collecting the activity
information for RTGov. I assume information will be routed depending on
type at the backend?
Regards
Gary
----- Original Message -----
So what I heard today was we don't want a standalone agent, but we do
want
something that can be embedded in Wildfly/EAP so it can monitor things
running in Wildfly (not just monitor Wildfly itself, but applications
running inside wildfly).
That lends itself to supporting customizable modules that can be deployed
in Wildfly/EAP as hawkular subsystems.
Can someone give me a quick summary of what Wildfly-Monitor does?
https://github.com/hawkular/wildfly-monitor
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________ hawkular-dev mailing list hawkular-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev