ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "vitthal (Suhas) Gogate (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AMBARI-6354) Alerts Design and Implementation
Date Tue, 26 Aug 2014 05:05:58 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109991#comment-14109991
] 

vitthal (Suhas) Gogate edited comment on AMBARI-6354 at 8/26/14 5:05 AM:
-------------------------------------------------------------------------

Nate, thanks for sharing the design of alert monitoring in Ambari. Here are some review comments
and questions about the design,

-- For various reasons, It is very important for Ambari to support Alert monitoring through
an inbuilt mechanism via ambari agents and not solely relying on the external monitoring services
like Nagios. So thanks for initiating the efforts! 

-- Although having a pluggable interface for Ambari to work with many existing monitoring
systems like Nagios/Zabbix etc. would be really important for some users who has already invested
in those monitoring systems for their other infrastructure components. Looking at current
design, the approach is to have Ambari do the alert monitoring via its agents and then dispatch
these alerts to other monitoring systems. This may not be ideal for some users(see some examples
below). 
   ** Users familiar with existing Monitoring systems may want to configure all the alerts
including Hadoop services, all in one place. 
   ** Advance alerts management features such as alert aggregation, correlation, mitigation
etc. can be done uniformly across various alerts with their existing monitoring system as
opposed to partly in Ambari. 
   ** Etc. 

-- So I was wondering, if we make Ambari server internally communicate with existing monitoring
systems with standard pluggable interface?  This design point is orthogonal to current Ambari
alert monitoring design. Ambari's alert monitoring would be one of the implementations of
the pluggable monitoring interface and serve as out-of-box default implementation for Ambari
managed services. Although advantage is that, it would also facilitate other users to add
the implementation for their existing monitoring system. 

I can propose the initial draft of the interface for alert monitoring and see how we can get
the existing Ambari alert monitoring to plug in under that interface.. 

Let me know what you think? 


was (Author: vitthal_gogate):
Nate, thanks for sharing the design of alert monitoring in Ambari. Here are some review comments
and questions about the design,

-- It is very important for Ambari to support the Alert monitoring through an inbuilt mechanism
via ambari agents and not solely relying on the external monitoring services like Nagios for
various reasons. So thanks for initiating the efforts! 

-- Although having a pluggable interface for Ambari to work with many existing monitoring
systems like Nagios/Zabbix etc. would be really important for some users who has already invested
in those monitoring systems for their other infrastructure components. Looking at current
design, the approach is to have Ambari do the alert monitoring via its agents and then dispatch
these alerts to other monitoring systems. This may not be ideal for some users(see some examples
below). 
   ** Users familiar with existing Monitoring systems may want to configure all the alerts
including Hadoop services, all in one place. 
   ** Advance alerts management features such as alert aggregation, correlation, mitigation
etc. can be done uniformly across various alerts with their existing monitoring system as
opposed to partly in Ambari. 
   ** Etc. 

-- So I was wondering, if we make Ambari server internally communicate with existing monitoring
systems with standard pluggable interface?  This design point orthogonal to current Ambari
alert monitoring design. The Ambari alert monitoring would be one of the implementations of
the proposed pluggable monitoring interface and serve as out-of-box default implementation
for Ambari managed services. Although advantage is that, it would also facilitate other users
to add the implementation for their own monitoring system. 

I can propose the interface for alert monitoring and see how we can get the existing Ambari
alert monitoring to plug in under that interface.. 

Let me know what you think? 

> Alerts Design and Implementation
> --------------------------------
>
>                 Key: AMBARI-6354
>                 URL: https://issues.apache.org/jira/browse/AMBARI-6354
>             Project: Ambari
>          Issue Type: Epic
>          Components: agent, client, controller
>            Reporter: Nate Cole
>            Assignee: Nate Cole
>             Fix For: 1.7.0
>
>         Attachments: AlertTechDesignPublic.pdf
>
>
> The purpose of this umbrella JIRA is to track a new feature that enables Ambari to be
the source of Alert data for a cluster.
> * "Black box" Nagios and not make it a hard dependency of Ambari.
> * Allow custom defined alerts and thresholds.
> * Flexibly define how alerts get published, and recipients of those alerts.
> * Use stacks to define baseline alerts for a cluster that can themselves be customized.
> (As design documents are completed, they will be attached to this JIRA)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message