How AppDynamics Assures Guidewire Software

Guidewire Software delivers the industry platform that property and casualty (P&C) insurers rely upon to adapt and succeed in a time of accelerating change. The company provides the software, services and partner ecosystem to enable its customers to run, differentiate and grow their business. Recognized as a market leader by Gartner, this rapidly growing software company serves about half of tier-one insurance companies, trades publicly on the NYSE, and has more than 350 customers across the globe. Consisting of several products for managing the lifecycle of insurance, Guidewire offers a strategic platform for insurers’ digital transformations, helping its clients meet their customer demands and discover new revenue channels.

Guidewire’s partnership with AppDynamics was created in a most unusual way. In 2013, a Guidewire customer approached AppDynamics and asked us to measure the availability and performance of a new system. Since this solution interacted with many non-Guidewire systems, visibility was critical—from browser to backend—for rapidly identifying, isolating and remediating issues.

Enter AppDynamics

AppDynamics’ sales engineering team was brought in and quickly determined a way to instrument Guidewire software using our Java agent. But this was no easy feat. Guidewire had created a language called GOSU that runs inside the JVM. This custom language introduced challenges by reducing visibility in some areas. Nonetheless, AppDynamics’ APM solution was able to provide great operational benefits, particularly in end-to-end monitoring.

After a couple of successful implementations, the number of Guidewire customers using AppDynamics increased dramatically around the world. To help these customers, we needed greater visibility inside GOSU to understand the JVM better. Two years ago, we approached Guidewire and began working with its technical, product and development teams. The results have been excellent. We’ve made many improvements to our Guidewire integration since then—hard work that has driven adoption of AppDynamics across Guidewire’s install base. Today AppD and Guidewire have more than 30 mutual customers, and that number continues to grow.

A Growing Partnership

The relationship between Guidewire and AppDynamics has grown even closer in the past six months. One Guidewire customer, for example, deploys AppDynamics across its enterprise. This company, a traditional shop with infrastructure and applications on-premise in its data centers, recently embarked on a CIO-driven initiative to digitally transform and adopt public cloud technologies. The company began working with its trusted providers, including Guidewire, to explore a move to SaaS. It wanted assurance that AppDynamics could provide visibility into all production systems within its environment, including Guidewire. Our previous work with Guidewire made this possible.

At the same time, Guidewire itself began researching APM tools for in-house use. The fact that AppDynamics had done extensive work with Guidewire software made us an ideal choice. This long-term relationship, combined with our industry-leading solution, helped us become a provider of APM for Guidewire, both in preproduction (development, performance testing and QA) and production.

We’re looking forward to continuing our work with Guidewire Software and ensuring that users of Guidewire’s cloud offerings have the best experience possible. AppDynamics would like to thank Guidewire for its partnership, and we look forward to growing together in the future.

Hands Off My Docker Containers: Dynamic Java Instrumentation in Three Easy Steps

Many AppDynamics customers have challenges with modifying startup scripts or updating images in order to inject Java agents, especially in a containerized environment. Other customers might not want to change their build process or completely restructure their projects just to try out a monitoring solution.

Fortunately, there are ways to instrument Java applications without having to access startup scripts or docker-compose.yml files. This blog will show a solution that bundles the dynamic-attach functionality with infrastructure monitoring to instrument Java processes in a Docker environment. This method requires no changes to images or deployment files. It relies instead on the ability of AppDynamics’ Java agents to dynamically attach to running Java processes.

Common Approaches to Inject Java Agent

Typically, injecting an AppDynamics Java agent to a process is done by adding runtime parameters to the Java command that creates the JVM. When done this way, the Java agent lives alongside the JVM and monitors it for its entire lifespan. An example of a runtime injection might look like this in the Java command:

java -javaagent:/appdynamics/AppServerAgent/javaagent.jar -jar customer-app.jar

This approach requires the agent files to be either installed locally or volume-mounted. The controller connection information is also often supplied using the run-time parameters, as well as the name of the AppDynamics Application and Tier that the agent will report to.

The above example is a very common way to inject the Java agent, but there are many variations of this method that can be customized to fit a customer’s needs.

Dynamic Attach

An alternative to the persistent Java agent injection described above is the Dynamic Attach method. The AppDynamics Java agent can be attached to a JVM that is already running, requiring no JVM restart.

This method takes the Java ProcessID and uses the Java -Xbootclasspath parameter to dynamically inject the Java agent into the JVM process. This will cause the JVM to perform a class retransformation necessary to monitor the application. Performance is temporarily impacted during retransformation, but returns to normal after completion.

Dynamic Agent Solution

We have developed a solution that uses Dynamic Attach within a Dockerized environment. This solution is packaged with infrastructure monitoring and is designed to make agent injection very simple to roll out and use. First, we will look at the steps required to use Dynamic Agent, and then talk about how it works.


Use of this solution assumes you have a Java application (using Java 1.7 – 1.10) running in Docker containers on a Linux host machine. This solution will not work with IBM Java or JRockit JVMs. JBoss processes can use this, but only if the standalone.conf file is modified to include the following setting:


Using Dynamic Agent in Three Easy Steps

It is very easy to get started with Dynamic Agent.

Step 1: Download the following repo to your host machine:

git clone

Step 2: Modify controller.env with your controller connection information.

Step 3: Run the script.

Step 4: (optional) Sit back and let your boss and coworkers marvel at how quickly you were able to give them valuable performance and business insights into your applications.

Details on the Three Easy Steps

Step 1:

Aside from the git files, pulling down the git repo will result in four small files being downloaded:

  • controller.env
  • readme.txt


Step 2:

Controller.env is the only file you need to modify. It contains the usual information on how to connect to the controller.






Step 3:

Once you have updated the values in controller.env, you are ready to use the script.


That’s it! Within a few minutes, you should start to see your newly attached agents reporting to your controller.

After a few more minutes, you should see traffic in the flowmap:

controller.env Parameter Reference

A complete and up-to-date reference of controller.env parameters is contained in the readme.txt file in the git repo.

What is a Tier?

As described in the Common Approaches section above, manual injection of the Java agent requires you to specify the Tier name that each process will report to. In contrast, the Dynamic Agent solution has the ability to extract the Tier name from the container. It also gives you options for how the Tier name can be extracted.

By default, the container’s Hostname will be used as the Tier name in AppDynamics. If you want to change this, there are some optional parameters you can set in the controller.env file:


  • TIER_NAME_FROM=HOSTNAME or if left blank or not included in controller.env, it will use the hostname for the Tier name
  • TIER_NAME_FROM=CONTAINER_NAME will cause the process to use the name of the container for the Tier name
  • TIER_NAME_FROM=JVM_PARAM will cause the process to look for the JVM param specified in TIER_NAME_PARAM


For example, the following controller.env file will result in the process looking for a JVM parameter -Dservice-name. It then will use that value for the Tier name in AppDynamics.








How It Works

For reasons that will soon become clear, the relevant parts of this solution run as an extension inside a standalone machine agent. Here are some of the more important files involved in the solution.


The heart of the extension is a Go process. It uses the Docker API to loop through all running containers on the host machine. It inspects each container, looking for a running Java process. If found, it will deploy the appropriate files to the container (housed in agentArchive.tar) and then run one of those files from the container.

This process also keeps track of the container IDs that have been instrumented, allowing it to run every minute without excessive overhead. Any already-instrumented containers will not be re-instrumented. More importantly, new containers will be quickly identified and processed.


Tar files are the only type of file allowed to be pushed to containers by the Docker API. This file contains the Java agent, a copy of tools.jar (because most containers will not have a full JDK), and a script named

The file is responsible for doing the actual dynamic attaching, and includes the Java command with the -Xbootclasspath parameter mentioned earlier.

This script must be run from inside the container. If dynamic attachment is attempted from the host machine, there will be errors because the users won’t match up.

The Power of Dynamic Attach

Even though the Dynamic Attach approach to agent injection is not commonly used, we have seen that it can be a powerful tool for getting a Dockerized Java environment instrumented very quickly. It also provides new possibilities to customers who might not have the ability to modify a Docker image or its runtime parameters.

We’re just beginning to explore the possibilities of what we can do with the Dynamic Attach approach. We’re working to expand this solution to work with other agents, too, such as NodeJS. Also, we’ve already started working on a similar Java solution packaged in a Kubernetes operator…but we’ll talk more about that next time.

This blog may contain product roadmap information of AppDynamics. AppDynamics reserves the right to change any product roadmap information at any time, for any reason and without notice. This information is intended to outline AppDynamics’ general product direction, it is not a guarantee of future product features, and it should not be relied on in making a purchasing decision. The development, release, and timing of any features or functionality described for AppDynamics’ products remains at AppDynamics’ sole discretion. AppDynamics reserves the right to change any planned features at any time before making them generally available as well as never making them generally available.



AppDynamics Supports Scala and the Typesafe Reactive Platform with Play2/Akka

In the AppDynamics Spring 2014 release we added support for the Scala language and the TypeSafe Reactive Platform with support for Play2 and Akka based applications. We are excited to announce a strategic partnership with TypeSafe to provide the best APM solution in the market for Reactive applications.

“Our new partnership with AppDynamics provides end to end visibility into production applications running on the Typesafe Reactive Platform. With AppDynamics’ unique support of Scala, Akka and Play, developers will be able to build reactive applications in record time, troubleshoot issues in real-time, and most importantly be certain that every user has a great experience with their application,” said Dave Martin, Vice president of Worldwide Sales and Business Development, Typesafe

Reactive Applications

Reactive applications are a new class of applications that are becoming more and more prevalent in both Consumer and Enterprise-facing environments. Reactive applications are fundamentally different to the traditional web-based or mobile applications seen today and are distinguished by having one or more of the following defining traits:

  • Event-Driven: Enables parallel, asynchronous processing of messages or events with ease.
  • Scalable: Can scale within and across nodes elastically to provide compute power on-demand when it’s needed.
  • Resilient: The ability to recover and repair itself automatically in order to provide seamless business continuity.
  • Responsive: Rich, engaging, single page user interfaces that provide instant feedback based on user interactions and other stimuli.

Typesafe Reactive Platform

The Typesafe Reactive Platform is a JVM-based runtime and toolset for building Reactive applications. The Typesafe Reactive Platform is a suite of integrated products consisting of Play Framework, Akka, and Scala.

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way.  It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive.

Akka is a runtime for building highly concurrent, distributed, and fault tolerant event-driven applications.

Play Framework is an MVC based web framework that focuses on developer productivity, modern web and mobile applications, and predictable, minimal resource consumption resulting in highly performant, highly scalable applications.

Slick is a modern database query and access library for Scala, where you can write your database queries in Scala instead of SQL, thus profiting from the static checking, compile-time safety and compositionality of Scala.

Spray is a toolkit for building REST/HTTP-based integration layers on top of Scala and Akka.  Being asynchronous, actor-based, fast, lightweight and modular it’s a great way to connect Scala applications to the outside world.


Bootstrapping with TypeSafe Activator

Typesafe Activator gets you started with the Typesafe Reactive Platform, Play Framework, Akka and Scala. A unique, browser-based tool that helps developers get started with Typesafe technologies quickly and easily. Activator is a hub for developers wanting to build Reactive applications. Unlike previous developer-focused offerings that are delivered simply via a website, Activator breaks new ground by delivering a rich application directly to the desktop. Activator updates in real-time with new content from Typesafe and value-add third parties, helping developers engage and adopt Typesafe technologies in an entirely frictionless manner.

The rich developer content in Typesafe Activator is dynamic and customizable. New templates are published regularly on the Typesafe website.

To get started we will use the Reactive Stocks Activator Template:

Adding the AppDynamics Agent

Java Agent


To enable the AppDynamics agent simply download and configure the AppDynamics Java Agent and update your ‘framework/build’ environment with the -javaagent switch:

JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/appdynamics/java-agent/javaagent.jar"

Monitoring the TypeSafe Reactive Platform with the AppDynamics

AppDynamics provides application performance management for Java and Scala applications. Get end to end visibility from the end user to the server side.

Jamie Allen, Director of Consulting at Typesafe talks about the mutual benefits of Typesafe partnering with AppDynamics:


Take five minutes to get complete visibility into the performance of your production applications with AppDynamics today.

Application Monitoring with JConsole, VisualVM and AppDynamics Lite

What happens when mission critical Java applications slow down or keep crashing in production? The vast majority of IT Operations (Ops) today bury their heads in log files. Why? because thats what they’ve been doing since IBM invented the mainframe. Diving into the weeds feels good, everyone feels productive looking at log entries, hoping that one will eventually explain the unexplainable. IT Ops may also look at system and network metrics which tell them how server resource and network bandwidth is being consumed. Again, looking at lots of metrics feels good but what is causing those server and network metrics to change in the first place? Answer: the application.

IT Ops monitor the infrastructure that applications run on, but they lack visibility of how applications actually work and utilize the infrastructure. To get this visibility, Ops must monitor the application run-time. A quick way to get started is to use the free tools that come with the application run-time. In the case of Java applications, both JConsole and VisualVM ship with the standard SDK and have proved popular choices for monitoring Java applications. When we built AppDynamics Lite we felt their was a void of free application monitoring solutions for IT Ops, the market had plenty of tools aimed at developers but many were just too verbose and intrusive for IT Ops to use in production. If we take a look at how JConsole, VisualVM and AppDynamics Lite compare, we’ll see just how different free application monitoring solutions can be.