perfsonar development work

[Florian Scharinger <>]

Hello Jeff,

Thank you for your quick response. My name is Florian Scharinger and I  
am one of the software engineers working with Charaka to create the  
NPM Alarm System. Let me comment inline.

On 18 Sep 2008, at 8:45PM, Jeff W. Boote wrote:

> 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?

From our point of view, the visualisation and the Alarm System should  
be loosely coupled, in order to allow different notification  
mechanisms for different (types of) users. The users should be allowed  
to pick their preferred interface. We chose to use Nagios for now to  
have a straightforward visualisation during this prototyping stage.

We found that the Host->Service structure that Nagios uses to  
configure and display alarms does not match directly the Domain -  
Interface/Path - Alarm Type structure of an alarm. Hence a separate  
visualisation plug-in would be an obvious additional functionality.


> 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.

This is why the architecture contains the "Alarm Notification  
Service", which would allow MAs to push detected alarms to our Alarm  
System (this might not be explained in the document clear enough).  
However, how this interface looks like is undefined at this early  
stage, and we welcome any suggestions.


Please don't hesitate to comment/ask further questions.

Regards,
Florian.


> jeff



| - - - - - - - - - - - - - - - - - - - - - -
  Florian Scharinger
  EPCC
  University of Edinburgh

  The University of Edinburgh is a charitable body, registered in  
Scotland, with registration number SC005336.