[Hawkular-dev] scope of the agent design

Tue Mar 17 04:48:14 EDT 2015

On 03/16/2015 09:30 PM, John Sanda wrote:
>
>> On Mar 16, 2015, at 4:02 PM, Lukas Krejci <lkrejci at redhat.com 
>> <mailto:lkrejci at 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.

Using/Reusing those tools should be done (there is no reason to rewrite 
cAdvisor for instance which should work on any platform that supports 
Docker today), but we need a way to easily be able to configure them 
"from the server". For some "tools" we may also need to check if they 
are available and if not, use an alternative solution, install the 
missing piece, or inform the user that he's missing something.

Thomas

>
>>
>>> 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 at redhat.com 
>>>> <mailto:gbrown at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150317/fed065aa/attachment-0001.html 