A while ago I created a first post about the Oracle Management Cloud ( #OMC for short 😎 ). In this post I will give you a first glance of a demo environment of the Oracle Management Cloud offering called “Application Performance Monitoring“. Because my company eProseed is an Oracle Platinum partner, I had the opportunity to ask for a trial on a demonstration environment, but as is, therefore this is a demo overview and not (yet) of a trial account / own test environment (but hopefully near to the real thing).
Also be aware that I had only 4 hours to play with this demo environment and although I tried to find every inch of info that was hidden under buttons, links, etc., it might be that I missed some pieces.
This demo environment is prepped by Oracle regarding, among others, an issue with a demo application called “Rideshare” (Uber look-a-like kind of possible application). Something went wrong in this environment and can be deducted as such via the Application Performance Monitoring environment. This post has a lot of pictures. Without telling you the clue, lets see if you can find what went broke and/or where it might guide you to look further, in more detail, at a node, programming code, or other issue.
🙂
As mentioned before in the general overview post about Oracle Management Cloud and here as a reference:
Oracle Application Performance Monitoring Service provides end-user and application performance monitoring across a wide array of technologies with minimal up-front setup.
Application Performance Monitoring is the first item that you see in this Oracle Management Cloud environment and the most “colorful” one regarding its out of the box click and go overview dashboard. A bit arbitrary therefore, this post about “APM”.
As mentioned in the Application Permance Monitoring documentation, here you can:
With Application Performance Monitoring, you can:
- Rapidly isolate application performance issues
- Drill down to related logs in context of a problem and find its root cause
- Gain end-to-end visibility into the performance of your application across all tiers
- Monitor end-user experience
At current there are five sections where, I think, although not clear to me, “Dashboards” and “Data Explorers” seem to be general sections in the OMC service offering. Application Performance Monitoring, Log Analytics and IT Analytics have license price tags as you can see on the Oracle Management Cloud main page.
Overview APM
If you click the “Application Performance Monitoring” square, you will arrive on the main APM dashboard. I am not sure if this is a “out-of-the-box” dashboard or just a demo example from Oracle and/or if you can create your own in the real cloud environment. But the dashboard presented showed a geography overview, server requests by appserver and 3 sections mentioning: the status of pages, server requests, and application servers.
All images are clickable, so you can zoom in to have a better look.
A lot of URL’s buttons, or in the case of a map, continents are clickable to be able to zoom in or forward you to an other page with more detailed info. In the case of a dashboard that you created by yourself, you can alter these different “regions” called widgets by, for example, alter the tabular format into a pie chart or add/remove information as you see fit.
For example if you would click on the appserver name in the appserver widget, you will be forwarded to the appserver detail page. Here you can see information about memory, garbage collection, cpu, response time etc. Also here you can zoom a bit further on details when you click URL’s, links, buttons, etc.
Just like the main “home” page, you can alter the time frame and if I remember correctly also refresh the page automatically in different time refresh times.
If you keep on this page, you will see that you can change via the menu (the “bar button” on the left upper corner) to different pages
- Home
- Page list
- Server Request list
- AppServer list
- Alerts
See below for the info you can discover here and the look-and-feel of the pages.
Page List
Server Request List page
The AppServer List page
Alerts page and Alert rules page
Server Requests
If you click on one of the links in the “Service Request” region/widget, you will, for example if you would click in the picture below “order.jsp“, detailed server request info on the order.jsp Java server page.
The following is the first page you would see for the order.jsp Java Server page.
You will get an overview about
- request response time
- tier average response
- calls and errors
- appserver status overview
also in the middle section a very cool, very useful “diagram” overview. Later more about the diagram features and why its very handy.
In the bottom section a “call from” / “call to” status overview with, where “it resides”, “self time”, “avg. response time”, “total calls and error” status information. So from an application status overview, this pages shows a lot of information.
But then the “diagram”-picture. Which isn’t a picture. You can actually click on, or hover over, every shown node in the diagram. When you do this, you will get information, via de “tooltip” section, information about the process / node in the diagram. Via this way you are able, via clicking on nodes / follow the edges, to get additional information and see its dependencies. In this case, the dependencies for the “/RideShare/order.jsp” Java Server page app.
Okay, before we dive deeper in the “coolness” of the diagram feature, wait a little bit, there is more 8-), lets zoom out a bit back to the main page.
Is there a problem?
So is there a problem with the demo RideShare application?
The RideShare checkout.jsp average response time is increasing as can be seen in the server request for the appserver region. Also the peak heap usage is increasing over time.
If we filter on “Error%” in the “Pages” and “Server Request” regions, we see that 40.49% result in errors.
Checkout – AppServer?
Something seems to be off on the AppServer servicing the “/RideShare/checkout” application. So zooming in on the appserver via “metrics” it shows…
And the “Service Request” menu tab shows more info on the “/RideShare/checkout” section. Especially the amount of errors is significantly different than on the other sections like “/RideShare/order.jsp”.
Checkout – Server Requests?
So can we get more info on “/RideShare/checkout”? Lets get back to the “diagram” page.
Because the checkout appserver bit ceased to exists (see the AppServer Heap/CPU/Load section), the depending “RestaurantService.placeOrder”, “OrderService.submit” and “OrderService.submitWithId” are producing a lot of errors and high average response times.
On the right side of the diagram you can alter the node size and arrow width. This item is very informative, for example, if you now alter the diagram on “Errors” for node size and “Error%” for node width, the diagram will almost guide you to the problem.
You might want to see the amount of calls (node size setting) to the different nodes related to the errors recorded (arrow width setting).
You might want to see the depending nodes of RestaurantServer.placeOrder and its details. You click on the node for the RestaurantServer.placeOrder and you get…
You might want to see what the “end” section in the line is… (apparently an external tier related node)
The additional fun bit is that if you click on one of those nodes, you also can checkout the related information for that particular node. For example, below a database tab/menu related screenshot of a part of the order.jsp process mentioned/shown earlier.
Server Request – Menu
So what is under those menus?
The following shows screen shots of the overall checkout process (so not one particular node). As mentioned above, if you click on a particular node, then the menu related info will show only the specific information for that node.
Lets see the info shown under the following menu items for the /RideShare/checkout process page…
- diagram
- metrics
- links
- database
- instances
The Diagram menu page
The Metrics menu page
The Links menu page
The Callers menu page
The Database menu page
The Instances menu page
In short…
I am not a Java guy, I don’t know the RideShare application and its technical architecture, I even don’t know the topology it is deployed on…but…with the Application Performance Monitor at hand and being a bit tech savvy, I can pinpoint the problem and address it to someone in the organization who should be able to fix it (in this case a Java developer responsible for the “checkout” part and/or Application Server admin).
The Application Performance Monitor being topology aware, with all the useful filter options (especially the diagram option), can visualize the, in this case errors clearly and its origins. Also the demo showed that one of the database (/connections) doesn’t reflect a normal SQL load. Being able to see the whole architecture in context, from page request to database and back to the client, is very useful. If your the owner of the application and know what it does, what it uses, how its normal functionality should be, then Application Performance Monitor makes your (supporting) life a whole lot easier…and time for finding and fixing the problem, at least in the finding bit of it, a whole amount faster.
Be aware, I have only shown you what I could find, have seen, while trying out the demo environment of the Application Performance Monitoring service offering, in what maybe has been a half hour, a hour, playing with it.
Despite this, I hope you have found the post interesting and will have a look at Application Performance Monitoring / Oracle Management Cloud when it comes available, for instance, via a 30 day trial opportunity.
HTH/M
