[Hawkular-dev] agent "new server" event

Joel Takvorian jtakvori at redhat.com
Tue Mar 28 10:43:52 EDT 2017


And btw I have the exact same problem with the inventory storage on metrics

On Tue, Mar 28, 2017 at 4:09 PM, John Sanda <jsanda at redhat.com> wrote:

> The metric definitions do not expire, but they need to be explicitly
> created for what you are suggesting to work. Even then we might run into
> problems. We are introducing a feature to purge metric definitions that
> have not received any data for some time. Unless we continue to
> periodically update the metrics used, we might run into problems.
>
> On Mar 28, 2017, at 9:25 AM, Jay Shaughnessy <jshaughn at redhat.com> wrote:
>
>
> 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> 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> 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
>>
>> 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
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
>
> _______________________________________________
> hawkular-dev mailing listhawkular-dev at lists.jboss.orghttps://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 listhawkular-dev at lists.jboss.orghttps://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
> 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/1969db53/attachment.html 


More information about the hawkular-dev mailing list