|
Home > Best Practices > Pre-Discovery Best Practices
Pre-Discovery Best Practices
 Spending extra planning time in pre-discovery with IBM® Tivoli® Application Dependency Discovery Manager (TADDM) almost always pays off in a significant reduction in the number of repeated errors that would otherwise come up in a blind discovery. Extending the planning phase also allows time for developing and testing custom sensors before putting them into play in a full-scale discovery.
The first step in pre-discovery is to identify the business services from a network perspective. To do this, create an overlay of IP address assignments listing the related business service, and then build a discovery scope. This allows the discovery to go forward in phases, reducing the time and overload that accumulate with a comprehensive network-discovery. For example, if a change is suspected within a specific business area, limiting the discovery to that area until it is identified will save valuable time. LSOF errors often occur on a first-run of discovery because each Linux® or UNIX® system is uniquely configured, causing the LSOF command to fail. One way to avoid this is to test whether LSOF is working on all machines before pushing it out across the environment.
Another best practice is to determine in advance what applications are running in the IT environment, and then developing custom sensors to discover the applications for which there are no out-of-the-box sensors. To configure these custom sensors, it is necessary to run "test discoveries" where the application is running and fine-tuning the response. Again, this limits the discovery errors to the initial run and smoothes the full-scale discovery.
| 
Application Dependency Discovery Manager