[Hawkular-dev] agent "new server" event
John Sanda
jsanda at redhat.com
Tue Mar 28 09:19:58 EDT 2017
On Mar 28, 2017, at 9:04 AM, Michael Burman <miburman at redhat.com> wrote:
>
> I don't think Cassandra supports that. If there's a table TTL, one needs
> to set a TTL to override the default expiry.
Correct. I think different table that uses deletes might be a better option.
>
> - Micke
>
>
> On 03/28/2017 03:34 PM, John Mazzitelli wrote:
>> how about make a value -2 meaning "no TTL at all - ignore even the table TTL"
>>
>> ----- Original Message -----
>>> 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
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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