Re: [Hawkular-dev] agent "new server" event

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(a)redhat.com > <mailto:jsanda@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(a)redhat.com >> <mailto:jshaughn@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-a... >>> <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-a... >>> >>> >>> 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(a)redhat.com <mailto:mazz@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(a)lists.jboss.org >>> <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org >> <mailto:hawkular-dev@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(a)lists.jboss.org > <mailto:hawkular-dev@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev