[Hawkular-dev] agent "new server" event
Joel Takvorian
jtakvori at redhat.com
Tue Mar 28 09:25:39 EDT 2017
Maybe the longer-term solution would be a taggable key-value store? Either
generic or dedicated...
On Tue, Mar 28, 2017 at 3:04 PM, 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.
>
> - 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170328/0855b5b7/attachment.html
More information about the hawkular-dev
mailing list