Note: Only for Edge Private Cloud 4.15.07 and earlier. For Edge 4.16.01 and later, use the Monitoring Dashboard.
On Routers and Message Processors in a Private Cloud installation, Edge gathers run-time metrics. Metrics include details about:
- All outbound traffic to a given host IP address
- All inbound traffic for a given organization
- Heartbeats between Router and Message Processor
- Many others
These metrics are all collected "in memory" until the server restarts.
Edge gathers run-time metrics in three groups:
- cumulative
- current
- previous
Initially, Edge starts with all metrics in all groups set to zero. The cumulative metrics contain the values collected from the start of the server.
The current group contains metrics collected in the last minute. Every minute, the metrics in current are copied to previous, and the current metrics reset to 0.
You can configure metrics collection by using the following APIs:
| API | Use |
| POST /v1/server/metrics/disable | Disable the metrics collection. |
| POST /v1/server/metrics/enable | Enable the metrics collection. |
| POST /v1/server/metrics/reset | Reset the collected metrics. |
| GET /v1/server/metrics/interval | Get the interval, in milliseconds, at which the metrics snapshots are collected. |
| POST /v1/server/metrics/interval/{millis} | Set the interval, in milliseconds, at which the metrics snapshots are collected. The default value is 60,000, corresponding to 60 seconds. |
The base URL of these APIs depends on if you are calling them on the Router or Message Processor. For the Router, you call them on port 8081 of the Router's host machine. For example, if you are calling from the machine hosting the Router:
curl -u $ADMINEMAIL:$PW -X GET http://localhost:8081/v1/server/metrics/inbound/traffic
Or, if you know the IP address of the machine hosting the Router:
curl -u $ADMINEMAIL:$PW -X GET http://192.168.52.101:8081/v1/server/metrics/inbound/traffic
For the Message Processor, replace port 8081 with port 8082 in the request:
curl -u $ADMINEMAIL:$PW -X GET http://localhost:8082/v1/server/metrics/inbound/traffic
The following table lists the API calls that you use to view the recorded metrics. The request URL is based on which metrics group you want to access: cumulative, previous, and current.
For cumulative, use the URL as shown in the table. For example:
curl -u $ADMINEMAIL:$PW -X GET http://localhost:8081/v1/server/metrics/inbound/traffic
For the current and previous metrics groups, append "current" and "previous" to the paths after /v1/server/metrics:
curl -u $ADMINEMAIL:$PW -X GET http://localhost:8081/v1/server/metrics/current/inbound/traffic curl -u $ADMINEMAIL:$PW -X GET http://localhost:8081/v1/server/metrics/previous/inbound/traffic
| API | Use |
| /v1/server/metrics | Get complete metrics object. |
| /v1/server/metrics/inbound/traffic | Get details about all inbound traffic. |
| /v1/server/metrics/inbound/traffic/unclassified | Get details about all inbound traffic which could not be classified (only for Routers). |
| /v1/server/metrics/inbound/traffic/organizations/{org} | Get details about all inbound traffic for a given organization. |
| /v1/server/metrics/inbound/traffic/organizations/{org}/ environments/{env} | Get details about all inbound traffic for a given organization and environment. |
| /v1/server/metrics/inbound/traffic/organizations/{org}/ environments/{env}/apiproxies/{apiproxy} | Get details about all inbound traffic for a given organization, environment, and apiproxy. |
| /v1/server/metrics/inbound/traffic/organizations/{org}/ environments/{env}/apiproxies/{apiproxy}/ revisions/{revision} | Get details about all inbound traffic for a given organization, environment, apiproxy, and revision. |
| /v1/server/metrics/outbound/traffic | Get details about all outbound traffic. |
| /v1/server/metrics/outbound/traffic/hosts/{host} | Get details about all outbound traffic to a given host name. |
| /v1/server/metrics/outbound/traffic/ hosts/{host}/ports/{port} | Get details about all outbound traffic to a given host name and port. |
| /v1/server/metrics/outbound/traffic/ addresses/{address} | Get details about all outbound traffic to a given host IP address. |
| /v1/server/metrics/outbound/traffic/ addresses/{address}/ports/{port} | Get details about all outbound traffic to a given host IP address and port. |
| /v1/server/metrics/inbound/connections | Get details about all inbound connections. |
| /v1/server/metrics/inbound/connections/ hosts/{host} | Get details about all inbound connections to a given host name. |
| /v1/server/metrics/inbound/connections/ hosts/{host}/ports/{port} | Get details about all inbound connections to a given host name and port. |
| /v1/server/metrics/inbound/connections/ addresses/{address} | Get details about all inbound connections to a given host IP address. |
| /v1/server/metrics/inbound/connections/ addresses/{address}/ports/{port} | Get details about all inbound connections to a given host IP address and port. |
| /v1/server/metrics/outbound/connections | Get details about all outbound connections. |
| /v1/server/metrics/outbound/connections/ hosts/{host} | Get details about all outbound connections to a given host name. |
| /v1/server/metrics/outbound/connections/ hosts/{host}/ports/{port} | Get details about all outbound connections to a given host name and port. |
| /v1/server/metrics/outbound/connections/ addresses/{address} | Get details about all outbound connections to a given host IP address. |
| /v1/server/metrics/outbound/connections/ addresses/{address}/ports/{port} | Get details about all outbound connections to a given host IP address and port. |
| /v1/server/metrics/latencies | Get details about all the latency counters (time spent in executing policies and internal executions). |
| /v1/server/metrics/latencies/organizations/{org} | Get details about all the latency counters by org. |
| /v1/server/metrics/latencies/organizations/{org}/ environments/{env} | Get details about all the latency counters by org and environment. |
| /v1/server/metrics/latencies/organizations/{org}/ environments/{env}/apiproxies/{apiproxy} | Get details about all latency counters by org , env, and API proxy. |
| /v1/server/metrics/latencies/organizations/{org}/ environments/{env}/apiproxies/{apiproxy}/ revisions/{revision} | Get details about all latency counters by org, env, API proxy, and revision. |
| /v1/server/metrics/latencies/organizations/{org}/ environments/{env}/apiproxies/{apiproxy}/ revisions/{revision}/policytypes/{type} | Get details about all the latency counters by org, env, API proxy, revision, and policy type. |
| /v1/server/metrics/heartbeats | Get details about heartbeats between Router and Message Processor. |
| /v1/server/metrics/heartbeats/hosts/{host} | Get details about heartbeats to a Message Processor host. |
| /v1/server/metrics/heartbeats/hosts/{host}/ports/{port} | Get details about heartbeats to a Message Processor host and port. |
Hello,
As mentioned for inbound traffic, '/current' does not give data only for current minute, also it doesnt resets to zero at the start of every minute.
Also what happens if the proxy is deleted?
@sgilson This is wonderful info.
I using this in-memory api 'http://<router_ip>:8081/v1/server/metrics/inbound/traffic/' to fetch all inbound traffic. Below are my queries with respect to this:
1) Which one to use, router or message processor? and why?
2) How much will it take to collect the metric after an api proxy has been hit?
3) What will happen if the proxy is deleted?
4) The '/current' is supposed to fetch the data for the current minute and reset to '0' at the start of every minute? But i don't see that happening.
@Sadiq Hussain FYI.
@sgilson One more thing, if i have 2 routers, do i need to make this call on both of them inorder to get the complete inbound traffic?
@sgilson @Akash Prabhashankar
I was able to find the answers for the first two questions, i need the last 2 questions to be answered. Thank you.
Adding @Sanjoy Bose @archendra to see if they know this information.
@Sadiq Hussain For question 3:
All these metrics are all collected "in memory". Which means there is a cache from which these data are read from. The data is overwritten when this memory fills up. Ideally we assume that this cache holds data until the server restarts. But practically it would depend on the amount of data cached (depends on the traffic, etc).
Hence, when an API proxy is deleted, the API calls may still return data given that it is still available in the cache memory.
Hope this explanation helps.
Contributors
13 People are following this .
