[Hawkular-dev] Business app/services representation in Inventory
Jay Shaughnessy
jshaughn at redhat.com
Wed Apr 15 14:18:35 EDT 2015
It certainly could be. As I mentioned below, I agree that users want to
see DOWN avail during redeploy, they just don't want to see an alert.
If we incorporate deployment_status into the data being fed to alerting
then we can do this sort of alerting. Although, I'm not positive that
we want to report deployment_status in that way. I think given
reporting intervals we may encounter some edge cases.
On 4/15/2015 11:58 AM, Gary Brown wrote:
> Couldn't the deployment status be added to the trigger when relevant, e.g. avail = DOWN && deployment_status = DEPLOYED - if user wants to ignore DOWN notifications when in maintenance mode.
>
> Reason being that something checking the end to end availability of a linked (dependent) set of resources would want to know if a resource was down, regardless of whether it was in maintenance, as it impacts the higher level business app. So it may be on a case by case basis - so possibly best left to the trigger definition to determine if deployment status is relevant?
>
> Regards
> Gary
>
> ----- Original Message -----
>>
>> On 4/15/2015 7:54 AM, Thomas Heute wrote:
>>> Catching up on old emails...
>>>
>>> On 03/31/2015 02:53 PM, Gary Brown wrote:
>>>> Ok thanks for the info.
>>>>
>>>> Just to be clear - so as components are dynamically deployed/undeployed
>>>> from a server, these should be reflected in the Inventory - so it
>>>> represents a current view of the environment being managed?
>>> This is an important point.
>>>
>>> When a resource in deployed / undeployed / deployed (or redeployed), you
>>> want to know if it's there but you also want to keep historical data
>>> (say response time history before the redeployment).
>>>
>>> It also has an impact on alerts, if an app is undeployed legitimately
>>> you don't want to receive 'non-available' alerts but you want them back
>>> once the app is deployed...
>> This could be relevant if avail is reported from an external monitor,
>> like the pinger. It either needs to be aware of the redeploy, or aware
>> of some maintenance window, I think, in order to not report DOWN avail.
>> Maybe easier is to let the down avail be reported but instead mute the
>> Triggers. If Triggers are logically connected to Resources then we may
>> want to disable the triggers during certain resource-level events, like
>> a maintenance window or a scheduled redeploy operation. In RHQ I think
>> people liked to see down avail reported for a resource when it was down
>> for a redeploy. If we could optionally disable alerting then that would
>> be nice.
>>
>> Another possibility could maybe be to add some sort of validation action
>> on a trigger, or maybe some sort of callback, such that persistence and
>> further actions are ignored if validation does not pass. So, instead of
>> preventing the triggering up front, we could mute it in a
>> post-processing way.
>>
>>
>> _______________________________________________
>> 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/20150415/104e0ba5/attachment.html
More information about the hawkular-dev
mailing list