Design and Implementation of a ServiceMonitoring Console within a Service Oriented

Architecture Framework

Arvind Krishnaa .J31508104017

Guided By

Dr. Chitra BabuHOD/CSE

SSN College of Engineering

Second Review - 30th March, 2012

Turmeric Runtime Platform

1 Client Runtime - Client application code written by theconsumers of the service. Service InvocationFramework(SIF)

2 Server Runtime - Deployment platform for developers topublish web services. Service Provider Framework (SPF)

3 CodeGen - Generate instrumentation code for deployingservices onto Turmeric.

Turmeric Runtime Platform

1 Client Runtime - Client application code written by theconsumers of the service. Service InvocationFramework(SIF)

2 Server Runtime - Deployment platform for developers topublish web services. Service Provider Framework (SPF)

3 CodeGen - Generate instrumentation code for deployingservices onto Turmeric.

Turmeric Runtime Platform

1 Client Runtime - Client application code written by theconsumers of the service. Service InvocationFramework(SIF)

2 Server Runtime - Deployment platform for developers topublish web services. Service Provider Framework (SPF)

3 CodeGen - Generate instrumentation code for deployingservices onto Turmeric.

Central Application Logging Framework

I Centralized collection of application server

logs

I Base for collecting data for the

monitoring consoleI Ability to generate custom reports from

this dataI TMC is a specific instance of a report

created using CAL

Central Application Logging Framework

I Centralized collection of application server

logsI Base for collecting data for the

monitoring console

I Ability to generate custom reports from

this dataI TMC is a specific instance of a report

created using CAL

Central Application Logging Framework

I Centralized collection of application server

logsI Base for collecting data for the

monitoring consoleI Ability to generate custom reports from

this data

I TMC is a specific instance of a report

created using CAL

Central Application Logging Framework

I Centralized collection of application server

logsI Base for collecting data for the

monitoring consoleI Ability to generate custom reports from

this dataI TMC is a specific instance of a report

created using CAL

Architecture of the Monitoring Console

1 Can be abstracted to two frameworks running in parallel -metrics logging framework and metrics handler framework

2 Both frameworks are web services deployed on an applicationserver

3 SOA Query Metrics Service (sqms) - Logging logging handlerframework

4 Monitoring Console (console) - Metrics handler framework

Architecture of the Monitoring Console

1 Can be abstracted to two frameworks running in parallel -metrics logging framework and metrics handler framework

2 Both frameworks are web services deployed on an applicationserver

3 SOA Query Metrics Service (sqms) - Logging logging handlerframework

4 Monitoring Console (console) - Metrics handler framework

Architecture of the Monitoring Console

1 Can be abstracted to two frameworks running in parallel -metrics logging framework and metrics handler framework

2 Both frameworks are web services deployed on an applicationserver

3 SOA Query Metrics Service (sqms) - Logging logging handlerframework

4 Monitoring Console (console) - Metrics handler framework

Architecture of the Monitoring Console

1 Can be abstracted to two frameworks running in parallel -metrics logging framework and metrics handler framework

2 Both frameworks are web services deployed on an applicationserver

3 SOA Query Metrics Service (sqms) - Logging logging handlerframework

4 Monitoring Console (console) - Metrics handler framework

SOA Query Metrics Service (SQMS)

Figure 1: Architecture of SQMS

Working of SQMS

1 SPFServlet is the main servlet which handles the requests tothe Turmeric runtime.

2 Initializes the CAL logger for logging metrics published byTurmeric services.

3 Metric data logged in a format called heartbeats.

4 Log message casted into a JMX MBean like object.

5 The MBean object is dispatched to the JMX servlet andpublished to a controller interface (Agent Service)

Metrics Storage Provider

I Java interface for defining the underlying storage mechanism

I Provides the general contract for defining the queries to storemetrics into the persistence mechanism

I Can be extended to provide custom implementations, forvarious Hibernate- compliant databases.

I Currently two implementations are provided - DAO(based ona MySql storage) and Cassandra (partially implemented)

Metrics Storage Provider

I Java interface for defining the underlying storage mechanism

I Provides the general contract for defining the queries to storemetrics into the persistence mechanism

I Can be extended to provide custom implementations, forvarious Hibernate- compliant databases.

I Currently two implementations are provided - DAO(based ona MySql storage) and Cassandra (partially implemented)

Metrics Storage Provider

I Java interface for defining the underlying storage mechanism

I Provides the general contract for defining the queries to storemetrics into the persistence mechanism

I Can be extended to provide custom implementations, forvarious Hibernate- compliant databases.

I Currently two implementations are provided - DAO(based ona MySql storage) and Cassandra (partially implemented)

Metrics Storage Provider

I Java interface for defining the underlying storage mechanism

I Provides the general contract for defining the queries to storemetrics into the persistence mechanism

I Can be extended to provide custom implementations, forvarious Hibernate- compliant databases.

I Currently two implementations are provided - DAO(based ona MySql storage) and Cassandra (partially implemented)

Metrics Logging

1 saveMetricValue(): It receives the timestamp, metric name,and a key-value pair to store the metric value, and converts itto row oriented format for MySQL storage (or name-value pairfor Cassandra)

2 saveMetricSnapshot(): Encapsulates the above receivedmetrics objects into a MBean instance and sends it to theJMX server for publication.

Logging helper utilities

1 Snapshot File Logger: Logs the aggregated metrics into a.log file

2 Differential Snapshot View Logger: Calculating thepercentage changes between the metrics collected on twodifferent days.

3 Monitoring System: Schedules the metrics logging processto be performed at regular intervals. Presently it is set at 60seconds.

Logging Handlers

1 Metrics Storage Provider InterfaceI Defines a framework which runs two

MetricsSnapshotSchedulers in separate background threads,one for the client-side metrics and the other for the server-sidemetrics

I Calls the saveMetricsSnapshot() method to store the metricdata.

2 DAO Metrics Provider : The provider implementation forMySQL persistence mechanism

3 Cassandra Storage Provider: Implementation for Cassandrastorage.

Any custom persistence mechanism can also be integrated.

Monitoring Console Service (TMC)

Figure 2: Architecture of Monitoring Dashboard

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Implementation of TMC service

I Responsible for constructing user interface of monitoringdashboard

I Retrieves the encapsulated data in the form of a MetricsDatainstance

I This object is serialized into JSON format and sent to theGoogle Web Toolkit’s charting API

I GWT API constructs the trends chart based on the JSON data

I A REST URI is created for every JSON object, and a link iscreated in the dashboard.

I The metrics detail can be exported into a CSV file as well.

Offline Aggregator - A Partial Implementation

I Objective of collecting the distributed metrics across cluster ofnodes, by utilizing Cassandra storage.

I Only the storage into Cassandra keyspace has beenimplemented

I Hooks are provided to read data across distributed nodes, tomake this feature full-fledged.

I Three main classes for implementing offline-aggregation

1 Readers2 Writers3 Erasers

Overview of Readers, Writers and Erasers

I Readers: Read the data from the offline cluster, de-serializethe MetricsData objects and display it in the dashboard.Different reader classes are available to customize metricsreading, in the future. (Classes need to be extended withcustom implementation)

I Writers: Write data into the offline cluster, by serializing themetrics into MetricsData objects. Different writer base classesavailable for extending with custom implementations.

I Erasers: Erase the data from the offline cluster.

Overview of Readers, Writers and Erasers

I Readers: Read the data from the offline cluster, de-serializethe MetricsData objects and display it in the dashboard.Different reader classes are available to customize metricsreading, in the future. (Classes need to be extended withcustom implementation)

I Writers: Write data into the offline cluster, by serializing themetrics into MetricsData objects. Different writer base classesavailable for extending with custom implementations.

I Erasers: Erase the data from the offline cluster.

Overview of Readers, Writers and Erasers

I Readers: Read the data from the offline cluster, de-serializethe MetricsData objects and display it in the dashboard.Different reader classes are available to customize metricsreading, in the future. (Classes need to be extended withcustom implementation)

I Writers: Write data into the offline cluster, by serializing themetrics into MetricsData objects. Different writer base classesavailable for extending with custom implementations.

I Erasers: Erase the data from the offline cluster.

Overview of Readers, Writers and Erasers

Figure 3: Overview of Reader, Writers and Erasers

Partial Demo

1 Nuts and bolts of Turmeric SOA services

2 Sample REST URLs for metrics

3 Walkthrough of database schema and significantimplementation classes

4 Overview of data aggregator tool

5 Tour of the user interface

Screenshots - SMC Dashboard for an eBay service

Figure 4: ShortURI Service

Screenshots - Turmeric Top volume graph

Figure 5: Example Echo Service

Screenshots - Turmeric Consumer trends

Figure 6: Example Echo Service

Data Aggregator tool

Figure 7: Ad hoc querying

Data Aggregator tool – Contd.

Figure 8: Ad hoc querying

Implementation Schedule

Figure 9: Project Roadmap

References

[1]Jeffrey Dean, Sanjay Ghemawat, MapReduce: Simplified DataProcessing on Large Clusters, In Sixth Symposium on OperatingSystem Design and Implementation(OSDI’04), San Francisco, CA,December, 2004

[2] Eben Hewitt, Cassandra: The Definitive Guide, O’ReillyPublications, November 2010.

[3] eBay Open Source Project, Turmeric SOA platform,http:

//www.ebayopensource.org/index.php/Turmeric/HomePage

References

[4] eBay Open Source Project, Documentation of Turmeric SOAplatform,https://www.ebayopensource.org/wiki/display/

TURMERICDOC110GA/Turmeric+Documentation+Overview

[5] eBay Open Source Project, Turmeric Source Code,http://www.github.com/ebayopensource

[6] Internal eBay documentation

[7] Google Web Toolkit,http://code.google.com/webtoolkit

[8] Apache Cassandra,http://cassandra.apache.org/