This page outlines key guidelines for designing efficient and manageable resource nodes within OpsRamp service maps. A Service Map resource node shows the availability status of a collection of resources that are part of a business service. When configuring these nodes, prioritize the aggregation of resources by type or function.

It is strongly recommended to group resources of similar type or function into a single resource node.

Example: Consolidate all MySQL resources supporting the “Acme Web Application” under a single “MySQL” node, regardless of instance count.

Benefits of this approach:

  • Easier to define a single availability rule for all similar resources (e.g., all MySQL resources).
  • New matching resources are automatically added to the node.
  • Non-matching resources are automatically removed from the node.
  • This principle applies to other resource types (e.g., Cassandra).
  • Enables efficient Service Map scaling.
  • Results in faster service Map loading.
  • Facilitates easier Service Map management and updates.

It is strongly recommended to link existing Service Maps to a new one when you need to utilize the same. This approach expands the use of existing Service Maps, eliminating the need to create new ones from scratch.

Example: If you’re creating a new Service Map called “Acme Portal” and want to reuse the structure of an existing Service Map, such as “acme-web-application,” you can simply link the “acme-web-application” Service Map instead of building the “Acme Portal” Service Map from scratch.

Benefits of this approach:

  • Saves time by eliminating the need to create a Service Map from scratch.
  • Overall, the Service Maps availability loads faster as it refers to the Service Map instead of re-calculating the availability for a similar Service Map.