| OVERVIEW |
|
|
| DOCUMENTATION |
|
| RESOURCES |
|
|
|
| InfraRED Roadmap |
- Ability to configure InfraRED properties dynamically using JMX.
- Provide persistence of performance data in database.
- Provide ability to capture statistics for business transactions serviced by the application. This would involve providing a capability to define a business
transaction
in InfraRED. Based on this definition, the statistics would be captured and reported.
- Update documentation:
- Usage of Request Filters: Explain how it can be leveraged for getting useful information.
- Fetch Statistics: Explain the information provided by this section in detail and how is it relevant.
- Track remote calls across VMs and provide an end-to-end call sequence (spanning remote calls).
- JDBC: Time taken to get a connection from the pool (this will identify issues with connection pool configuration).
- JMX support (expose InfraRED statistics via JMX).
- Self-tuning Instrumenter
- How to automatically figure out what and how much to instrument?
- Measure and report the actual overhead.
- Allow applications to set a certain upper-limit for the overhead and adapt the data gathering to that overhead.
- Trend analysis - pick a few metrics and a time-frame and plot the value of those metrics over that timeframe.
- Integration with other metrics
- Metrics collected by application servers
- Metrics collected by JVM
- JDK 1.5 has a Monitoring API
- JRockit has several monitoring features
- Network performance.
- Database metrics.
- Show how much memory InfraRED takes. Control how much memory InfraRED takes - for example, we can allow specification of maximum memory for IR.
- Link top n SQL queries to their execution path. i.e. from the JDBC summary page where we list the top 'n' queries, we should make the queries clickable and take it to a page that shows the reverse call tree of where this query was made from.
- JMX notifications if certain queries and APIs take more than a certain time. Notifications can be both for individual API execution times as well for averages.
- If an API/query takes more than a certain time, we can auto-trigger gathering more statistics for that API (such as getting call-trees) so that it's easy to debug the problem.
- Report total number of calls into each layer. This will help in seeing if load balancing is happening correctly.
- Add a feature to show statistics for a list of servers one below the other. (Right now, we aggregate stats for a set of servers or we can see the stats for one server at a time, but we would like to select a set of servers and see stats for each server one after another).
- Reporting capability on components that are throwing the most number of exceptions.
- Correlation with weblogic metrics (Number of EJB activation/passivation, pool sizes etc.) and integrate and correlate these stats with InfraRED.
- Integration with Cactus/ JUnit tests and report failures - i.e. report on APIs taking more than certain time and dump call trees for those APIs. Provide an API to get the data and call trees as well.
|
| |
|
