CAT | News
Today AppDynamics announced integration with PagerDuty, a SaaS-based provider of IT alerting and incident management software that is changing the way IT teams are notified, and how they manage incidents in their mission-critical applications. By combining AppDynamics’ granular visibility of applications with PagerDuty’s reliable alerting capabilities, customers can make sure the right people are proactively notified when business impact occurs, so IT teams can get their apps back up and running as quickly as possible.
You’ll need a PagerDuty and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of PagerDuty and AppDynamics online. Once you complete this simple installation, you’ll start receiving incidents in PagerDuty created by AppDynamics out-of-the-box policies.
Once an incident is filed it will have the following list view:
When the ‘Details’ link is clicked, you’ll see the details for this particular incident including the Incident Log:
If you are interested in learning more about the event itself, simply click ‘View message’ and all of the AppDynamics event details are displayed showing which policy was breached, violation value, severity, etc. :
Let’s walk through some examples of how our customers are using this integration today.
Say Goodbye to Irrelevant Notifications
Is your work email address included in some sort of group email alias at work and you get several, maybe even dozens, of notifications a day that aren’t particularly relevant to your responsibilities or are intended for other people on your team? I know I do. Imagine a world where your team only receives messages when the notifications have to do with their individual role and only get sent to people that are actually on call. With AppDynamics & PagerDuty you can now build in alerting logic that routes specific alerts to specific teams and only sends messages to the people that are actually on-call. App response time way above the normal value? Send an alert to the app support engineer that is on call, not all of his colleagues. Not having to sift through a bunch of irrelevant alerts means that when one does come through you can be sure it requires YOUR attention right away.
If you are only sending a notification and assigning an incident to one person, what happens if that person is out of the office or doesn’t have access to the internet / phone to respond to the alert? Well, the good thing about the power of PagerDuty is that you can build in automatic escalations. So, if you have a trigger in AppDynamics to fire off a PagerDuty alert when a node is down, and the infrastructure manager isn’t available, you can automatically escalate and re-assign / alert a backup employee or admin.
The Sky is Falling! Oh Wait – We’re Just Conducting Maintenance…
Another potentially annoying situation for IT teams are all of the alerts that get fired off during a maintenance window. PagerDuty has the concept of a maintenance window so your team doesn’t get a bunch of doomsday messages during maintenance. You can even setup a maintenance window with one click if you prefer to go that route.
Either way, no new incidents will be created during this time period… meaning your team will be spared having to open, read, and file the alerts and update / close out the newly-created incidents in the system.
We’re confident this integration of the leading application performance management solution with the leading IT incident management solution will save your team time and make them more productive. Check out the AppDynamics and PagerDuty integration today!
At AppDynamics we’re laser focused on Application Performance Management. Our growth over the past three years has been fuelled by customers worldwide who selected AppDynamics as their preferred APM solution over legacy vendors like BMC Software and Compuware. This is one of the reasons why AppDynamics was positioned as a Leader in its debut year for the Gartner APM Magic Quadrant.
According to Reuters on March 21st, buyout firms are teaming up to take BMC private via auction, in addition Reuters also reported today that Sandell Asset Management are urging Compuware Management to sell the company, ”We believe that the only viable path to maximize stockholder value, rather than destroy it, is to execute a sale of the company to the highest bidder as promptly as possible. ”
So, if you’re considering APM in your organization, ask yourself one question:
Get started today with AppDynamics with our free trial.Link to this post:
The most common cause of application slowdowns today is slow SQL or stored procedures in the database. The reason? Databases store large amounts of data on disk, and disk is super slow relative to data in memory (unless its SSD). As data volumes grow, the need to configure, maintain and optimize a database also grows because you can’t manage everything on one disk or volume. This is why database administrators (DBA’s) exist.
A huge problem is that developers write ad-hoc SQL queries for their applications and have no idea how those queries actually execute and retrieve data from disk in the database. They are blind to the number of records in a table, or which columns in a given table has indexes. This is why developers typically blame the DBA when their SQL queries run slow– they assume slow queries means a slow database, and that the DBA isn’t doing his job properly. This couldn’t be further from the truth.
With AppDynamics for databases we’re now giving DevOps teams visibility of how their application SQL queries actually execute within the database, so when things slow down they can now collaborate with DBA’s instead of blaming them. Thats right, users of AppDynamics will now be able to find the root cause of slow SQL and stored procedures in their application. This is indeed good news because customers can dramatically improve their end user experience, response time and application throughput by tuning their data access layer.
Obviously, SQL executes differently in different databases, thats why we built AppDynamics for databases to provide universal support for all common relational databases like Oracle, SQL Server, DB2, Sybase, MySQL and PostGres. This is a big deal because no monitoring vendor at the moment provides database diagnostics across all type of relational databases, not to mention providing the application and business transaction context.
So let’s show you a few screenshots of what AppDynamics for Databases can give you.
Single Pane of Glass View
How about a single pane of glass view to monitor ALL your databases regardless of platform? done. Application databases these days vary significantly, most use Oracle, some use MySQL and obviously .NET applications are better related to windows-based databases like SQL Server and Sybase. Its therefore important you can get a holistic view of performance across all your databases.
Real-Time Performance Metrics:
Its always good to know exactly what is happening “right now” in a database. Has the database ran out of connections? or is the database experiencing latency from locking on rows? These are just a few answers you can get from the below “Current” workspace which provides a real-time view of database resources and performance.
Historical Analysis of Database Activity:
Real-time data is good, but its also helpful to have historical data so you can identify trends, spikes and abnormal patterns in performance. For example, a simple application code change can have a dramatic impact on a database and its performance. We had an agile customer last year who deployed a code release in production and immediately saw a slowdown in application response time. When they drilled into AppDynamics for Java they noticed that one business transaction was now performing 25 SQL queries per execution instead of just 2 queries, this was the difference between 20,000 and 250,000 executions per minute in the database. Obviously when you increase concurrency that much in the database your going to experience contention and wait, being able to visually track database resource, time spent, wait states and number of executions over-time is invaluable.
Top SQL Statements and Stored Procedures:
Perhaps the most obvious view you’d expect from a database monitoring solution. This is typically what most Application Performance Monitoring (APM) vendors provide by extracting data from the JDBC or ADO.NET protocols. The big difference between those solutions and AppDynamics is that we allow you to drill down into the SQL or stored procedures and understand their execution plans, so you can actually find the root cause of why your queries run slow. This is great data for application support teams and developers who want to collaborate better with their DBA’s, so they can understand the real reason of database latency.
Most databases will automatically parse and refine the execution of SQL queries based on what plan its query optimizer selects. Just because you add an index to a table to try and make a query faster, doesn’t mean the database query optimizer will use it, and when you consider that index’s aren’t for free (they take up disk space) you might want to check exactly how the database is executing your queries. Take a look at the below explain plan and you can see how the SQL is being processed with two simple selects and two different tables. Notice how the SUBQUERY on the iplookup table is using the index ‘ian1′ because that table has over a million rows in it. If this index was accidentally dropped you can be sure this query would run significantly slower given it would be doing a full table scan on over a million records.
How frequently are applications connecting to your database? and what operations are these applications performing? Applications differ by the volume of data they request, process and manage over-time. For example, in a Cable or Telco provider you might have a customer portal application which accesses customer data inside a large Oracle schema. That same Oracle schema may also service queries from reporting applications for marketing, or perhaps batch jobs from billing applications that need to process large volumes of customer data. If you have different applications performing different operations (read, write, update, delete) at the same time on the same database then that can be a recipe for disaster. You can see from the below screenshot that the application connect to this MySQL instance is spending most of its time inserting data, meaning its write intensive versus read intensive. Obviously if the database and application was purely read intensive, you might consider moving that data to a cache in memory closer to the application logic. Remember, database calls are often remote and expensive, ever so more in the cloud where storage is less than stella.
All database schema’s have generic objects that represent users, databases, tables, indexes and so on. These objects are often configured and maintained by DBA’s to ensure that the database is optimally configured for availability and performance. Change is constant within databases because data volumes are always increasing, and application data models are always evolving to support new features. Making a single configuration change can have a dramatic impact on database and application performance. AppDynamics for databases flags and provides a full audit report on all changes made within the database as shown below. This helps DevOps and DBA’s correlate the impact of change with database performance which can be very powerful. If someone dropped an index and performance spikes shortly after then thats worth knowing!
I walked through just a few features and capabilities of AppDynamics for Databases, here’s a quick 4 minute overview of the product:
You can get started right now and sign up for our free trial.
Happy database monitoring!
Appman.Link to this post:
It’s been about 12 years since I last scripted in PHP. I pretty much paid my way through college building PHP websites for small companies that wanted a web presence. Back then PHP was the perfect choice, because nearly all the internet service providers had PHP support for free if you registered domain names with them. Java and .NET wasn’t an option for a poor smelly student like me, so I just wrote standard HTML with embedded scriplets of PHP code and bingo–I had dynamic web pages.
Today, 244 million websites run on PHP which is almost 75% of the web. That’s a pretty scary statistic. If only I’d kept coding PHP back when I was 21, I’d be a billionaire by now! PHP is a pretty good example of how open-source technology can go viral and infect millions of developers and organizations world-wide.