Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Extending Grid Infrastructure Components with Monitoring Support Ondřej Krajíček Masaryk University CoreGRID
  2. 2. Infrastructure Monitoring <ul><li>Grid Infrastructure Monitoring </li></ul><ul><ul><li>important part of Grid middleware </li></ul></ul><ul><ul><li>provides information for grid management </li></ul></ul><ul><ul><li>many cluster/grid monitoring tools avaiable today </li></ul></ul><ul><ul><li>more or less inspired by the GMA proposed by GGF </li></ul></ul><ul><ul><li>assuming service-oriented grids – infrastructure components are (SOA) services </li></ul></ul>
  3. 3. Infrastructure Monitoring <ul><li>three basic aspects </li></ul><ul><ul><li>gathering monitoring data </li></ul></ul><ul><ul><li>discovery of interested parties </li></ul></ul><ul><ul><li>transport </li></ul></ul>
  4. 4. Infrastructure Monitoring <ul><li>two distinct flavors </li></ul><ul><ul><li>blackbox monitoring </li></ul></ul><ul><ul><li>whitebox monitoring </li></ul></ul>
  5. 5. I nstrumentation <ul><li>basic technique to gather data </li></ul><ul><ul><li>define metrics which describe “status” of a monitored service </li></ul></ul><ul><li>implementation </li></ul><ul><ul><li>hooks to gather values of metrics </li></ul></ul><ul><ul><li>sensors actively reading values </li></ul></ul>
  6. 6. Monitoring by Contract <ul><li>inspired by Design by Contract </li></ul><ul><ul><li>defining {pre,post}-conditions for code elements... </li></ul></ul><ul><ul><li>generalize from error handling to monitoring (monitoring conditions) </li></ul></ul><ul><li>two complementary approaches </li></ul><ul><ul><li>imperative monitoring support </li></ul></ul><ul><ul><li>declarative monitoring support </li></ul></ul>
  7. 7. Monitoring by Contract <ul><li>goals and defining features </li></ul><ul><ul><li>providing grid service monitoring support should be as transparent to the service developer as possible </li></ul></ul><ul><ul><li>service developer defines working conditions of the service as part of the service contract </li></ul></ul><ul><ul><li>the service container provides the monitoring infrastructure into which the service plugs </li></ul></ul>
  8. 8. Imperative Monitoring by Contract <ul><li>framework for particular programming environment </li></ul><ul><li>use object-oriented features to achieve the desired transparency </li></ul><ul><ul><li>aspect-oriented programming presents interesting option to implement this </li></ul></ul><ul><li>does not change the programming model, but does not require compiler changes </li></ul>
  9. 9. Imperative Example <ul><li>public static void OurMonitoredService </li></ul><ul><li>{ </li></ul><ul><li>// threadCount must be always nonzero and lower than </li></ul><ul><li>// threadLimit, otherwise we are going to fail. </li></ul><ul><li>private int threadCount = 0; </li></ul><ul><li>// defined in configuration, default is 10 </li></ul><ul><li>private int threadLimit = 10; </li></ul><ul><li>} </li></ul>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); } }
  10. 10. Imperative Example <ul><li>threadCount += 1; </li></ul><ul><li>if (threadCount > threadLimit) </li></ul><ul><li>compensateThreadCount; </li></ul><ul><li>try { </li></ul><ul><li>doSomething(); </li></ul><ul><li>} </li></ul><ul><li>catch (OurThreadException e) </li></ul><ul><li>{ </li></ul><ul><li>threadCount -= 1; </li></ul><ul><li>if (threadCount <= 0) </li></ul><ul><li>tryToCreateNewThread(); </li></ul><ul><li>... </li></ul><ul><li>} </li></ul><ul><li>threadCount += 1; </li></ul><ul><li>try { </li></ul><ul><li>doSomething(); </li></ul><ul><li>} </li></ul><ul><li>catch (AppLogicException e) </li></ul><ul><li>{ </li></ul><ul><li>compensateForAppEx(); </li></ul><ul><li>} </li></ul>
  11. 11. Imperative Example Concluded <ul><li>the goal is to focus only on application logic in the source code </li></ul><ul><li>all other aspects are handled by the runtime libraries and frameworks </li></ul><ul><li>still not ideal </li></ul>
  12. 12. Declarative Monitoring Support <ul><li>declarative programming </li></ul><ul><ul><li>syntactical constructs specify what is to be done, not how (functional programming, SQL, etc.) </li></ul></ul><ul><ul><li>currently, declarative features start to appear in production languages (Python, C#, Java, etc.), but we are only at the beginning </li></ul></ul>
  13. 13. Monitoring by Contract <ul><li>information suitable for monitoring is part of the contracts (interfaces) of methods/functions in source code </li></ul><ul><li>specifically enhanced compiler creates the “monitoring policy” from the declarations </li></ul><ul><li>service container supplied monitoring toolkit plugs at runtime and waits for assertions </li></ul>
  14. 14. Declarative Example <ul><li>public class OurMonitoredClass </li></ul><ul><li>{ </li></ul><ul><li>[Essential: threadCount > 0 and threadCount < 10] </li></ul><ul><li>[Overloaded: threadCount > 6] </li></ul><ul><li>private int threadCount = 0; </li></ul><ul><li>[Heartbeat] </li></ul><ul><li>public doSomething() </li></ul><ul><li>{ </li></ul><ul><li>// runtime will generate heartbeats here </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  15. 15. Declarative Example Concluded <ul><li>developer focuses only on application logic in the code </li></ul><ul><li>“ monitoring policy” must be defined by the developer </li></ul><ul><ul><li>may be extended by administrator </li></ul></ul><ul><ul><li>monitoring policy is a contract between service and its container </li></ul></ul>
  16. 16. Declarative Example Concluded <ul><li>support for declarative features requires changes in compilers and also in the current programming model </li></ul><ul><ul><li>they are already appearing </li></ul></ul><ul><li>letting developers focus on application logic in services leads to </li></ul><ul><ul><li>more lightweight and flexible middleware </li></ul></ul><ul><ul><li>less errors in code </li></ul></ul>
  17. 17. Conclusions <ul><li>explore the concept </li></ul><ul><li>verify the concept on some case studies </li></ul><ul><li>prototype implementation of the imperative approach </li></ul>
  18. 18. Thank you for your attention.