Top-down discovery schedules

  • Release version: Xanadu
  • Updated August 1, 2024
  • 4 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Top-down discovery schedules

    Top-down discovery schedules in Service Mapping automate the regular rediscovery and updating of application service maps by scanning all configuration items (CIs) involved in application services. After the initial map creation, these schedules keep the maps current by periodically rediscovering the relevant CIs.

    Show full answer Show less

    By default, Service Mapping includes preconfigured schedules for rediscovering all application CIs and load balancer services once daily, which typically suffices for most organizations.

    Custom Discovery Schedules

    ServiceNow customers can create custom top-down discovery schedules to meet specific operational needs, such as more frequent rediscovery of critical or frequently changing services. Custom schedules can be configured based on the following criteria:

    • Services: Rediscover all CIs belonging to services that meet defined filters, such as business criticality or operational state. This is useful for prioritizing critical or rapidly changing services.
    • Services belonging to a group: Target services assigned to specific organizational groups, enabling geographic or departmental rediscovery schedules. Note that only services directly inside the specified group are discovered, excluding embedded subgroups.
    • CI types: Discover all application CIs of specific application types. This helps manage discovery load by tailoring schedules to the update frequency of particular CI types. More specific schedules for child CI types take precedence over parent type schedules.
    • Specific CIs: Rediscover a single specified CI. This is ideal for handling individual CIs that require special attention or cause frequent discovery errors. Schedules for specific CIs override those for their CI types.

    Host Discovery Integration

    During top-down discovery, Service Mapping verifies the presence of hosting devices for application CIs in the CMDB. If a host or load balancing device is missing, it triggers horizontal discovery to identify and update host information in the CMDB.

    Managing Discovery Schedules

    ServiceNow customers can manage schedules that trigger horizontal discovery as well as serverless discovery methods, allowing flexibility in how CIs are discovered across different protocols and infrastructure setups.

    Practical Implications for Customers

    • Leverage the default daily schedules for broad application and load balancer updates.
    • Create targeted custom schedules to optimize discovery frequency for critical, frequently changing, or geographically specific services.
    • Use specific CI schedules to troubleshoot problematic CIs without impacting broader discovery processes.
    • Ensure host devices are accurately discovered and maintained in the CMDB through integrated horizontal discovery triggers.
    • Adjust schedules to balance discovery load and maintain up-to-date application service maps, supporting operational accuracy and service reliability.

    Learn about schedules that trigger top-down discovery of application services.

    When you define a new application service, Service Mapping performs discovery of all CIs that participate in this application service and creates its map. After the initial mapping is complete, Service Mapping regenerates application service maps regularly by rediscovering the CIs making up an application service.

    By default, Service Mapping is preconfigured with these generic schedules:
    All Applications
    This schedule triggers the top-down discovery of all CIs of the application type [cmdb_ci_appl].
    Load Balancer Service
    This schedule starts the top-down discovery of all CIs of the load balancer service type [cmdb_ci_lb_service].
    The generic schedules trigger discovery of all applications and load balancer services in your organization once a day. Typically, these preconfigured schedules are enough to update information for application services. However, if it is necessary to discover specific CIs or services more frequently, you can create the following custom discovery schedules:
    Table 1. Schedule types for top-down discovery
    Schedule type Description Example
    Services Service Mapping discovers all CIs belonging to certain services that answer filtering criteria. In your organization, some application services are more critical than others and it is important for you to rediscover such services with high criticality more frequently. Create a custom discovery schedule to discover all services with the business criticality value set to most critical.

    Alternatively, certain services in your organization are undergoing changes more often than once a day. You may want to create custom schedules to rediscover such services more frequently.

    You can also create a schedule of this type to discover application services in a sub-production instance, where services are not in the operational state yet.

    Services belonging to a group Service Mapping discovers all CIs belonging to services assigned to groups that answer filtering criteria.

    Service Mapping discovers only services located directly inside the group that answers defined filtering criteria. Service Mapping does not discover services inside embedded groups.

    Notice that you can define schedules based on service groups, even if your role does not have access to these service groups.

    In a distributed organization with offices in several geographic locations, you may want to create a custom discovery schedule to rediscover services in one of these locations. For example, one schedule can trigger rediscovery of all services relevant for the EMEA site at 7am GMT, while another schedule can start rediscovery of services for the US headquarters at 7am PT.
    For CI types Service Mapping discovers all application CIs belonging to this application type. Some application CI types are prone to more frequent changes and updates than others, so you can manage the load by adjusting the discovery schedule to match the nature of each CI type.

    When you define discovery schedules based on application CI types, several schedules may apply to the same CI. To avoid discovering the same CIs more than once, the most specific schedule always has precedence. For example, if you create separate discovery schedules for a parent CI type and its child CI type, CIs belonging to the child CI type are discovered using its dedicated schedule. At the same time, if there is no schedule for a child CI type, the parent CI type schedule is used to discover the child CIs.

    This schedule discovers only CIs belonging to application services in the operational state.

    If you modify a certain application more often than the rest of your applications, you may want to discover it more frequently than other CIs. In that case, create a custom discovery schedule for such an application CI type.
    Specific CIs Service Mapping discovers only one CI that you specified for this schedule.

    If you define a discovery schedule for a specific CI as well as a schedule for the CI type to which this CI belongs, Service Mapping uses the schedule for this specific CI, and not the generic schedule for its CI type.

    This schedule discovers only CIs belonging to application services in the operational state.

    For rare cases of rediscovering a specific CI that causes discovery errors frequently.
    Part of discovering an application CI is identifying its host. Service Mapping checks if the device hosting this application CI exists in the CMDB. For a load balancer service, Service Mapping checks if the load balancing device hosting this load balancer service exists in the CMDB. If not, Service Mapping triggers Discovery to perform the horizontal discovery. As a result, Discovery performs host detection and updates the information on hosts in the CMDB. If necessary, you can manage the schedules that trigger horizontal discovery as described in: