3:30 p.m.
On Mar 16, 2015, at 4:02 PM, Lukas Krejci <lkrejci(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
<https://lists.jboss.org/mailman/listinfo/hawkular-dev>