
Dear graap, We're currently focusing on monitoring the execution of an SLA (in a grid context), ie making sure the SLA is respected. The aim is to fire notifications when violations to the contract are detected. WS-Agreements (March 2007) offer service level objectives: <wsag:ServiceLevelObjective> <wsag:KPITarget> <wsag:KPIName>xs:string</wsag:KPIName> <wsag:Target>xs:any</wsag:Target> </wsag:KPITarget> <wsag:CustomServiceLevel> ... </wsag:CustomServiceLevel> </wsag:ServiceLevelObjective> Is this the place to specify which metrics are to be monitored, along with their expected values? Has anybody used this in real life, or even as a toy? Are there examples I should refer to? I've seen many use JSDL to specify the job description, specifying in detail the resource used. But JSDL doesn't say how the resource should behave while used (ie what monitoring information should it output, and what values are acceptable?). For example, I can say I want a 1GHz processor. Where and how do I specify that while running my job the CPU should have a mean load lower than 75% ? Thanks for any pointers you may have on monitoring SLAs for Grid. Best regards Igor ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente. Pueden estar protegidos por secreto profesional Si usted recibe este correo electronico por error, gracias de informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus ------------------------------------------------------------------
participants (1)
-
Igor Rosenberg