Collaboration with inspectIT RESTful services - spread your performance data
Last month we released the brand new inspectIT version 1.6.9 with a lot of new features, for example the new configuration interface and a JMX extension as well.
Next to the new features we also extended the inspectIT RESTful API. We decided to support the API First approach and develop an API to request data via HTTP protocol. With the API First approach it’s easy to access and integrate performance data into your existing monitoring system like Icinga 2.
Before the inspectIT 1.6.9 release we already had a REST API for the StorageService. With this service it’s possible to start/stop a recording and also to create, delete and get a storage with all the instrumentation data inside. For further information about the inspectIT storage you can read the following wiki page: “save to storage“
How to access the data
However, lets talk about the new RESTful services, the platform and the invocation service.
All requests to a RESTful service returns the results in the JSON format, so it’s easy to read and you are able to parse the response very easily. The services are bounded to the IP of the CMR and port that is used for HTTP communication (defaults is 8182).
For example: http://localhost:8182
Platform services
What are the benefits of platform services? Overall you can retrieve information about the platform, also called agent. It’s possible to get information of all existing agents of the Central Repository Measurement (CMR), detailed information about the status of one agent are also available.
Furthermore you can retrieve a list of instrumented methods for an agent and a list of used sensors as well.
Platform overview
If you request http://localhost:8182/rest/data/platform/all you will get the following JSON response:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
[ { "id": 5, "timeStamp": 1461333224740, "definedIPs": [ "fe80:0:0:0:bc8a:e7ff:fbae:b13%awdl0", "192.168.99.1", "fe80:0:0:0:a65e:60ee:fbb5:b5db%en0", "192.168.1.140", "fe80:0:0:0:0:0:0:1%lo0", "0:0:0:0:0:0:0:1", "127.0.0.1" ], "agentName": "Agent1", "version": "1.6.9" }, { "id": 6, "timeStamp": 1464360543860, "definedIPs": [ "fe80:0:0:0:b0bd:96ff:ef70:7ca0%awdl0", "2003:13:ab7b:9fad:d0e1:e7c3:96f6:1b4a", "2003:13:ab7b:9fad:a65e:55ff:fea5:b8db", "fe80:0:0:0:a65e:60ff:fee5:b8db%en0", "192.168.2.104", "fe80:0:0:0:0:0:0:1%lo0", "0:0:0:0:0:0:0:1", "127.0.0.1" ], "agentName": "Agent2", "version": "1.6.9" } ] |
Platform details
To get agent information in detail you can specify a platform id: http://localhost:8182/rest/data/platform/status?platformId=5
1 2 3 4 5 6 |
{ "agentConnection": "CONNECTED", "lastKeepAliveTimestamp": 1468053577757, "connectionTimestamp": 1468053524550, "millisSinceLastData": 4100 } |
Invocation services
As far as an agent is connected to the CMR and you did some requests to your application you can request the invocation data via the RESTful invocation service as follows:
http://localhost:8182/rest/data/invocations/overview
Invocation overview
With this request you get an overview off all invocation sequences which are requested.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
[ { "id": 4611686018427387927, "platformIdent": 5, "sensorTypeIdent": 30361, "timeStamp": 1468348002604, "methodIdent": 30352, "timerData": { "@class": ".TimerData", "id": 4611686018427387942, "platformIdent": 5, "sensorTypeIdent": 30365, "timeStamp": 1468348002605, "methodIdent": 30352, "min": 0.7361769676208496, "max": 0.7361769676208496, "count": 1, "duration": 0.7361769676208496, "cpuMin": 0.698, "cpuMax": 0.698, "cpuDuration": 0.698, "exclusiveCount": 1, "exclusiveDuration": 0.22999894618988037, "exclusiveMax": 0.22999894618988037, "exclusiveMin": 0.22999894618988037 }, "duration": 0.7865550518035889, "childCount": 4 } ] |
Here you can find the most important information of the invocations, including information about child invocation (childCount) and timer data as well.
This overview can be very heavy if many invocations happened in the past, so you can enclose the request with different parameters. For example, it’s possible to specify a “platformId” or to narrow the request with a “fromDate” and “toDate” parameter. With the “latestReadId” parameter it only requests all the invocations with a higher id than the submitted one. Last but not least the “limit” parameter will literally limit the request to a desired amount of invocations; default is 100.
Invocation details
If this is not enough for you and you are going to need more information about one invocation you can request detail information of one invocation by calling http://localhost:8182/rest/data/invocations/details?id=4611686018427387927
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 |
{ "id": 4611686018427387927, "platformIdent": 5, "sensorTypeIdent": 30361, "timeStamp": 1468348002604, "methodIdent": 30352, "nestedSequences": [ { "id": 4611686018427387934, "platformIdent": 5, "sensorTypeIdent": 30361, "timeStamp": 1468348002604, "methodIdent": 30355, "nestedSequences": [ { "id": 4611686018427387935, "platformIdent": 5, "sensorTypeIdent": 30361, "timeStamp": 1468348002604, "methodIdent": 30370, "timerData": { "@class": ".TimerData", "id": 4611686018427387936, "platformIdent": 5, "sensorTypeIdent": 30365, "timeStamp": 1468348002604, "methodIdent": 30370, "min": 0.15588605403900146, "max": 0.15588605403900146, "count": 1, "duration": 0.15588605403900146, "cpuMin": 0.151, "cpuMax": 0.151, "cpuDuration": 0.151, "exclusiveCount": 1, "exclusiveDuration": 0.15588605403900146, "exclusiveMax": 0.15588605403900146, "exclusiveMin": 0.15588605403900146 }, "duration": 0.25355100631713867, "childCount": 0 } ], "timerData": { "@class": ".TimerData", "id": 4611686018427387941, "platformIdent": 5, "sensorTypeIdent": 30365, "timeStamp": 1468348002604, "methodIdent": 30355, "min": 0.5061780214309692, "max": 0.5061780214309692, "count": 1, "duration": 0.5061780214309692, "cpuMin": 0.482, "cpuMax": 0.482, "cpuDuration": 0.482, "exclusiveCount": 1, "exclusiveDuration": 0.2613779306411743, "exclusiveMax": 0.2613779306411743, "exclusiveMin": 0.2613779306411743 }, "duration": 0.553291916847229, "childCount": 3 } ], "timerData": { "@class": ".TimerData", "id": 4611686018427387942, "platformIdent": 5, "sensorTypeIdent": 30365, "timeStamp": 1468348002605, "methodIdent": 30352, "min": 0.7361769676208496, "max": 0.7361769676208496, "count": 1, "duration": 0.7361769676208496, "cpuMin": 0.698, "cpuMax": 0.698, "cpuDuration": 0.698, "exclusiveCount": 1, "exclusiveDuration": 0.22999894618988037, "exclusiveMax": 0.22999894618988037, "exclusiveMin": 0.22999894618988037 }, "duration": 0.7865550518035889, "childCount": 4 } |
It shows the same information as seen in the overview part including all nested invocations. Now you’ve got information about the root invocation including the nested invocations in a hierarchal structure.
It’s so easy…
…to work with the inspectIT RESTful API and the performance data are utilizable in your monitoring solution as well – What is a great benefit!
If you like what you read please go ahead and star us on github.com/inspectIT.
Thanks a lot and stay tuned.
Mario
Comment article
Recent posts






Comment
pulkit
It’s really good to use the restful service of inspectIT but as for now it allows only limited data to be fetched through HTTP but if we need to get more data we have to use the InspectIT UI for that.
I am hoping that you will add whole information to be fetched through restful services.
If you can provide me tentative month when this update could be leveraged that will be great.