Extending Grid Infrastructure Components with Monitoring Support

1. Extending Grid Infrastructure Components with Monitoring Support Ondřej Krajíček Masaryk University CoreGRID

2. Infrastructure Monitoring • Grid Infrastructure Monitoring • important part of Grid middleware • provides information for grid management • many cluster/grid monitoring tools avaiable today • more or less inspired by the GMA proposed by GGF • assuming service-oriented grids – infrastructure components are (SOA) services CGW 2006

3. Infrastructure Monitoring • three basic aspects • gathering monitoring data • discovery of interested parties • transport CGW 2006

4. Instrumentation • basic technique to gather data • define metrics which describe “status” of a monitored service • implementation • hooks to gather values of metrics • sensors actively reading values CGW 2006

5. Monitoring by Contract • inspired by Design by Contract • defining {pre,post}-conditions for code elements... • generalize from error handling to monitoring (monitoring conditions) • two complementary approaches • imperative monitoring support • declarative monitoring support CGW 2006

6. Monitoring by Contract • goals and defining features • providing grid service monitoring support should be as transparent to the service developer as possible • service developer defines working conditions of the service as part of the service contract • the service container provides the monitoring infrastructure into which the service plugs CGW 2006

7. Imperative Monitoring by Contract • framework for particular programming environment • use object-oriented features to achieve the desired transparency • aspect-oriented programming presents interesting option to implement this • does not change the programming model, but does not require compiler changes CGW 2006

8. Imperative Example public static void OurMonitoredService { // threadCount must be always nonzero and lower than // threadLimit, otherwise we are going to fail. private int threadCount = 0; // defined in configuration, default is 10 private int threadLimit = 10; } public static void OurMonitoredService { // threadCount must be always nonzero and lower than // threadLimit. private CheckedValue<int> threadCount; public OurMonitoredService() { threadCount = new CheckedValue<int>(0, new Constraint<int>10); } } CGW 2006

9. threadCount += 1; if (threadCount > threadLimit) compensateThreadCount; try { doSomething(); } catch (OurThreadException e) { threadCount -= 1; if (threadCount <= 0) tryToCreateNewThread(); ... } threadCount += 1; try { doSomething(); } catch (AppLogicException e) { compensateForAppEx(); } Imperative Example CGW 2006

10. Imperative Example Concluded • the goal is to focus only on application logic in the source code • all other aspects are handled by the runtime libraries and frameworks • still not ideal CGW 2006

11. Declarative Monitoring Support • declarative programming • syntactical constructs specify what is to be done, not how (functional programming, SQL, etc.) • currently, declarative features start to appear in production languages (Python, C#, Java, etc.), but we are only at the beginning CGW 2006

12. Monitoring by Contract • information suitable for monitoring is part of the contracts (interfaces) of methods/functions in source code • specifically enhanced compiler creates the “monitoring policy” from the declarations • service container supplied monitoring toolkit plugs at runtime and waits for assertions CGW 2006

13. Declarative Example public class OurMonitoredClass { [Essential: threadCount > 0 and threadCount < 10] [Overloaded: threadCount > 6] private int threadCount = 0; [Heartbeat] public doSomething() { // runtime will generate heartbeats here } } CGW 2006

14. Declarative Example Concluded • developer focuses only on application logic in the code • “monitoring policy” must be defined by the developer • may be extended by administrator • monitoring policy is a contract between service and its container CGW 2006

15. Declarative Example Concluded • support for declarative features requires changes in compilers and also in the current programming model • they are already appearing • letting developers focus on application logic in services leads to • more lightweight and flexible middleware • less errors in code CGW 2006

16. Conclusions • explore the concept • verify the concept on some case studies • prototype implementation of the imperative approach CGW 2006

17. Thank you for your attention.