Foglight is an application management solution that provides a correlated, 360 degree view of your applications from end user to database and from service levels to infrastructure. Foglight combines transactional data with infrastructure metrics to help identify performance bottlenecks impacting your business and fix them quickly. Mentioned below is a conversation on Foglight via email with Brad Micklea, Director of Product Management for Quest’s Application Management business and Hugh McEvoy, Manager of Product Management for Foglight’s applications offerings and thanks to Krystal Jones AR/PR Specialist, Application Management of Quest Software, for facilitating the email conversation.
1. Question: Where do you classify Foglight solution to fall in, Application Performance Management (APM) or Business Transaction Management (BTM)?
Answer: Currently Foglight’s features fall primarily within the APM space, however, we believe that in the next three to five years any viable APM solution will have to include a strong BTM solution. We feel we are standing on an unusually strong foundation here as we already have deep transactional analysis abilities within our end user, Java, .NET and database solutions. We are developing transaction analysis and tracing capabilities that will connect these together and join them with our application and services focus to create what we believe will be among the pre-eminent BTM solutions in the market.
2. Question: From a high level architectural perspective, what components make Foglight?
Answer: It depends, but in general there are agents. A few places where there aren’t agents: monitoring of real end-user transactions, some database monitoring (which we can do in both an agented and agent-less way). Additionally, we can integrate with many other, non-Quest agents to pull in performance data without requiring new agents to be installed. In addition to the agents, there is the management server, where data is stored, analyzed, correlated and visualized (via a rich-experience, web front-end).
3. Question: Can you elaborate on why one would need integrations between Foglight and Spotlight, QuestCentral and Performasure among other Quest products?
Answer: Foglight is used for 24×7 performance monitoring & diagnostics. Spotlight & Performance Analysis are more specific diagnostic tools for databases, so there are cases where a Foglight alert, for example, would lead a DBA to open up Performance Analysis to see the cause of the issue. Quest Central is a database administration toolset which is used extensively by production DBAs. Integration between Quest Central and Foglight is centered on the workflow for detecting problems (Foglight) and resolving them (Quest Central). In these cases, integration between the products makes the workflow easier. JProbe is a Java profiler for pre-production use. PerformaSure overlaps technically with Foglight, but PerformaSure is optimized for pre-production use cases whereas Foglight is optimized for production use cases.
4. Question: What are the top five diagnostic features provided by Foglight? that can help an ops team to diagnose and resolve performance problems quickly.
Answer: This is a really big question and probably deserves a conversation. However the short answer is that it depends who the audience is. For example, Foglight is used by apps administrators, IT Ops, NOC users (if those are different) and business application owners. All of them use it in different ways. It also depends whether the customer puts Foglight in across their entire infrastructure or whether they go for only a part of the solution (e.g. particular application servers, particular databases etc). But for performance diagnostics & resolution, and without being application specific, the most commonly used features are probably:
The ability to see all issues (whether end-user, apps, db, infrastructure) within the context of the application. So rather than being an asset-based solution, Foglight is a service-based solution.
The ability to see detailed information about the health of the system, presented in ways which are specific to the Correlation of performance information across multiple tiers
Flexible, role-based visualization by role (e.g. a business owner might see only KPIs while an apps admin might see everything).
Long-term data retention & analysis i.e. how much slower is the system today than last week/month/year.
The ability to roll up performance information in many different ways to show attainment against a whole variety of SLAs.
5. Question: How can Foglight help pinpoint the root cause of a problem? such as a memory leak caused by a data structure in the application or an expensive SQL due to missing index on a DB table.
Answer: The precise mechanism is different in the two cases you mention. However, the principle is the same: we collect data on both the infrastructure resource consumption (memory, disk, thread pools…) and on the transactions flowing through the system. We then analyze that data. To give a couple of specific examples: in the case of Java we can show you how often a particular Java call is made, who has called it and how long it’s taking. That information, when tracked across time, can show you where problems are. In the case of the database, we specifically look at how long SQL takes to execute and whether adding an index would help. We could give similar, specific, examples across any of the technology stacks that Foglight can manage. Note that our approach here covers areas unaddressed by most BTM vendors (many of whom focus on transactional performance at the expense of resource-based issues) and also unaddressed by solutions such as pure end-user based monitors (whether passive or active).
6. Question: Does Foglight support performance management of an application developed on PHP or Ruby/RoR, Scala/Lift technologies using MySQL DB?
Answer: We have no out-of-the-box collectors for PHP or RoR, however, most of our customers have used our consulting services to build custom agents for technologies which are important to them but are uncommon. We developed Foglight with an eye to this by creating agent and data management APIs which make building a custom agent easy provided you can get access to the data you want Foglight to measure.
7. Question: How is Foglight different from Customer Experience Monitoring (CEM)? Example tools in this CEM category include Coradiant, Tealeaf among others. Would you advise companies using Foglight are better off than using CEM tools for performance monitoring? Can you provide some example scenarios supporting this claim?
Answer: Foglight includes, but is not limited to CEM. So we compete with all the products you mention above. There are two main differences (at a high-level) between us and them.
Firstly, those products look at transactional traffic between the end-users and the web servers. So they can say “this is slow at the front end” or “this is slow at the back-end”. For the front-end, our functionality is essentially equivalent: 24×7 performance monitoring plus transaction playback. For the back-end, none of those systems look into the technical stacks in the actual application, so they simply can’t tell you *why* it’s slow. We can be specific about why it’s slow, by looking at the back end. For example: the reason your end-users are experiencing slowdown is because their transactions are exercising an EJB which is experiencing resource contention across its database connection pool.
Secondly, we not only have CEM but also synthetics (the latter for both thin and thick client applications). In our experience we find that our combination of real and synthetic performance and session analysis capabilities are necessary to understand what performance is, generate performance baselines and also understand whether the users themselves are using the application in the optimal way.
Finally, note that, compared with e.g. HP, Foglight is a completely integrated solution. HP (and others) have amassed a set of acquisitions which aren’t really integrated. So the effort and time required to find and fix problems will be greater with their solutions. We’ve also seen that, for some of those vendors, the need for them to integrate using services what is OOTB with Foglight makes their implementations disproportionately expensive compared to ours.
8. Question: Does Foglight support transaction monitoring across protocols? i.e. an ability to identify Web traffic vs. IM Sessions, VOIP calls among others.
Answer: We currently focus mostly on HTTP(S) but we’re looking at extending that.
9. Question: What does it take or how do you create the grouping of all transactions and displaying them per business function? Is this done programmatically? If yes, what languages are used for such implementations?
Answer: We provide a rich web 2.0 client for all administration and operation. Additionally, you can choose to exercise APIs to achieve things like service definition. The main language for that is Groovy: we find that it’s a powerful and intuitive scripting language for people who are OO-literate.
10. Question: Where is the SLA information retrieved from? Is it from a CMDB? If yes, does Foglight have an embedded CMDB or do you integrate with other CMDBs? Can you provide some example CMDB’s that you integrate with or support?
Answer: Foglight is not a CMDB, our goal is to integrate with a wide range of CMDBs to give customers the option of choosing the CMDB that works for their organization without the need to compromise on service management as a side effect. To this end we are building out an integration mechanism targeted at the new CMDBf standard. We believe this will provide our customers with the greatest degree of freedom in choosing their CMDB. SLA information can therefore be built out simply within Foglight alone (for organizations looking to create primarily performance and availability-based SLAs); can be built in Foglight to leverage configuration data from a 3rd party CMDB or external store. In the event that a customer has already invested in an SLA management system that they feel is right for them, Foglight’s data and alerts can also be pushed to that system to add further strength to existing or new SLAs.
Other articles of possible interest:
Top five Java application performance management tools
How to size a JVM
Top six performance tuning tips for a Java enterprise application
Keynote and SOASTA, cloud offerings to test your web site performance
To scale out or not using Gigaspaces
Three tools to monitor your Websphere MQ environment
