How to Build Hybrid Cloud Confidence

This blog post is coauthored by Vamsi Chemitiganti, Chief Strategist at Platform9 Systems.

The hybrid cloud is not a new concept. Way back in 2010, AppDynamics founder Jyoti Bansal had an interesting take on hybrid cloud. The issues Jyoti discussed more than eight years ago are just as challenging today, particularly with architectures becoming more distributed and complex. Today’s enterprises must run myriad open source and commercial products. And new projects—some game-changers—keep sprouting up for companies to adopt. Vertical technologies like container orchestrators are going through rapid evolution as well. As they garner momentum, new software platforms are emerging to take advantage of these capabilities, requiring enterprises to double down on container management strategies.

Building Applications: 2008 vs. Now

When you consider how applications were built a decade ago, today is truly an amazing time to be a software engineer. From a commercial Java standpoint, software vendors in 2008 may have released only a few variations of their application—for instance, specific WAR (web archives)—to account for differences in application servers. Fast forward to today: commercial vendors must expose entirely how the sausage is made and provide a litany of formats to deploy and integrate with CI/CD and hybrid cloud infrastructures.

The 2008 point of view: commercial vendors delivering just a WAR.

Enterprises today are doing more due diligence. It’s not uncommon for enterprises to ask for source/binaries, quality/security scans, infrastructure-as-code templates, container orchestrator descriptors, and cloud vendor deployment scripts.

With enterprises needing to run a wider array of technologies, decisions must be made on where to run these workloads. The hybrid cloud allows enterprises to pick and choose which workloads and tools to run internally, and when to leverage a public cloud service.

Current Hybrid Cloud Prospective

The hybrid cloud is composed of six fundamental components, as shown in the illustration below. This diverse infrastructure spans public and private clouds to deliver a mix of VMs, containers and bare metal deployments; a SaaS-delivered management plane that guarantees 99.999% uptime; a certified catalog of applications for developers with single-click self service, and an ability to run application architectures composed of various runtimes (e.g., Tomcat, NGINX, Kafka, Istio, Spring Boot, and so on); CI/CD toolchains; line-of-business self service; and application architectures that are a mix of stateless microservices, stateful applications and serverless functions.

The six pillars of the hybrid cloud.


In a cloud-based infrastructure, the key concerns facing enterprises include complex cloud management, overall cost of infrastructure, and the lack of a single pane of glass for metrics. These lead to pain points in Day-1 and Day-2 operations, a lack of choice for developers, slow provisioning times and overly complicated management stacks.

The Key to Hybrid Cloud Success

Success depends on your ability to quickly deliver all of the above components: a lean hybrid cloud in days and weeks, not months. With an effective strategy, an enterprise can bring together all of the six component technologies, creating a hybrid cloud that “just works.” This includes the ability for both developers and infrastructure admins to deploy applications and workloads on any underlying cloud provider, a single pane of glass across all the underlying clouds, and a robust catalog of application runtimes for developers.

Incremental Success Develops Cloud Confidence

The ability to deliver a lean hybrid cloud in days or weeks is an ambitious goal. When picking workloads to run on the private or public cloud, metrics become a crucial component of your strategy. One of AppDynamics’ core strengths is its ability to compare workloads and platforms for effectiveness. When a new application works effectively in your hybrid cloud infrastructure, you gain confidence in your investment and quickly bring additional workloads into the new model. By using AppDynamics to trace a business transaction such as user conversion, IT can easily justify where and why a workload is running in a particularly segment of the hybrid cloud environment.

AppDynamics provides essential KPIs for comparing workloads—a great resource for justifying your cloud migration strategy.

The Hybrid Cloud Revolution Continues

As our cloud topology marches towards cloud infrastructure nirvana, where organizations can reallocate workloads to the most prudent infrastructure provider(s)—either on- or off-prem—confidence in your hybrid cloud is crucial. Look to AppDynamics and Platform9 to help you navigate this exciting new world!

Unlocking Insights and Visibility Into TIBCO With APM Software

TIBCO Software is a global leader in integration, API management and analytics. The company recently was named a leader in the Gartner 2018 Magic Quadrant for Full Life Cycle API Management report for the fourth consecutive time. TIBCO’s traditional strength in application integration is based on its enterprise service bus (ActiveMatrix BusinessWorks), message-oriented middleware (Enterprise Message Service and FTL), and off-the-shelf adapters for applications and other platforms.

TIBCO offers real-time analytics and operational intelligence, including process-intelligence Business Activity Monitoring (BAM) (in AMX BPM); business intelligence BAM, visual data discovery and predictive analytics (in Spotfire and R); business rule processing (in AMX Decisions); two stream analytics CEP platforms (BusinessEvents and StreamBase); and other capabilities.

Critical Banking and Infrastructure Dependencies Require Reliability

In large financial institutions around the world, critical processes such as online banking, mortgages and payments rely on TIBCO. If TIBCO systems were to go down, banking customers wouldn’t be able to get mortgage information, borrow money, or even pay their bills. Indeed, the importance of keeping TIBCO systems up and running is extremely high. It’s equally important for TIBCO users to identify issues, provide solutions, and respond immediately to potential problems as quickly as possible.

More Insights, Please

TIBCO’s product line is extremely powerful, but it can be complicated and expensive for many small and midsize business process management (BPM) projects. As I’ve seen quite a few times throughout my career, TIBCO can be a black box for companies, which usually lack the ability to see inside the code. The reason is that TIBCO users are not exposed to code, but instead use a GUI called TIBCO Designer to create integration projects for their enterprise environments. The good news is that application performance management (APM) software can provide insights into how TIBCO is working under the hood.

When you intend to monitor something as immensely complex as TIBCO, you need a good plan. The first step is to identify what is important and what is not. Therefore, your initial focus should be on identifying the most important business flows on the TIBCO side, and defining the most important business transactions on the APM side. Mapping the relationship between TIBCO workflows (customer/business journeys) and AppDynamics Business Transactions—a key monitoring component consisting of all required services in your environment—is the next logical step. (For a deeper dive into the philosophy of configuring BTs, read How to Identify Impactful Business Transactions in AppDynamics.)

Once mapping has been established, TIBCO users should be able to understand and ultimately resolve performance issues, as well as optimize infrastructure and application setup. But that’s just the beginning.

Dashboards for Real-Time Metrics

AppDynamics can enrich TIBCO monitoring by comparing real-time EMS metrics side-by-side with metrics measured by our Java agent in handy dashboards, providing useful insights into TIBCO’s performance. This is achieved by configuring the AppDynamics TIBCO EMS Monitoring Extension. You will need to give this extension access to your TIBCO EMS server. Our machine agent then uses the extension and feeds the data directly from the EMS server to AppDynamics, where we can display it side-by-side next to real-time metrics provided by our Java agents.

How About Some Alerts?

Of course, users also need to know when something is wrong—and not only by looking at a nice dashboard! This is why you should utilize the power of AppDynamics Health Rules, which leverage dynamic baselines to establish performance thresholds and configure them for Business Transactions. Once these rules are defined and configured, you’re all set: When AppDynamics detects a potential issue, it triggers a Health Rule and sends out a notification. This enables the user, with just a few clicks, to examine the Business Transaction snapshot and get code-level details for every anomaly, even under extreme load. Therefore, AppDynamics’ three-click drill down allows TIBCO customers to pinpoint issues in a very short amount of time.

In many respects, TIBCO is still a grey area for companies, as it is difficult, if not impossible to see its inner workings. (As mentioned above, TIBCO users never see the internal code, but instead rely on the GUI-based TIBCO Designer.) AppDynamics’ monitoring brings more insight into how TIBCO works behind scenes, and gives users a better understanding of how their configuration is tied to TIBCO code. Although it might not be meaningful to the user to see TIBCO code errors, this information could prove valuable to TIBCO support and lead to faster mean time to resolve.

A High-Level Overview

For companies using TIBCO as a backbone for their services, a cross-application flow view is exceptionally useful for seeing which applications are communicating with TIBCO. The screenshot below shows a practical, graphic representation of a TIBCO user’s environment in AppDynamics.*

AppDynamics can create an intuitive diagram of TIBCO workflows, such as one showing the health of each TIBCO operation translated into one or more Business Transactions.

Above you see a slightly different view, one more business-focused and based on normal APM data. However, if you need more detailed business-focused dashboards with funnel graphs, a number of unique transactions, or full end-to-end duration of each transaction, there is a way! All this and much more can be achieved by using AppDynamics Business iQ. (Read how AppDynamics Business Journeys provide a unified, end-to-end application view and help solve complex business problems.)

Global financial institutions depend on TIBCO’s real-time analytics and operational intelligence to keep their operations running efficiently. But TIBCO can be a black box for companies, which need a powerful APM solution to gain code-level insights into their environments and to resolve issues quickly.

*All screenshots shown in this article are not actual representations of TIBCO’s environment.

Why Idempotency and Ephemerality Matter in a Cloud-Native World

The first time I heard “idempotent” and “ephemeral,” I had no idea what they meant. Perhaps I should have, though, because idempotent and ephemeral patterns are not new to the computing world.

In mathematics and computer science, idempotence is a property in which no matter how many times you execute some operations, you achieve the same outcome. Ephemerality is a concept of things being short-lived or transitory. In a Cloud Native environment, we expect consistency and portability with the presumption that infrastructure will likely be impermanent, including containers that are transient and disposable. These shifts are influencing providers across multiple layers of the OSI Model.


Again, “idempotent,” threw me the first time I heard it. I had not felt so perplexed by the meaning of a word since childhood. I was a staff developer and excited to use JMS for the first time. My team was starting to modernize a financial service client’s system to be event-based, implementing ActiveMQ as the message broker. We were determining transaction boundaries and suffering from duplicate messages that were wreaking havoc on our final calculations. One of the project’s senior developers suggested I make the endpoint “idempotent.” I gave him a blank look as if he was speaking pig Latin.

Someone recommended I get a copy of what soon became one of my favorite books, Enterprise Integration Patterns. The book’s authors, Gregor Hohpe and Bobby Woolf, describe a lot of the system-to-system design patterns that we depend on today. In the case of the financial service client, the design pattern was Idempotent Receiver (Consumer). We deployed into one of the client’s data centers, and minus a severe application infrastructure fault, we were under the guise that the center’s infrastructure would be there indefinitely.

By today’s standards, our application infrastructure was fragile. Our duplicate check implementation was very stateful, but if the service had stopped we would have been open to duplicates again. In the next iteration of our application, we designed the idempotent service to be more robust—something we would’ve done sooner had we not been under the guise that our infrastructure was more stable than ephemeral.


Cloud providers are looking to capture more workloads while providing their clients with better ROI. When Google launched its Preemptible Virtual Machine in 2015, it was responding to a demand for lower-cost instances. Due to the short-lived nature of instances, I was having a hard time wrapping my head around the workload that would be appropropriate for a Preemptible Virtual Machine—or even an Amazon Spot Instance, which offers spare compute capacity in the AWS cloud at steep discounts.

The rise of preemptible or spot instances shows the upsurge in ephemeral computing. As enterprises grapple with the nuances of cloud cost, one avenue for lower-cost services is to have the compute live for a shortened, or ephemeral, period.

Prior to preemptible or spot instances, there was a baseline understanding that compute capacity would exist for a finite period of time. Because of cloud availability, some organizations treated traditional instances as indefinite. For a planned hardware upgrade, the cloud vendor would give its customers advance notice to switch workloads over to another instance. For unplanned events like outages, a service designed to be multi-region or multi-zone would suffice.

Today, it feels like we are designing workloads to cope with Chaos Monkey at every level, including infrastructure. There’s a growing understanding that our workload infrastructure likely won’t be there in a predictable format. As a result, we’re building more robust services to cope with this unpredictability. These changes spotlight the importance of keeping workloads portable in case we have to switch to another instance, region, zone or provider.

Software is Eating (Feeding) the Cloud Native World

Marc Andreessen’s famous quote—“software is eating the world”—proves equally true in the Cloud Native space. The most prolific push for generic hardware has been led by public cloud vendors. Similar to enterprises making the move to x86, cloud vendors have been pushing to make all parts of their stack as generic as possible. In case of failure or expansion, vendors can swap a generic part in and out with ease.

With the generic hardware approach, a good amount of logic moves to the software stack. The rationale here is that if hardware is ephemeral, reconstituting the compute, storage, and even networking would be both seamless and consistent with software-defined storage and networking. Applying this to the public/hybrid cloud market, a software-driven solution that’s robust, scalable and portable becomes a core component of Cloud Native.

Save Us, Software!

Configuration control and consistency is moving down the stack: from application to application infrastructure, and now down to infrastructure. With advances in software-defined infrastructure (SDI), the trifecta of load-balancing, clustering and replication can be applied to multiple parts of the stack.


Medium has a very well-written article on the different layers of software-powered networking, from software-defined networking (SDN) to container networking. With the ever-widening adoption of the container networking interface (CNI), containerized applications can have a more consistent approach to network connectivity. For example, with Cisco Application Centric Infrastructure as a robust SDN platform, coupled with a service mesh, enterprises have a consistent and recreatable way of discovering and participating in services. AppDynamics can provide insight into this increasingly complex networking landscape as well.


Not long ago, storage in the cloud world was viewed as non-ephemeral. But as offerings, practices and architectures have begun to shift for some cloud storage products, there’s now a delineation between ephemeral and non-ephemeral storage. Although one of the pillars of a twelve-factor application is to run stateless processes, some sort of state needs to be written somewhere, and a popular place is to disk. Advances in software-defined storage (SDS), with projects such as Ceph and Gluster, provide object and file storage capabilities, respectively. Similar to the delineation of SDN and CNI, there is SDS and Container Storage Interface (CSI). For example, Portworx, a popular cloud-native storage vendor, coupled with commodity cloud or on-premises storage, allows for greater portability and storage consistency from the infrastructure to the container/application level.

One More ‘y’ Term

A successful Cloud Native implementation requires another key component: observability. Because without proper visibility into the stack, it’s nearly impossible to know when and how to react to an ephemeral infrastructure action to maintain idempotency.

Idempotency + Ephemerality + Observability = Cloud Native

Despite the inherent challenges with observability, insight into the system is crucial. Relating changes in ephemeral infrastructure to overall sentiment and KPIs can be a challenge as well. With AppDynamics, it’s much easier to validate and advance your investment in the software-defined world.

AppDynamics provides insight on KPIs for a cloud migration/infrastructure change.


AppDynamics delivers deep insights into containers running across an enterprise infrastructure.

A Look to the Future

Every month it seems like a new project is accepted into the Cloud Native Computing Foundation, which is very exciting. As enterprises march toward infrastructure nirvana, where organizations can recreate robust and consistent infrastructure in an ephemeral world, Cloud Native computing will be an important part of the equation. With the power to create cloud computing almost anywhere, it’s important to not lose focus of non-functional requirements such as security. Cisco’s Tetration Platform, which addresses security and operational challenges for a multicloud data center, can protect hybrid cloud workloads holistically.

Look to AppDynamics for help with navigating the Cloud Native world!

Deploying at Scale: Chef, Puppet, Ansible, Fabric and SaltStack

The manageability, reliability and powerful technology of remote servers — cloud computing — allows IT managers to deploy hundreds, even thousands of machines. At the same time, the cloud creates a new challenge for sys admins and ops teams: how to maintain and configure all these machines. How do you apply patches, maintain updates and fix security gaps?

The answer is to use powerful tools like Chef, Puppet, Ansible, Fabric or SaltStack for managing Infrastructure As Code (IaC) automation. IaC means deploying and managing infrastructure for computing, including virtual servers and bare-metal servers. Definition files are used instead of physical hardware management. Here is a bit of the history, background, advantages and disadvantages for each of these infrastructure configuration management tools currently on the market.


Puppet was founded in 2005 by Luke Kanies, making it one of the earliest infrastructure configuration management tools. It is free software written in Ruby and made available under the Apache Software License 2.0, although it was released using the GNU General Public License up to version 2.7.0. It operates declaratively on Microsoft Windows and UNIX-based systems like AIX, Solaris and Mac OS X. Puppet uses a declarative language to define system configuration. To begin, you set up system resources and relevant state that are stored in files called Puppet Manifests. A resource abstraction layer then lets you use higher-level terms such as packages and services to define configuration.

Because Puppet is model driven, you don’t need an extensive programming background to use it. In a model-driven approach, you can set up how you want the infrastructure and applications to operate. With the model in place, you can then test and evaluate changes you want to deploy across the system. Constant reporting and feedback allows you to improve processes, show compliance and tweak the results as you go. Puppet is perhaps the most popular infrastructure configuration and management tool among those described here, used by a variety of organizations including:

  • Mozilla
  • PayPal
  • Spotify
  • Oracle
  • Rackspace
  • Wikimedia Foundation


Chef is a configuration management tool Adam Jacob developed to use in his consulting company. Seeing a broader use for managing Amazon Web Services operations, he joined with Nathan Haneysmith, Barry Steinglass and Joshua Timberman to found a firm called Chef to manage the tool.

Chef is based on “recipes” that describe how the software will configure and manage utilities and server apps like MySQL or Hadoop. These recipes can be combined to form a “cookbook.” Each recipe defines resources used in a state such as what services should be operating, what packages need to be installed and what files need to be created. The resources can be modified to make sure programs are installed in a specific order based on dependencies. Industry commenters often suggest that DevOps and developers usually choose Chef while SysAdmin’s prefer Puppet.

There are two versions of Chef: an open-source basic version and a premium enterprise edition. The enterprise offering has both on-premise and hosted versions. Open-source Chef is available at no charge but lacks many of the add-ons in the enterprise edition as well as ongoing support.

Chef began as a Linux product but later added support for Microsoft Windows. It runs on major platforms including

  • Solaris
  • Ubuntu
  • Microsoft Windows
  • FreeBSD

It is used by companies and websites such as:

  • Facebook
  • Airbnb
  • Expedia
  • Citi
  • Disney

Chef and Puppet are two of the largest infrastructure management tools available to you. They both continue to respond to the needs of enterprise companies by providing new features, and they are also busy creating partnerships with major vendors like Microsoft to better integrate with their platforms. Puppet has also aligned with software defined networking (SDN) vendors to stay in the forefront of that technology. Choosing between the two is a matter of determining the core advantages of each and figuring out which align with your requirements.


Ansible is an open-source software framework for managing and configuring infrastructure. It offers configuration management, software deployment for multiple nodes and ad hoc task execution. You can manage it using PowerShell or through a secure shell (SSH). This software framework was developed by Michael DeHaan, who was also one of the original developers over the Func framework used for administering systems remotely. Ansible is included in distributions of Fedora, and is also available if you use CentOS, Red Hat Enterprise Linux, Scientific Linux and other operating systems. A company of the same name was created to support the software product and help it grow in business markets. Red Hat acquired the company in 2015.

The name Ansible is derived from a communications system in “Ender’s Game,” a 1985 novel by Orson Scott Card. The fictional system was first invented for the 1966 novel “Rocannon’s World” by Ursula K. Le Guin.

Ansible controls two kinds of servers: nodes and controlling machines. The system is based on a single controlling machine, which configures and manages nodes using SSH. Modules are deployed over SSH to orchestrate notes, which then communicate to the controlling machine using a JSON protocol. Ansible is light on resources because when it is not managing nodes, it does not run any programs or daemons waiting for utilization.

Unlike Puppet and Chef, Ansible has an agentless architecture where nodes need a daemon to talk to the controlling machine. Under this system, nodes do not need to install and operate daemons in the background to communicate. This set-up significantly reduces network overhead because it stops nodes from constantly polling the controlling machine.

Ansible was designed with a minimalist approach, with a focus on making sure managing the system does not create additional dependencies on the system itself. It is secure because it requires OpenSSH. In addition, Ansible playbooks are written in an easy-to-learn, descriptive language. It is used in a variety of private and public clouds including:

  • Google Cloud Platform
  • OpenStack
  • SoftLayer
  • Amazon Web Services
  • XenServer

Ansible works well with Aerospike, Riak and Hadoop, monitoring resource consumption by every node while using few CPU and memory resources. Organizations and companies deploying Ansible include:

  • NASA
  • Weight Watchers
  • Juniper
  • Apple

Its agentless model makes it a popular choice for government divisions such as NASA because it is very secure, a quality highly valued in federal and state governments.


Fabric is an open-source command line tool and Python library used to smooth out SSH utilization for system administration and application deployment. It consists of a suite of operations for launching shell commands, either locally or remotely, via sudo or normally; downloading and uploading files; and asking for input from users, stopping execution and other auxiliary functions. While products like Puppet and Chef focus on organizing and handling system libraries and servers, Fabric is more concerned with deployment and other application-level functions.

Developers like Fabric because it is simple, easy to maintain and you can add any type of job quickly. You can execute Python functions using the command line, and launching shell commands on SSH is simplified due to the extensive library of subroutines. Companies using fabric include:

  • Snap
  • Coursera
  • Instagram
  • Sosh
  • FlightAware
  • The Orchard

Fabric development is managed by Jeff Forcier. He is assisted by open-source developers who add suggestions and patches through the Fabric mailing list, on IRC chats or via GitHub.


SaltStack is an open-source platform based on Python, and it is used for managing and configuring cloud infrastructure. It was developed by Thomas S. Hatch using ZeroMQ to create a better tool for collecting and executing data at high speeds. Initially released in 2011, Reliable Queuing Transport (RAET) was added in 2014. The project has subsequently been developed through a partnership that includes several large enterprises. SaltStack was built from the ground up to be highly modular and flexible, and able to adapt to diverse applications. It creates Python modules that each manage a different part of the Salt system. You can detach and modify the modules to fit the needs of your project. Each module is designed to handle a specific action. The six types of modules include:

  • Execution modules which offer functions for directly executing the remote execution engine as well as help manage portability and core API functions.
  • Grains detect system static information and keep it in RAM for fast access.
  • State modules represent the back end, executing code to configure or change a target system.
  • Renderer modules pass information to the state system.
  • Returners modules manage the return locations associated with remote execution calls.
  • Runners are convenience apps.

SaltStack created a buzz early on by capturing the 2014 InfoWorld Technology of the Year Award as well as the 2013 TechCrunch Award for Most Exciting Project. Organizations and companies using SaltStack include Adobe, Jobspring Partners, Dealertrack Holdings, JumpCloud and International Game Technology.

This article covered five of the top infrastructure configuration and management tools available. It’s a highly dynamic area of enterprise computing, with new tools constantly evolving to solve various challenges. Each of these solutions gives you lots of ways configure your infrastructure, allowing you to manage digital transformation at scale easily and efficiently.

Learn more

Find out more about our Infrastructure Monitoring tool.

Gain insight into your infrastructure with Server Visibility

To succeed in today’s hyper-competitive and fast-changing marketplace, enterprises must pursue digital transformation leveraging software to deliver and support their products and services — with the goal of creating an ideal user experience and maximizing business agility and efficiency. To provide excellent end-user experience, enterprises need to manage their applications end-to-end including their dependencies on the underlying server infrastructure to deliver exceptional experience.

AppDynamics Server Visibility, a new module of the AppDynamics Application Intelligence platform, provides an application-centric view of servers in the context of business transactions. This helps IT Ops teams proactively isolate and resolve application performance issues faster with actionable, correlated application-server metrics. It complements end-user monitoring, application performance management, and database visibility modules to provide a comprehensive, end-to-end view of the entire application ecosystem.

Server Visibility provides an entire view into CPU, memory, disk, networking, and running processes metrics for Linux and Windows servers. In my blog announcing the beta of this solution in June 2015, I reviewed some of the key features.

In this blog, I will provide review a couple of use cases where application support personnel or a developer may use the new Server Visibility module in conjunction with the AppDynamics APM solution to quickly isolate and resolve an application performance issue.

Drill down from application flow map to Server Visibility dashboard

Customers can drill down from the application flow map to the server dashboard and see the detailed server metrics in case the server issues are impacting the performance between two application tiers.

Let me review a scenario where the application flow map shows calls between two tiers are taking longer than normal. In Fig 1 below, we can see that the E-Commerce tier is having some problems since half of the tier has turned red. Pretty obvious, right? We can also see on the right-hand, the server health indicator shows critical response time.

Server Monitoring Blog Fig 1.png

Fig 1: Application Flow Map with Server health indicator showing issues

Clicking on the E-Commerce Services tier, you will notice a new tab called “Servers” which will show you the list of servers (as you can see in Fig 2) on which the nodes under this tier are running. You will notice that health indicator for both servers have turned red.

Server Monitoring Blog Fig 2.png

Fig 2: List of servers supporting an application shown in the flow map

Clicking on any server, you will get to a server dashboard (Fig 3) with an indicator of server health, key performance indicators, server properties and top 10 processes consuming CPU and memory.

Server Monitoring Blog Fig 3.png

Fig 3: Server Visibility Dashboard

Here you can clearly see that CPU consumption has often been reaching 100%, and may be contributing to application performance issue at the E-Commerce tier. From the server dashboard, customers can also go to other tabs with detailed information on attached storage, network, and processes for additional details required for troubleshooting.

Troubleshoot server-related performance issue by drilling down from transaction snapshot

AppDynamics enables enterprises to proactively track lagging application performance, troubleshoot the root cause, and resolve them before they impact their customers. Let’s look at the use case of troubleshooting server related application performance issue by drilling down from business transaction snapshot following the same E-Commerce application scenario (Fig 1) discussed in last use case.

As you can see in the transaction scorecard shown in Fig 1, 26 of the transactions are very slow. To troubleshoot the root cause of these very slow transactions, you can simply click on the very slow transactions in the transaction scorecard to go to the list of transaction snapshots.

Server Monitoring Blog Fig 4.png

Fig 4: Transaction Snapshot

Looking at the transaction snapshot taken at 4:12 PM on 01/20/16, you’ll see the snapshot details as shown in Fig 4 above. You can now drill down further into the calls at the E-Commerce server to troubleshoot the root cause. Clicking again will bring up a more granular view and take you to the snapshot details showing a call graph and another tab for server details as shown below in Fig 5.

Server Monitoring Blog Fig 5.png

Fig 5: Transaction Snapshot drill down

Server Monitoring Blog Fig 6.png

Fig 6: Transaction Snapshot drill down

By clicking on the server tab, you will reach the server dashboard (as shown below in Fig 6) with an indicator of server health, key performance indicators, server properties and top 10 processes consuming CPU and memory. Here you can clearly see that CPU consumption has been maxing out, which can be contributing to the very slow transaction.

You can further drill down to see which processes are consuming CPU cycles by scrolling down to take a look at top 10 processes consuming CPU. As you can see in Fig 7 below, the antivirus process is consuming approximately 70 of CPU cycles contributing to the slowness of the business transaction, ultimately affecting the end-user.

Server Monitoring Blog Fig 6.png

Fig 7: Transaction Snapshot

Hopefully, this gives you an overview of use cases how the new Server Visibility module can be used in conjunction with the AppDynamics APM solution to isolate quickly and resolve an application performance issue.

Interested in learning more about Server Visibility? Attend our free webinar here.