If we could just use existing metrics to make the determination we could
avoid the TTL issue, I think. If we went with something like below I'd
just suggest a single metric definition with a tag for each server
name. Do metric defs suffer from TTL?
On 3/27/2017 11:36 PM, John Sanda wrote:
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
> <mailto:jshaughn@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...
>>
>>
>> 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
>>
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