[Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

[Thomas Segismont]

- Start a Hawkular server
- Use the REST resources under /hawkular/alerts to create a trigger for 
'my_fancy_gauge'
- Use the REST resources under /hawkular/alerts to create an external 
condition (my understanding is that such a condition will always 
evaluate to true if data is received)
- Use the REST resources under /hawkular/alerts to create a webhook action
- Use the REST resources under /hawkular/metrics to publish data


Le 10/11/2015 22:36, Stefan Negrea a écrit :
>
>
> Thomas, I will ask the same thing I asked John earlier. Can you then please walk through how to implement the feature proposed in the document? I can see how it can be done in the proposals I put in the document and discussed so far. But looks like you might have a different alternative. Do you mind explaining the alternative and walking through the design and implementation?
>
>
>
> ----- Original Message -----
>> From: "Thomas Segismont" <tsegismo at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Tuesday, November 10, 2015 3:06:33 PM
>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
>>
>> Le 10/11/2015 18:09, John Sanda a écrit :
>>>> After this long introduction, there are three main reasons the current
>>>> solution needs improvements:
>>>>>
>>>>> 1) Addressability -> the current solution does not work in the
>>>>> distributed environment because there is no clear way how to access the
>>>>> public API of the services deployed. Let's say the installation spread
>>>>> across 5 containers. How can I make a public API call from a Metrics
>>>>> instance to an Alerts instance. There is no directory to know where the
>>>>> Alerts or Metrics instances are deployed.
>>> Addressability is provided by the messaging system. There is no need for a
>>> directory. You just to need to communicate with the messaging
>>> server/broker. Beyond that there are a lot of features around
>>> addressability and routing such as message selectors, message grouping,
>>> hierarchical topics, and more.
>>
>> +1
>>
>>>
>>>>> 2) Load distribution -> there is no clear way on how the load
>>>>> distribution works or who is responsible for it.
>>> Again, this is largely handled by the messaging system. Multiple consumers
>>> take messages from a queue where each message corresponds to work to be
>>> done.
>>>
>>
>> Right, load distribution is a feature of the messaging system. As for
>> HTTP load balancing, there is hardware and software dedicated to this, I
>> would avoid building an HTTP load balancer into the project.
>>
>>>>> 3) Availability of the existing public API -> There is no reason to
>>>>> implement a new API just for the purposes of communicating between the
>>>>> components. Given that we strive for this micro-service architecture,
>>>>> the one and single public API should be the main method for
>>>>> communicating between components for request-reply.
>>> I do not think it is a given that we strive for a micro-service
>>> architecture. It might make more sense in an OpenShift environment, but I
>>> don’t think it necessarily does in general.
>>>
>>>
>>>>> We might need to extend what we have but the public API should be front
>>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other
>>>>> method), the public API interface should be available over all the
>>>>> channels. Sure there might be difference on how to make a request in JMS
>>>>> vs HTTP (one with temporary queues, and the other with direct http
>>>>> connections) but the functionality should be identical.
>>> I don’t know that I agree with this. Suppose we decide to offer an API for
>>> inserting metric data over UDP to support really high throughput
>>> situations. Are you suggesting for example that the operations we provide
>>> via REST for reading metric data should also be available via the UDP API?
>>> And since the motivation for a UDP API is performance/throughput, we might
>>> event want to a more compact request format than JSON.
>>>
>>> Lastly and most importantly, if you want push for an alternative
>>> communication mechanism between components in H-Metrics and H-Alerts, then
>>> you push for the same across all of Hawkular because it does not make to
>>> have to support two different mechanisms.
>>
>>
>> The public API (JSON over HTTP) is how the users must interact with the
>> Hawkular platform. It is the unique entry point for the users.
>>
>>
>> It's has been agreed during the project inception to make Hawkular
>> components talk to each other via the bus. It is not a trivial change to
>> break this assumption: everything the bus provides (see above) will need
>> to be re-implemented.
>> That is why I am opposed to the change, unless it is proven that it is a
>> limitation.
>>
>> _______________________________________________
>> 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
>