Archive for May, 2010
Nagios Support and More!
Wednesday, May 26th, 2010
At AppFirst, we move quickly to incorporate your feedback and deliver, so we release into production every Wednesday. This week, we’re pushing some very exciting and significant new features into production, and we want to share them with you:
1) Nagios support — we now integrate with Nagios on Linux!
- If you have Nagios Client scripts running on your servers, the AppFirst collector will automatically pick up the output of the scripts (given you have everything running in the default directory). Then the collector will send the output message to our backend, so you can visualize messages on the AppFirst Dashboard and alerts on AppFirst Alert Management.
- If you are using the Nagios Server, there is no need to continue doing so. You now have one consolidated view of your infrastructure that includes your Nagios scripts.
- If your Nagios Client installation is not in the default directory, you can specify the correct location by editing the collector(s) that are affected. In the future, should you decide to install new Nagios Client scripts, AppFirst will automatically detect them, incorporate the messages on AppFirst Dashboard, and create new alerts.
- In addition, it will no longer be necessary to install the out-of-box Nagios Client scripts on new servers, because AppFirst will collect the information for you. This new feature in AppFirst will save you the cost of a server and days of time installing and configuring the Nagios Server.
2) Automatic attachment to running processes
- When you install new collectors, you no longer have to restart processes or reboot your machine in order for the AppFirst collector to start “seeing” your application as it executes. If you already have collectors installed, you will have to reinstall the new version. To do so:
Redhat/CentOS
- First remove collector from the host
$ sudo yum remove appfirst
- Download/Install the latest rpm package
$ sudo rpm -ihv http://wwws.appfirst.com/packages/initial/1/appfirst-i386.rpm 32 bit version
$ sudo rpm -ihv http://wwws.appfirst.com/packages/initial/1/appfirst-x86_64.rpm 64 bit version
Ubuntu
- First remove collector from the host
$ sudo apt-get remove appfirst
- Download the latest deb package
$ sudo wget http://wwws.appfirst.com/packages/initial/1/appfirst-x86_64.deb 64 bit version
$ sudo wget http://wwws.appfirst.com/packages/initial/1/appfirst-i386.deb 32 bit version
- Install the newly downloaded package
$ sudo dpkg -i appfirst-x86_64.deb // 64bit
$ sudo dpkg -i appfirst-i386.deb // 32bit
Windows
- First remove collector from the host – Control Panel – Add/Remove programs – Uninstall AppFirst program
- From AppFirst console administation -> collectors -> instructions select the appropriate Windows version
- Install the downloaded collector
3) Renaming Tags
- We’ve heard from you that the term “Tags” is confusing. We have now renamed Tags to Applications. Applications are entities you create by logically grouping processes together, whether they run on one or more servers. These groupings represent the way you think about your infrastructure (ex. your database, job messaging system, shopping cart, etc….)
- To learn more, check out our new Applications page and demo videos on www.appfirst.com!
4) Significant changes to the Alert Management system
- You can now set alerts on processes, applications and servers.
- We have also added new types of alerts for processes and applications based on incident reports, files, registry and ports accessed. With these new powerful alerts, you can be alerted when certain strings are identified in incident reports, and user-specified files, registry or ports are accessed.
- If you are using Nagios on Linux, AppFirst now automatically creates alerts for every Nagios script you have enabled. These are displayed on AppFirst Alert Management where you can edit or delete them.
As always, we very much appreciate your support and feedback. Please keep it coming!
Posted in Company News, Product Information | No Comments »
Down Time
Monday, May 17th, 2010
AppFirst was down for approximately 10 minutes today. Our tenant database encountered performance issues. They were severe enough to cause requests to time out between the back end and front end. Please note we don’t manage data streamed from your servers in a database, we use flat files. The database is used to manage tenant details as well as state information for remote collectors.
Our monitoring showed us that response times between the front end and client browsers was slowing quickly. We followed the response times to the connection between database and front end. A detailed look at the database application using Data Insight showed that the aggregate of the four Postgres processes were using a lot more memory than was normal. We also saw that page faults for the four Postgres processes were high and growing.
A look at the database made it clear we needed to vacuum it. We had vacuumed the database three months ago and at that time enabled auto vacuum. It’s clear we need to understand exactly what auto vacuum is enabling.
We apologize for any inconvenience this outage may have caused.
Posted in Company News | No Comments »
The Value of Real Data
Thursday, May 13th, 2010
For better or worse, I’m a baseball fan. It’s something I grew up with. My grandparents were devout Detroit Tigers fans. Some of my fondest memories are of listening to the game on the radio with grandparents and extended family.
One of the talking points in baseball circles these days is the pace of the game. It was a recent topic when the Red Sox and Yankees took nearly 5 hours to play a game last month. There are a few generally accepted reasons why some of the games take longer than others. Most people passionately describe the time consumed when the catcher goes to the mound to talk to the pitcher and the amount of time consumed by the pitcher between pitches. In fact, MLB has instituted new rules this year that are supposed to govern some of these times.
A funny thing happened recently in the midst of all of this discussion. A baseball writer (Didn’t write down his name…) sat down with video of several notoriously long games and measured times. He used a stop watch to measure the amount of time taken for each individual activity. With absolute times in hand, he was able to clearly tell precisely where time was consumed. The activities that took most of the time were not those generally accepted to be the culprits. It turned out, for example, that Derek Jeter stepping out of the batter’s box and walking around between pitches consumed a lot more time than any of the pitchers or visits to the mound by a catcher.
Why bore you with all the baseball reference? It’s an example from my personal frame of reference that illustrates an aspect of the human condition that affects the management of IT infrastructure. It’s really easy to accept that something is factual when one or more individuals speak with passion that it is so. That system is slow because the java app is using too much memory, or it’s slow because the database is over extended. It’s all too easy to accept. I’ve done it. We had a recent performance issue with our back-end servers. Our entire development team, myself included, was convinced that the issue stemmed from the aggregation of data. We all just accepted that as reality because it made a lot of sense. It was logical. However, when we looked at the visualization of the applications on our infrastructure, it was very clear very quickly that we were all wrong. Data aggregation was really consuming less than 5% of CPU resources. It was the act of responding to API requests that were consuming up to 30% of CPU.
The point is; get the facts. Easier said than done, I know. You don’t have access to the real facts if you are looking at server resources alone – they are insufficient to see the detail you need. Transaction times alone aren’t going to fully inform. All of the copious information that you can get from individual components is a patchwork of data, much of it contradictory. The information from byte code insertion tools is detailed, but it doesn’t help much with management of your application infrastructure. Maybe if you wrote much of the code yourself, you can get what you need. Either way, it’s like real work to get what you need.
What you need is a consistent view of the apps running on your infrastructure. A view that is the same for all apps; web server, app server, database, Java, .Net, Ruby, PHP…well, you get the idea. If you are managing infrastructure, do you care which line of code is calling a SQL statement? Do you care if you’re dealing with Java or Ruby? You do care about the performance profile, about what resources the apps require, about bottlenecks. So, why not look at what matters to you?
Give it a try – it’s easy and not at all scary: http://appfirst.com/sandbox/
Tags: Donn
Posted in Company News | No Comments »
IT Operations has spoken and AppFirst is listening!
Monday, May 10th, 2010
I hear you loud and clear! You spend all of your time putting out fires and, with the big gap in monitoring tools, you’ll never get out of that mode.
It’s time to do better than “your father’s monitoring products”. System monitors only tell you the health of the physical or virtual box (with no insight to what’s inside). Application-specific probes and agents don’t paint a complete n-tier application picture. Byte-code analysis doesn’t see the entire application as it executes, and it focuses on finding code problems that lead to performance issues when, actually, the majority of IT Operations issues are due to non-code-specific changes in the infrastructure configuration or usage patterns. As you can see, there’s a huge gap of unaddressed monitoring needs for IT operations.
Until you can see your entire application stack as it executes in real time, you’ll still be settling for blind spots that lead to fire fighting and extended delays while you try to put out the fires.
With help and input from your IT peers, AppFirst has not only listened but has built the only Infrastructure Performance Management Solution that:
- Visualizes your entire application stack as it executes
- Captures the response times and detailed resource utilization profiles for every application
- Automatically and continuously discovers and maps the topology of every application
- Allows you to know with certainty what’s changing within your application and to use this insight to make smart infrastructure decisions to reduce performance issues and lower your costs
- Works across Windows, Linux, physical deployments, virtual deployments and cloud deployments
- Takes minutes to set up and provides instant value
What does all of this mean? AppFirst is delivering the industry’s first deterministic IT Infrastructure root cause analysis solution! By determining what has changed when slower than acceptable response times occur, we can provide IT with not only the complete view of the application stack, but also the depth to know in minutes all the information that has eluded IT without us.
Your time is valuable, your company’s cost of operations matters, and we are committed to your success in achieving your goals in these metrics.
Posted in Company News | No Comments »
