perfsonar development work

["Jeff W. Boote" <>]

Hi Charaka,

Thanks for the details on your architecture. It is very interesting  
indeed.

One question that came up for me when looking at your prototype...  
What additional functionality will you gain once you remove nagios and  
plug in your own alarm/status notifiers?

To be honest, I think it would be very good to get more network  
researchers and noc operators involved in answering some of the  
questions you raise - they are similar to the ones I would ask. As to  
the aggregation/performance questions... It is fairly dependent on the  
type of data. Because of that - I had actually envisioned a slightly  
different architecture for some of the alarms:

For deriving alarm state from multiple perfSONAR services (i.e. data  
types or network locations) I definitely agree with your architecture.  
But for some of the more simple specific measurements cross specific  
threshold types of alarm states, I was actually considering the idea  
of putting nagios 'agents' into some of our perfSONAR archiving  
services directly. That way alarm states could be triggered  
immediately when the data is incorporated into the archive. This would  
minimize both alarm propagation delay as well as issues of performance  
regarding data queries.

jeff

On Sep 18, 2008, at 7:16 AM, Charaka Palansuriya wrote:

> Hi Eric, Jeff, Joe and others,
>
> Let me introduce myself. My name is Charaka Palansuriya and I am the  
> project leader (as well as a technical developer) for the JISC  
> Network Performance Monitoring (NPM) project.
>
> Nicolas mentioned that you are interested in learning more details  
> about the JISC-NPM's Alarms Service work. I put together a document  
> that explains the following in the context of an Alarms Service for  
> LHC-OPN,
>
>  1) List of alarms conditions to be monitored
>  2) List of requirements
>  3) Preliminary high level architecture
>  4) Brief explanation of the prototype we are
>     currently building
>  5) Questions (with answers we received so far)
>
> Please note that the work is still at an early stage. We are  
> presently proceeding with building a prototype. Based on this  
> experience and feedback from LHC-OPN, WiN-Labor, perfSONAR  
> developers such as your selves and others, we may alter  
> architectures as well as the underlying design and technology used.
>
> Therefore, we would greatly appreciate if you could have a look at  
> the attached document and provide feedback to us. In particular, we  
> are looking for
>
>  * Tips on analysing network measurement data (aggregation, any  
> pitfalls?)
>  * Performance considerations (how much/often can we query)
>  * Ways of alarm notification?
>  * What information should an alarm contain?
>
> Thanks in advance for your replies.
>
> Charaka
> (On behalf of the JISC-NPM team)
> --------------------------------------------------------------
> Dr Charaka J. Palansuriya         email: 
>
> Applications Consultant           phone: +44 (0)131 651 3595
> EPCC                              fax: +44 (0)131 650 6555
> _______________________________________________________________
> The University of Edinburgh is a charitable body,
> registered in Scotland, with registration number SC005336
>
>
>
>
>
> <JISC-NPM-Alarms-Service.doc>