[Hawkular-dev] agent "new server" event

Tue Mar 28 09:25:01 EDT 2017

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 at redhat.com 
>> <mailto:jshaughn at 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-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java 
>>>
>>>
>>> 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 at redhat.com 
>>> <mailto:mazz at 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 at lists.jboss.org <mailto:hawkular-dev at 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 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/20170328/8311f982/attachment-0001.html 