My first thought was a string metric where data points are the servers that get
discovered. There are a couple things though that I do not like about this. First, all
data point queries in hawkular-metrics have a date range. Having to use a date range here
seems a bit awkward. Secondly all data points in hawkular-metrics expire. These does not
seem like data that we would want to expire.
On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy
<jshaughn(a)redhat.com> wrote:
i was thinking, perhaps it's not even necessary to involve inventory to know if the
server was reported or not. We define metrics, like avail, for these root types, I think.
At startup if the metric existed perhaps you could assume it was already reported,
otherwise you could send a "new server" event. Would that approach fly or be
easier?
On 3/27/2017 12:40 PM, Joel Takvorian wrote:
> For point 1., we can probably use some functions I wrote in the integration tests,
see there:
https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-a...
<
https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-a...
>
> I assume you can build a canonical path? (The same "canonical path" than in
the existing inventory) If so, the method "getBlueprintFromCP" gives it to you
as an Optional blueprint.
>
> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz(a)redhat.com
<mailto:mazz@redhat.com>> wrote:
> <tl;dr>
>
> Need ideas on how we are to implement the following two things in the agent:
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told
you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event to the server
about the new server EXCEPT if the server isn't really new at all (see 1. above)
>
> </tl;dr>
>
>
> ===
>
>
> This post is to open up a discussion on how we want to implement a new features in
the agent.
>
> Joel is developing a new "inventory in metrics" feature:
https://github.com/hawkular/hawkular-agent/pull/303
<
https://github.com/hawkular/hawkular-agent/pull/303>
>
> This means the agent will be storing inventory directly into Hawkular-Metrics.
Because of this, we need to figure out how to get events sent based on things happening in
H-Metric's inventory so MiQ can do things with it (like put things in the timeline
such as "new server discovered" or "new WAR was deployed").
>
> Jay looked at the code and the only thing that would be "missing" after
this move of inventory into metrics is an event triggered when a new server is added to
inventory. (When a new deployment is added, or a deployment is removed, the server is
looking at command responses and generating events from that - so we don't lose
anything by moving inventory into metrics).
>
> By "new server", what we mean is a new resource that has no parent
resources (i.e. a "root resource"). This includes standalone WildFly Servers and
domain Host Controllers.
>
> Right now, the agent starts with a "clean slate" when it starts up for the
first time, or restarts. That means the agent's in-memory inventory graph is
completely empty at startup - when discovery is run, the agent's internal inventory
graph is filled in. After that, the agent just keeps the inventory graph up to date as it
discovers new things coming and old things going away.
>
> We need the agent to know if it already stored its top level servers into H-Metrics
inventory and if it did, not to generate any "new server event". But if the
agent is brand new, and it never sent any top-level resources to H-Metrics inventory yet,
it should now send a "new server" event to the server (the agent never sent
events like this before).
>
> So there are two new things (assuming we keep the stuff Joel is doing - that is, we
store inventory into H-Metrics):
>
> 1. At startup, agent needs to ask H-Metrics "what top-level servers have I told
you about in an earlier life?"
>
> 2. When a new server is discovered, the agent should send an event (whatever this
means - probably a REST API call somewhere) about the new server EXCEPT if the server
isn't really new at all (see 1. above)
>
> We need to figure out how to implement 1. and 2. So we are soliciting thoughts on
those two subjects.
> _______________________________________________
> 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>
>
>
>
> _______________________________________________
> 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>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev