Edit this image here.

The metrics service has a few different responsibilities:

1. The metrics service must accept metrics from the OpenHIM in particular format. These metrics will be reported for each transaction that the OpenHIM processes and will be sent directly to the metrics service. The OpenHIM must calculate the metrics for each transaction but it is left up to the metrics service to aggregate these into particular intervals.
2. The metrics service must process the metrics it receives and store them in mongodb. It should aggregate the metrics based on a number of different intervals (ie. 1min, 5min, 15min, 1hour, 1day).
3. The metrics service must provide a mechanism to query for the metrics it has stored for a particular interval for graphing purposes.
4. The metrics service must provide a mechanism for the visualizer to poll for events that the metrics service has recieved.

OpenHIM to Metrics Service

The metrics service will expose a simple RESTful endpoint that accept metrics as JSON objects.

Method: POST

URL: http://<server>/metrics

Data:

[
	{
		"metricName": "aName",
		"type": "count|ave|min|max"
		"Value": 753
		"timestamp": "??"
	},
	{
		"metricName": "aName",
		"type": "count|ave|min|max"
		"Value": 753
		"timestamp": "??"
	},
	...
]

Or perhaps just:

 {
    "_id": "123",
    "status": "Processing|Failed|Completed",
    "clientID": "Musha_OpenMRS",
    "request": {
        "path": "/api/test",
        "headers": {
            "header1": "value1",
            "header2": "value2"
        },
        "querystring": "param1=value1&param2=value2",
        "body": "<HTTP body>",
        "method": "POST",
        "timestamp": "<ISO 8601>"
    },
    "response": {
        "status": 201,
        "body": "<HTTP body>",
        "headers": {
            "header1": "value1",
            "header2": "value2"
        },
        "timestamp": "<ISO 8601>"
    },
    "routes": [
        {
            "name": "<route name>"
            // Same structure as above
            "request": { ... },
            "response": { ... }
        }
    ]
    "orchestrations": [
        {
            "name": "<orchestration name>"
            // Same structure as above
            "request": { ... },
            "response": { ... }
        }
    ]
    "properties": { // optional meta data about a transaction
        "prop1": "value1",
        "prop2": "value2"
    }
}

Metrics Service to MongoDB

The metrics service will aggregate metrics into a number of predefined intervals. These are as follows:

• 1min
• 5min
• 15min
• 1hour
• 1day
• totals

Each of these will be a separate collection in mongodb. The user must be able to choose which intervals should be stored else the metrics service will default to storing against all of them. Each document in the collection holds a set of aggregated metrics for a timeperiod of length of the interval. The _id of the document is a tiemstamp that represents the start time of this particular interval document. When the metrics are received by the metrics service it find the document (or creates it if it doesn't exist) in each interval and updates the metric with the value recieved.

Sample interval documents:

{
	“_id”: “321646814”, // interval start time
	“completedTX”: 5,
	“aveTXTime”: 265
}

OpenHIM Console to Metrics service

The metrics service will provide a simple RESTful API to query for metrics. The OpenHIM Console will read from this.

Method: GET

URL: http://<server>/metrics?interval=1min&start_ts=...&end_ts=...

Data: and array of interval documents

Visualizer to Metrics Service

The metrics service will provide a simple RESTful endpoint for querying for the latest events:

Method: GET

URL: http://<server>/events?last_ts=...

Data:

[
	{ "ts": "20140502130000000", "comp": "ep-reg", "ev": "start" },
	{ "ts": "20140502130000100", "comp": "cr", "ev": "start" },
	{ "ts": "20140502130000300", "comp": "cr", "ev": "end", "status": "ok" },
	{ "ts": "20140502130000400", "comp": "dhis", "ev": "start" },
	{ "ts": "20140502130000600", "comp": "dhis", "ev": "end", "status": "ok" },
	{ "ts": "20140502130000700", "comp": "sub", "ev": "start" },
	{ "ts": "20140502130000900", "comp": "sub", "ev": "end", "status": "error" },
	{ "ts": "20140502130001000", "comp": "ep-reg", "ev": "end", "status": "error" }
]

Outstanding questions: How will the metrics service produce this? Should we rather provide this feed from the OpenHIM-core itself? Or should we try calculate this based on the tx response time metric? The OpenHIM and metrics service won't know about components. Should we use routes names and orchestrations names and map these to components on the visualizer side?