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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev



_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev



_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev