[Hawkular-dev] agent "new server" event
Michael Burman
miburman at redhat.com
Tue Mar 28 06:10:02 EDT 2017
Hi,
If you use TTL -1 in current Hawkular-Metrics, we will write without
setting TTL information. At that point the table TTL will be used (if
such is set).
- Micke
On 03/28/2017 11:36 AM, Joel Takvorian wrote:
> It could be interesting to have the possibility to deactivate TTL (for
> instance by setting a negative value, without any change in the
> existing API for that) but for the time being we could have the
> workaround of setting an arbitrary high value, no?
>
> Concerning the time range, at some point I was using "fromEarliest:
> true", " order: desc" and "limit:1" ... It seems that it could also be
> used here.
>
> Joel
>
>
> Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
> <mailto:jsanda at redhat.com>> a écrit :
>
> 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
>>> <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 <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
>> <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
> <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
More information about the hawkular-dev
mailing list