DripStat

The Smartest Java APM  DripStat Home

[dripstat-blog]

DripStat now the next gen Scala APM

With the release of Agent 7 today, we are now a full fledged Scala APM! We now support both Play and Spray frameworks with all the full feature set of DripStat.

Previously on DripStat: --------------------------------

Our previous release with limited Scala support had the following basic features working for Play and Spray Frameworks:

Show request as transactions to show correct response times and throughput.

Capture asynchronous activity, to show things like calls to databases, external services etc that happen asynchrnously

Starting today: --------------------

Today however, are bringing Play and Spray framework support to the highest level of functionality. So in addition to the above, you get:

Asynchronous Segments in Transaction Traces

All Transaction traces will now show times spent in various asynchronous calls. This is supported for both Scala and Java frameworks.

Exception tracking

Uncaught exceptions in Play and Spray frameworks are recorded. Http request that return with an error will be indicated so in dashboard.

Environment detection

The correct version and port of Play and Spray frameworks will be detected and shown in the Environment tabs.

Much Lower Memory Overhead

If you ran into memory overhead issues with the previous one, be sure to try this version. We have greatly reduced the overhead.

Next Steps -------------

Upgrade to Agent 7

To see what DripStat can do, check out the Live Demo.

[dripstat-blog]

Integrate DripStat with PagerDuty through StackStorm

StackStorm is like an If This Then That for your operating environment.

We are today announcing deep integration of DripStat with StackStorm so you can take advantage of the full breadth of integrations that StackStorm offers and use it with DripStat.

Read our blog post on the StackStorm blog that shows how you can get PagerDuty working with DripStat through StackStorm.

[dripstat-blog]

Monitor JVMs on Jelastic with DripStat

Jelastic is a PAAS provider for Java, which means if you have a Java app you can get it up and running with just a few clicks on Jelastic without having to worry about servers, scripts etc.

So, in the same spirit, we made enabling DripStat on Jelastic as simple as a few clicks. Yes, with just a few clicks you can have full enterprise grade monitoring on Jelastic.

See full details on the blog post at Jelastic: http://blog.jelastic.com/2015/06/03/enable-dripstat-monitor-java-apps/

[dripstat-blog]

Google Cloud Datastore monitoring

DripStat now allows you to monitor Google Cloud Datastore.

Version 6.1.25 of the DripStat agent will track timing of all calls to Google Datastore.

All view inside DripStat, including ‘Transactions’ and ‘Application Overview’ tab now show Google Cloud DataStore timing

[dripstat-blog]

Detailed MongoDB stats

We are now able to show detailed stats for MongoDB broken down by Operation and Collection name.

You can even see the various types of operations being performed, the response times and throughput of each.

The transactions tab will show MongoDB activity broken down by Operation and Collection name.

Next Steps

Upgrade to Agent 6.1.23 to see detailed Mongo stats in your app.

Check out our Live Demo to see this in action now.

[dripstat-blog]

Spray Framework monitoring with DripStat

We have released support for Spray Framework starting from DripStat Agent 6.1.15.

Monitoring Spray framework requires a little bit of extra work since the controller methods in Spray are inside a set of ‘Routes’ which are formed using Spray’s own DSL. Thus there is no real ‘method name‘ we can use to name your Transactions.

The recently released DripStat-API jar contains support for adding custom names to your transactions, which will need to be used here. Just add an extra line inside your routes to name the Transactions to your liking. Eg:

path("hello") { get { complete { DripStat.setCurrentTransactionName("hello") //code... "hi" } } }

The current implementation of Spray support has similar limitations as Play Framework support. We are working to get over these asap.

Related Links:

Spray Framework agent installation documentation

DripStat-API jar

Agent Changelog

[dripstat-blog]

Hardware monitoring across instances and Docker containers

We are releasing a new view today - Hardware.

The aim of this view is to allow you to:

Monitor usage of physical resources by your JVMs across the cluster

Notice how changes to your hardware (scaling up/down) affect your application performance

Allow optimization of hardware resources to best match your application’s requirements, so you are not over/under-spending on hardware

This is specially useful for people who use autoscaling or run inside containers like Docker to dynamically alter their physical resources on-demand.

You can see this view in your dashboard by going to Overview > Hardware.

Lets walk through each of the panels. We will use 2 JVMs A & B to show example data.

JVM Count

This shows you the number of JVMs active for this application

Core Count

This shows the total number of CPU Cores available to this application across JVMs.

Eg - A is deployed on a 4 core box, B on a 2 core box. This graph will show 4+2 = 6 cores available to your app.

Total CPU

Using this graph along with the ‘Core Count’ graph, you can optimize the number of CPU cores available to your application.

It shows the total CPU used across your JVMs. 

Eg - A is using 50% of total CPU and B is using 40%. This graph will show (50+40)/2 = 45% CPU usage.

Total Memory

This graph allows you to optimize the memory available to your applications and tune the heap to match your needs.

It shows the total RAM, Total Available Heap and Total Used Heap.

Eg, A has 4GB RAM with Max Heap of 3GB and using 2GB. B has 2GB RAM with Max Heap of 1GB and using 0.5GB. The graph will show: Total RAM = 4+2 = 6GB, Total Available Heap = 3+1 = 4GB, Total Used Heap = 2+0.5 = 2.5GB

Longest GC Pause

Shows the single longest GC Pause across your JVMs for a time period.

Eg, At time X, A has the longest GC pause of 10ms, and B of 50ms. This graph will show  50ms.

Total Thread Count

Shows the total thread count for your application across JVMs.

Eg, A has 100 threads, B has 200 threads. This graph will show 100 + 200 = 300 threads.

Next Steps --------------

Make sure you have atleast Agent 6.1.20 to see all the data in this view.

See this view now on our Live Demo.

[dripstat-blog]

ColdFusion monitoring on Railo

Are you running ColdFusion on Railo server? Now you can monitor it with DripStat, since Agent 6.1.17.

Calls to your .cfm files and Rest Services will show up as Transactions inside DripStat. Any calls made to a Database or an External Rest Service will show up too, along with all the rest of the goodness of DripStat’s features.

To see what DripStat can do, see Live Demo

[dripstat-blog]

Post Mortem of today’s downtime

Our data collection was down today for approx 3.5 hours from 5:20 AM PST to 9:00 AM PST.  The rest of the services were still up, so you could still see login and see all your historical data.

The root cause of this issue was due to Azure rebooting a lot of our instances without any notification whatsoever. This took a while to resolve since we had no idea for a while why any of our services was down. Azure status page indicated everything was up. It seems due to some bug in the Azure portal our support plan was shown as downgraded so were unable to get a response directly from the Azure team in time to help us solve this issue.

We have had tons of problems in the past with Azure. While most of our infrastructure has indeed moved off of Azure, some boxes had still remained. We are now in the process of completely moving off of Azure.

Uptime is highly valuable to us. We know our customers rely on us as system of record to monitor their boxes. Even a 3.5 hour downtime is a huge deal for us. We will continue doing our very best to ensure this never happens again.

[dripstat-blog]

Change Transaction names to your liking

DripStat automatically generates a name for your Transactions. Now you can change that name if you don’t like it.

The recent update (v 2.1.0) of DripStat-API contains the following method:

DripStat.setCurrentTransactionName(String txnName)

Call it anywhere inside your code with the name of the Transaction you would like to see.

Example

@RequestMapping(value = "/accountinfo", method = RequestMethod.GET) public AccountInfo accountinfo() { DripStat.setCurrentTransactionName("/accounts/info") //code... }

Before API usage:

After:

Related Links:

 DripStat API jar

[dripstat-blog]

DripStat monitors Scala and Play Framework

We have added support for Scala and Play Framework monitoring. 

Play controller methods will show up as Transactions inside DripStat now.

We took into account the highly asynchronous nature of Play applications. All your asynchronous activity will be captured. It will be shown under  ‘Async Segments’ for each transaction and in other places in the Dashboard UI.

This is our first release of official Play framework support so it does not support all the features that we support for Java Frameworks. We have created a list of features that remain to be implemented for Play. That said, you should see that list become empty in a matter of days.

Make sure to upgrade your agents to version 6.1.12 to get this feature.

Related Links:

Agent Changelog

Play implementation details

[dripstat-blog]

We are committed to Scala

Support for Scala and the Play and Spray framework is by far the most requested feature of DripStat.

We have promised support for this to our users in the past. So it is no suprise that we got a ton of angry mails after yesterday’s release contained even more Java async features and not Scala support. I guess its time to answer a few questions:

Why have you of late been focusing on Java Async support and not implementing Scala support?

Scala’s frameworks are completely asynchronous from top to bottom. We saw other vendors who added Scala support and it was terrible and useless cause the APM wasn’t designed to track asynchronous calls in the first place.

Seeing the growth of Scala and reactive programming we knew we had to bake it async support in our agent from the ground up. To do this, we decided the best way would be to work with stuff we already know, so we decided to make the implementation for Java’s asynchronous libraries first. This helped us learn about the various problems in supporting async and form the right set of abstractions in the agent, on our backend and in the UI to support it.

Why did yesterday’s release focus again on Java async and not Scala?

Our initial release of the agent only partially supported most of the async libraries in the Java world, but with yesterday’s release we have covered the ground for the most popular java async libs and made sure our agent is robust with async support.

When is Scala support coming?

We are entirely focused on Scala at the moment. As I write this blog post, we are working tirelessly only with Scala code to add support for Play and Spray frameworks. Our experience adding support for Async in java should help us achieve this very swiftly. 

Next week we should have some announcements that will make the Scala people happy!

[dripstat-blog]

Monitor Async calls in Java 8 and Spring MVC

Since the last post announcing Async framework support in DripStat, we have now added support for:

Java 8′s CompletableFuture

Spring MVC’s Async requests, including support for controller methods that return DeferredResult or ListenableFuture.

This means is you can have a method like this, and it will be fully recognized by Dripstat!

@RequestMapping(value = "/hello", method = RequestMethod.GET) public ListenableFuture> hello() { return FutureConverter.toListenableFuture( CompletableFuture.supplyAsync( () -> restTemplate.getForEntity ("https://google.com", String.class))); }

Upgrade to Agent 6.1.11 to get the above functionality.

Related:

Agent Changelog

[dripstat-blog]

Deprecating Old Agent v4

In the past, we had already deprecated old agents upto and including version 3.x.

Today, we are announcing deprecation of agent v4.x. While there are very few people using this older version anyway, if you are one of them, please switch to the latest version. We will be dropping support for 4.x in 24 hours.

Current agent version is 6.1.8. If you are not on this version, we highly recommend you to upgrade to it to get all the latest goodies.

[dripstat-blog]

JVM Details in Transaction Traces

Its the 4th consecutive day of DripStat updates!

Now you can see the details of exactly what was happening in your JVM when a Transaction Trace was collected. This is very useful to check if the slowdown occurred due to something like a GC Pause, High CPU usage, etc.

Select a Trace from the Transactions tab and scroll down the Trace Summary to see the JVM activity during the trace period.

The charts show 3 timestamps:

The middle timestamp is the one when the trace was collected.

There is one minute before and after shown to give you a good idea what was going on in your JVM during the trace.

Check out the Live Demo area to see this in action.

[dripstat-blog]

Per Transaction Cluster View

Its another day and we have another set of amazing features!

Cluster View per Transaction

There is now a ‘JVMs’ tab when viewing the details of a Transaction. It shows the per JVM details of how that transaction is executing across every JVM.

So you can see the Response Time, Throughput and Error Rate per JVM.

Sort by Error Rate

You can now sort the Transactions list by Error Rate

This is the 3rd consecutive day of updates today! We will have more stuff for you next week. Happy Friday!

[dripstat-blog]

Monitor GC Pauses with DripStat

Java Garbage Collector pauses have always been a big issue. Dealing with them usually requires starting your JVM with a whole bunch of flags to output the info to a log file, and then later on analyzing that (huge) log file manually.

With the new GC Pause monitoring feature in DripStat Agent 6.1.8, all that changes now!

How it works

In the JVMs tab, you will now see a GC Pauses chart.

Total Time Spent 

Shows the total time spent in GC during this time period.

Max GC Pause

The max time spent in a single GC Pause during this time period.

Count

The total number of GC Pauses during this time period.

Note that the Total Time Spent and Max GC Pause are on a single ‘stacked column’ chart.

Example

Lets say you have:

Total Time Spent = 900ms Max GC Pause = 600ms Count = 20

What this tells you is that:

Out of the 900ms that were spent in GC, 600ms of those were spent in a single GC Pause. The remaining 300ms were spent in 19 ( = 20 - 1) GC Pauses. So you had 1 big pause, followed by lots of smaller pauses.

This is extremely useful information if you are trying to optimize your GC for throughput or latency.

Next Steps

Update your agent to 6.1.8 to see this info. This feature will only work on JVMs version 7 or higher.

Check out the Live Demo to see the GC Pause graph in action!