Differences Between Data Collectors and Information Points
Sometimes there is confusion between Data Collectors and Information Points because both enhance performance monitoring with information about data passed to an application and both must be explicitly configured. It is also possible to create data collectors and information points on the same method, but for different purposes.
A major difference between data collectors and information point metrics is that:
- Data collectors exist in the context of a business transaction
- Information points exist outside of business transactions
Data collectors exist only in the context of a business transaction. They add information to a business transaction snapshot, where they can highlight poor performance that may be associated with data passed in by the request. Data from data collectors appear in the panels of the transaction snapshot call drill down - HTTP PARAMS, COOKIES, or USER DATA - depending on the type of the data collector. Data collectors do not appear in the Metric Browser and cannot be used in health rules. You can filter transaction snapshots based on the value of a data collector in the transaction snapshot list or using the AppDynamics REST API.
Here are some use cases for data collectors:
- You want to identify which users are experiencing problems with a business transaction. Often the userid is carried in the request as an HTTP query string or in the cookie. Create a data collector on the userid so you can identify the users in transaction snapshots for slow transactions. You can then filter transaction snapshots for those specific user ids.
- You can identify a business context for slow transactions. Use a method invocation data collector to extract some business information, such as the country or the orderid, to better understand the execution context in which users are experiencing poor performance.
- You can identify a technical context for slow transactions. For example, you may suspect that a cache is performing poorly for a specific set of keys, so you create a data collector on the cache retrieve method. Then the transaction snapshots can help determine if there is correlation between the suspect keys and poor performance.
- You can take advantage of the ability to filter transaction snapshots on a data collector to tag snapshots. For example, create a data collector based on a header value or path pattern to tag transaction snapshots initiated by synthetic transactions.
Information points aggregate numeric data about invocations of a method outside the context of any business transaction. Use information points to get metrics about method invocations across multiple business transactions. Any time the method configured for the information point is invoked, no matter from where, the information point is triggered.
Information points are visible in the Metric Browser.
Here are some use cases for code metric information points:
- You can use a code metric information point to track the number of times a servlet is invoked when the servlet is not part of a business transaction.
- You have a slow XML parser used by many business transactions. Use an information point to report when the parser was called and how many lines it parsed.
- The development team is trying to optimize common application code used by many business transactions. Creating information points on the important methods can give them KPIs to assess the success of their optimization efforts.
- You can use two information points to track the number of concurrent users of an application, regardless of the business transaction. Create an information point on the login method, another on the logout method. The difference between them is the concurrent users logged into the application in the specified time range.
Here are some use cases for business metric information points:
- To report how many of a certain item were sold or returned.
- To find the average value of credit card totals.
Because information points are not tied to a particular business transaction, it is possible that an error that occurs in the context of a business transaction that happens to go through the information point will not be counted as an error on the information point itself. Only downstream exceptions that are unhandled by the end of the information point method or exceptions that are handled upstream of the method and logged as ERROR or FATAL are counted as errors in the context of the information point.