Re: [Hawkular-dev] scope of the agent design

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