Presentation on theme: "Considerations for Monitoring Root Container Resource Consumption Measurement of Component Hierarchies C1 C2,2 C2,1 Root Container."— Presentation transcript:
Considerations for Monitoring
Root Container Resource Consumption Measurement of Component Hierarchies C1 C2,2 C2,1 Root Container C1 C2,1 C2,2 Root Container C1 C2,1C2,2 Containment Hierarchy Depending on component type and the way resource consumption is measured for it, containee resource consumption may not be visible C1 does not provide resource consumption metric for its containees. C1’s resource consumption includes its containees C1 provides consumption metric for its containees How can we quantify the resource consumption of a component hierarchy?
Scaling Metrics In order to track dynamic instances we need metrics such as – Min, Max, Desired # of Instances – Available + Starting + StandyBy + Terminating = Total – GroupSpec Members comprising the dynamic set, e.g. WebTier, WebApps in Container X 3
Metric Type vs Collection vs Consumption Metric – Type – Unit – Max Frequency – Preferred Frequency – Aggregation Semantic – Node State 4 CollectionSpec – Type – Subjects – Frequency ServiceLevelObjective – CollectionSpec – Filter – Threshold – EventSpec (e.g. scale-up)
Metric Providers and Collectors 6 Compute Node WebServer Resource Metric Provider Metric Collector Metrics for a component may be provided by different sources such as the component itself or the environment or other specific monitoring endpoint For each metric type for a specific subject it must be possible to determine the source. This syntax should be agreeable among collectors and consumers Metric collectors will collect and store metrics. Metric consumers will interpret their meanings over time
Metric Summarization Computing the 1 hour min, max, and average from 1 min samples – Simple, good for graphing Computing the X quantile over a moving window – Good for SLAs – Generalize as filters – Not always simple SQL queries 7