RESTful GlassFish Monitoring
Monday, February 28, 2011 |In previous posts, I’ve shown various ways to manage a GlassFish 3.1 server via its REST interface. As nice as that is, we also support monitoring your server via REST as well. In this article, we’ll take a look at some of the things you can ask of your server.
If you’re familiar with the management interface, you should be immediately comfortable with the monitoring interface. To access it, you use http://localhost:4848/monitoring/domain. Just like the management interface, you can request HTML, XML, or JSON. The simplest way to change the return type is to append an extension of the desired type.
1
2
3
$ curl http://localhost:4848/monitoring/domain.html
$ curl http://localhost:4848/monitoring/domain.xml
$ curl http://localhost:4848/monitoring/domain.json
Similarly, you can use the Accept header as well:
1
2
3
$ curl -H "Accept: text/html" http://localhost:4848/monitoring/domain
$ curl -H "Accept: application/xml" http://localhost:4848/monitoring/domain
$ curl -H "Accept: application/json" http://localhost:4848/monitoring/domain
There’s a good chance that at this point, many of you are getting a response that looks like this (in JSON):
1
2
3
4
5
{
"message": "",
"command": "Monitoring Data",
"exit_code": "SUCCESS"
}
I’ll admit that’s not a very helpful message, but the issue here is that while monitoring is turned on by default, the monitoring levels are set to OFF by default. You can change that a few different ways. Perhaps the two easiest are via the command-line (you can use asadmin set, but we’ll not look at that here):
1
...
or via the Admin Console:
Select the modules you’re interested in (if you’re just experimenting, it might be best to select all of them), select the level you want (again, I’d suggest HIGH for now), then click save. Your monitoring requests will now give you the data you’re seeking.
Now that we know how to get the data, what kind of data can get? Fortunately, the system will help you with that:
1
2
3
4
5
6
7
8
9
10
$ curl -H "Accept: application/json" http://localhost:4848/monitoring/domain
{
"message": "",
"command": "Monitoring Data",
"exit_code": "SUCCESS",
"extraProperties": {
"entity": {},
"childResources": {"server": "http:\/\/localhost:4848\/monitoring\/domain\/server"}
}
}
If you just installed GlassFish 3.1, you’ll see the above. If, however, you have a more complex setup (cluster, standalone instances, etc.), you might see something like this (two clustered instances, one standalone instance, and the DAS):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ curl -H "Accept: application/json" http://localhost:4848/monitoring/domain
{
"message": "",
"command": "Monitoring Data",
"exit_code": "SUCCESS",
"extraProperties": {
"entity": {},
"childResources": {
"c1in1": "http:\/\/localhost:4848\/monitoring\/domain\/c1in1",
"c1in2": "http:\/\/localhost:4848\/monitoring\/domain\/c1in2",
"in1": "http:\/\/localhost:4848\/monitoring\/domain\/in1",
"server": "http:\/\/localhost:4848\/monitoring\/domain\/server"
}
}
}
If you do have extra instances like this, you will need to set the monitoring levels as desired in the appropriate configuration.
The server instance (also known as the DAS), has these child elements:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ curl -H "Accept: application/json" http://localhost:4848/monitoring/domain/server
{
"message": "",
"command": "Monitoring Data",
"exit_code": "SUCCESS",
"extraProperties": {
"entity": {
"starttime": "1298837779434",
"state": "1",
"uptime": "2639132"
},
"childResources": {
"applications": "http:\/\/localhost:4848\/monitoring\/domain\/server\/applications",
"deployment": "http:\/\/localhost:4848\/monitoring\/domain\/server\/deployment",
"http-service": "http:\/\/localhost:4848\/monitoring\/domain\/server\/http-service",
"jvm": "http:\/\/localhost:4848\/monitoring\/domain\/server\/jvm",
"network": "http:\/\/localhost:4848\/monitoring\/domain\/server\/network",
"resources": "http:\/\/localhost:4848\/monitoring\/domain\/server\/resources",
"security": "http:\/\/localhost:4848\/monitoring\/domain\/server\/security",
"transaction-service": "http:\/\/localhost:4848\/monitoring\/domain\/server\/transaction-service",
"web": "http:\/\/localhost:4848\/monitoring\/domain\/server\/web"
}
}
}
Note that we can see the server start time (displayed in Unix time. This server was started on Sun Feb 27 2011 14:16:19 GMT-0600 (CST)) and how long the server has been up (2639132 milliseconds, or about 44 minutes). Notice under childResources the various classes of additional information. The easiest way to examine those is to point your browser at http://localhost:4848/monitoring/domain/server. Go ahead and poke around. You can’t hurt anything. : )
While I won’t take the time to examine the tree exhaustively, for those that can’t examine a running GlassFish instance right now, let’s take a look at the information on memory the server gives us:
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
$ curl -H "Accept: application/json" http://localhost:4848/monitoring/domain/server/jvm/memory
{
"message": "",
"command": "Monitoring Data",
"exit_code": "SUCCESS",
"extraProperties": {
"entity": {
"committedheapsize-count": {
"count": 158642176,
"lastsampletime": 1298841382830,
"description": "Amount of memory in bytes that is committed for the Java virtual machine to use",
"unit": "bytes",
"name": "CommittedHeapSize",
"starttime": 1298839382803
},
"committednonheapsize-count": {
"count": 120938496,
"lastsampletime": 1298841382830,
"description": "Amount of memory in bytes that is committed for the Java virtual machine to use",
"unit": "bytes",
"name": "CommittedNonHeapSize",
"starttime": 1298839382803
},
"initheapsize-count": {
"count": 0,
"lastsampletime": 1298841382830,
"description": "Amount of memory in bytes that the Java virtual machine initially requests from the operating system for memory management",
"unit": "bytes",
"name": "InitialHeapSize",
"starttime": 1298839382803
},
"initnonheapsize-count": {
"count": 12750848,
"lastsampletime": 1298841382830,
"description": "Amount of memory in bytes that the Java virtual machine initially requests from the operating system for memory management",
"unit": "bytes",
"name": "InitialNonHeapSize",
"starttime": 1298839382803
},
"maxheapsize-count": {
"count": 518979584,
"lastsampletime": 1298841382830,
"description": "Maximum amount of memory in bytes that can be used for memory management",
"unit": "bytes",
"name": "MaxHeapSize",
"starttime": 1298839382803
},
"maxnonheapsize-count": {
"count": 234881024,
"lastsampletime": 1298841382830,
"description": "Maximum amount of memory in bytes that can be used for memory management",
"unit": "bytes",
"name": "MaxNonHeapSize",
"starttime": 1298839382803
},
"objectpendingfinalizationcount-count": {
"count": 0,
"lastsampletime": 1298841382830,
"description": "Approximate number of objects for which finalization is pending",
"unit": "count",
"name": "ObjectsPendingFinalization",
"starttime": 1298839382803
},
"usedheapsize-count": {
"count": 95092688,
"lastsampletime": 1298841382830,
"description": "Amount of used memory in bytes",
"unit": "bytes",
"name": "UsedHeapSize",
"starttime": 1298839382803
},
"usednonheapsize-count": {
"count": 77427208,
"lastsampletime": 1298841382830,
"description": "Amount of used memory in bytes",
"unit": "bytes",
"name": "UsedNonHeapSize",
"starttime": 1298839382803
}
},
"childResources": {}
}
}
In English, this shows us:
-
CommittedHeapSize - 158642176 bytes
-
CommittedNonHeapSize - 120938496 bytes
-
InitialHeapSize - 0 bytes
-
InitialNonHeapSize - 12750848 bytes
-
MaxHeapSize - 518979584 bytes
-
MaxNonHeapSize - 234881024 bytes
-
ObjectsPendingFinalization - 0
-
UsedHeapSize - 95092688 bytes
-
UsedNonHeapSize - 77427208 bytes
Similarly, from http://localhost:4848/monitoring/domain/server/jvm/runtime, we learn (large strings like InputArguments stripped for brevity’s sake):
-
ClassPath
-
InputArguments
-
LibraryPath
-
ManagementSpecVersion - 1.2
-
Name - 937@halpert
-
SpecName - Java Virtual Machine Specification
-
SpecVendor - Sun Microsystems Inc.
-
SpecVersion - 1.0
-
Uptime - 1298843595776
-
VmName - Java HotSpot™ Client VM
-
VMVendor - Apple Inc.
-
VmVersion - 17.1-b03-307
We’ve only scratched the surface of what the monitoring interface can provide developers and administrators, and since this is REST, you no longer need to write a Java client to get to the data, so point your browser at the monitoring interface and start digging.
My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997,
using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat
on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer,
Jakarta Faces, and Bean Validation. (Full resume 