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

On 13 Mar 2015, at 8:57, Thomas Heute wrote: While this may first sound like a disadvantage, it can also be seen as advantage. In RHQ when we lost the connection to the agent, all the resources behind it were at backfilling considered as down. Now when when have e.g. the pinger in a different location and this sees that the application is reachable, we could "overwrite" the unavailable data from the agent. (and yes, I know that the previous sentence/scenario was oversimplified). Similar when the embedded agent is not able to send perhaps due to high usage of the app server, the platform agent can still see if the process is up and report it as up. Or the other way around. The embedded agent sends a "UP" report every minute, but the external agent can detect that the PID has changed and can either report a "DOWN" for the time in between two ups (which may be too much) or at least report a "tag" that the server process was rebooted, which can then later be displayed to the user in the charts. This may then explain why some resource usage is higher/lower than before. We have started this discussion (from a different angle) in two different places already - the Alert on URL return code mail http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000402.html and "Computed Resource State" http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html The point is that the very strict 1:1 mapping that we had in RHQ is not enough. In scenarios like Aircraft, they often even have a 2 of 3 voting principle.