Now that you have your AppDynamics Controller up and humming, the next step is to instrument an Application to see the awesomeness of AppDynamics in practice.
For this blog post, I’ve chosen a very simple Java Web Application running on a tomcat server (It is the ‘sample’ application that comes with tomcat). The instrumentation process is fairly straight forward. While what I’m about to show is fairly manual, in real world scenarios involving hundreds of servers, you will be using some sort of automation 🙂
At high level, here is the procedure:
- Download the agent software either from the controller UI, or from appdynamics website
- Copy the agent software to the target application server (which is to be instrumented)
- Update the java command line that starts the application to instrument AppDynamics and restart the Application Server.
Ready ? Let’s get started.
OK. So, you want to get AppDynamics controller installed on your Mac. Perhaps you want to test the awesome power of AppDynamics locally before purchasing the product. Great. In this blog post, I’m going to show you how to get AppDynamics Controller installed on your Mac. Let’s get to work.
- Login to https://aperture.appdynamics.com/download/
- Scroll down on the left pane and select the Mac check box
Virtualization is a technique using which you can run multiple Operating Systems (aka Guest) in a physical server (host) by abstracting (or virtualizing) CPU, Memory, Disk and Network resources. The core component of any virtualization solution is Hypervisor – the software that performs the abstraction of bare metal resources.
Here are the primary benefits of using Virtualization:
- Save cost on hardware
- Centrally manage the infrastructure
- Add effective fault tolerance and high availability
- Dynamically update the infrastructure
The diagram below shows virtualization at a high level.
Yes, AppDynamics is awesome for Application monitoring – Java Heap, deep transaction tracing, tons of out-of-the-box framework monitoring (JDBC,WebService etc) and the list goes on. But do you know Appdynamics can be used to effectively monitor Servers too, whether it is virtual or physical? When I say server, I mean the host operating system such as RedHat Enterprise Linux, Windows 2012, Solaris etc. Let me show you how you can do this.
Enter AppDynamics Machine Agent
While Java can be monitored using a Java Agent, a Server can be monitored using a special type of agent called Machine Agent. You will have to have license to run these agents (When you purchase Application agents, typically AppDyanmics throws the same number of Machine Agents, and so you should be good in terms of additional cost). If you are not sure about your present licensing situation, click on ‘licensing’ in your Controller UI as shown below.
Unlike Application agents which run inside the JVM/CLR, Machine agent is a standalone Java program that runs on the host operating system. It collects hardware metrics and sends them to Controller (once a minute). A user can view these metrics via Controller UI. Pretty simple, hah?
Java Heap is a labyrinth. You can spend hours or even days analyzing a heap dump from a production Java application. Heap is where all the objects created by your application live. And even in a relatively simple application, there could be hundreds of thousands of objects created. When dealing with Java memory leak, you know you are looking for one the following (or both):
- Excessive number of objects of certain class
- Objects with unusually large size
Fortunately, Appdynamics provides a feature using which you can easily reveal both of the above cases. Let’s get right to it.
- In AppDynamics Controller UI, locate the Node that you want to troubleshoot and click on ‘Memory’ tab
In this part, let’s explore AppDynamics facilities for diagnosing Memory Leaks. AppDynamics provides two powerful tools to hunt down memory leaks.
- Automatic Leak Detection
- Objet Instance Tracking
Automatic Leak Detection
With Automatic Leak Detection enabled, Appdyanmics can capture objects that live longer than usual period – i.e long lived Collection objects that simply won’t get garbage collected. If your application is leaking memory, it is definitely one of these long-living, never-dying objects that cause the leak. Use the following procedure to make use of this tool.
Troubleshooting JVM memory issues can be daunting, but you if you don’t fix it, it can kill your application and possibly your face in front of your customers. There is good news though. With any modern APM tool, you virtually get an X-Ray vision to this labyrinth named Java Heap.
In this blog post, I’ll show you how to use AppDynamics to troubleshoot Java memory issues.
AppDynamics is one of the leading APM vendors in the market, providing tons of useful tools ranging from Hardware monitoring to End user experience monitoring to operational data analytics (Actually it can be quite overwhelming. If you don’t know what exactly you are looking for in the tool, you can go in circles. But don’t worry, I can help).
There are three major areas where AppDynamics can help in regards to Java memory troubleshooting.
We live in the world of APMs where traffic lights in fancy dashboards show us what’s wrong with our applications in a heartbeat. Definitely a proud achievement (and I highly recommend investing in an APM solution). But at times, you have to get down to very basic, old fashioned troubleshooting. And to be honest with you, it is outright fun.
In this article I want to show you how you can troubleshoot using web server access log. I am going to use Apache 2.X as example web server (Even with Nginx on the rise, apache is still the most popular web server in the world. Sorry IIS).
Before we dive in to the access log, here is a very high level architecture that shows where apache typically sits. For simplicity sake, I have not shown things like DMZ zone, Caching servers, Web Access Firewalls, Reverse proxys etc)
Analyzing logs can be fun, tricky, frustrating and valuable – all at the same time. As a problem solver, you must equip yourself with efficient tools to do the mundane work. In this article, let me show you three somewhat less popular log analysis tools. They are less popular because they are sparingly used by companies here and there (mainly due to Administrators becoming familiar with a certain tool over time). Check these out, who knows you might end up liking one of these tools and put it to good use.
Apache log4j is the foundation for java based applications. Chanisaw was written to provide a graphical view of log4j logs.
Image source: http://logging.apache.org/chainsaw/
Some notable features:
You can use expression based filtering and also do some quick-and-dirty filtering
Specify your own rules to highlight log records
Capturing remote events
Using the ‘Receiver’ concept you can configure chainsaw to capture logs from a remote source
Java memory leaks can be deadly, and difficult to troubleshoot. Are you one of those shops where you restart your Application Servers at regular intervals (weekly, daily or more frequently)? It is pathetic, is it not? Wait a minute, gone are the days where we had 128 MB memory on servers. We have several giga bytes of memory on servers, don’t we? Why do we still run into memory issues? Good question. But sad truth is there are several reasons why Memory leak is not something that will go away. All you can do is to prepare yourself. And that’s what this article is about. Let’s dive into 10 things you need to know about Java memory leak.
1. Java Heap Memory leak is different from Native Memory leak
Java heap is where the objects created by your application live. The maximum heap is determined by the –Xmx flag of the Java command line that starts the application. If you write code that leaks memory, there is where it will blow up.