Auto-Onboard: Batch-Creating Collection Points with Collection Zones + Collection Rules
Overview
Spiral Discovery solves the problem of "expanding topology layer by layer from a single known entry point" (vCenter / k8s / a switch). But often your starting point is more basic — a network segment where you don't know what's inside: a new data center just went live, you inherited an unfamiliar network, or you need to onboard an entire office subnet. You don't have an existing vCenter or core switch as an entry point — just an IP range.
This is where you take a different path: Collection Zones + Collection Rules. The collection zone handles "finding the live devices within this network segment," and the collection rule handles "automatically turning discovered devices into fully configured collection points." Together, a batch of unknown devices can be onboarded automatically and in bulk — no manual entry required.
Give a data center subnet 192.168.10.1-254, configure "how to probe" and "what to do automatically after probing," and within minutes every online device in that subnet automatically becomes a collection point — with templates attached, groups assigned, and data flowing.
Prerequisite Reading
- Discovery & Collection Overview
- Collection Zones — "Where to find devices"
- Collection Rules — "What to do automatically after finding a device"
- Collection Points — the result produced by auto-onboard
- Collection Templates — the most commonly associated "operation" object in rules
Two Roles: Inspector + Dispatcher
The key to understanding this pipeline is distinguishing two roles with separate responsibilities that connect sequentially:
| Role | Corresponding Feature | Question It Answers | What It Does |
|---|---|---|---|
| Inspector | Collection Zone | "Where to look, how to probe, how often" | Periodically probes the IP range using protocols (ICMP / SNMP / TCP) to find live devices |
| Dispatcher | Collection Rule | "What to do automatically after finding them" | Evaluates conditions against discovered devices and, on match, executes a set of actions (create collection point, attach template, assign group, enable...) |
The collection zone is only responsible for discovery ("this device is alive and has SNMP open"). It does not create collection points. What actually turns a "barely discovered device" into a "managed collection point" is the collection rule. So the two must be used together: a zone without rules means devices are discovered as "bare data" — they never enter CMDB and never get collected.
Walkthrough: Bulk Onboarding a New Data Center
Goal: Automatically onboard every online device in the new data center subnet 192.168.10.1-254.
Step 1: Create a Collection Zone ("How to Probe")
Create a new entry in Collection Zones:
| Field | What to Fill In | Notes |
|---|---|---|
| Name | e.g., "Data Center A Subnet" | For identification |
| IP Range | 192.168.10.1-254 | The subnet to scan |
| Collection Proxy | If the data center is an isolated network, select a proxy already deployed inside the data center; leave empty if the platform can reach it directly | Required for isolated networks — otherwise nothing will be scanned |
| Check Interval | e.g., 1 hour | The scanning cadence |
| Collection Interfaces | First add ICMP (liveness check); to identify network devices also add SNMP (port 161, fill in the community string) | Multiple protocols can be stacked |
After saving and enabling, the system begins periodically scanning this subnet at the configured interval.
Step 2: Create a Collection Rule ("What to Do After Probing")
Create a new entry in Collection Rules to chain "discovery → onboard":
Conditions (define which devices get processed):
| Condition | Example |
|---|---|
| Collection Zone | = "Data Center A Subnet" (only process devices discovered by this zone) |
| Collection Protocol | = SNMP (optional — only onboard SNMP-enabled network devices) |
| Host IP | (Optional) only onboard a specific sub-range |
Actions (executed automatically on match):
| Action | Purpose |
|---|---|
| Add Collection Point | Creates the device as a managed collection point (the key onboarding action) |
| Associate Template | Automatically applies a Collection Template, e.g., "General Network" |
| Add to Collection Group | Assigns to a specified group, e.g., "Network Devices" |
| Enable Collection Point | Immediately begins collection |
| Add Collection Point Tags | (Optional) Apply tags like env:room-a |
The most practical onboarding rule only needs: Condition = "discovered by a specific collection zone," Actions = "Add Collection Point + Associate Template + Add to Collection Group." After these three steps, a new device automatically becomes a fully configured collection point that starts producing data.
Step 3: Enable and Observe
After enabling the collection zone and collection rule, wait one scan cycle:
- The collection zone discovers live devices → triggers the collection rule evaluation.
- Devices matching the conditions are automatically created as collection points, with templates attached and groups assigned.
- Go to the Collection Points list to view the newly generated batch of collection points and confirm they have templates associated and are in enabled status.
UI Configuration Essentials
Collection Zone Side
| Configuration | Required | Description |
|---|---|---|
| IP Range | Yes | Supports range notation (e.g., 10.0.0.1-100) |
| Collection Proxy | Yes | When the platform cannot reach the network directly, a proxy already deployed within that network must be specified |
| Check Interval | Yes | Scanning cadence |
| Collection Interface Protocols | Yes | ICMP for liveness / SNMP for identifying network devices / TCP for probing specific ports |
| Scan Probe Credentials (e.g., SNMP community string) | Required when using SNMP probing | Configured alongside the SNMP protocol in the collection interface; used only for identifying devices during scanning — this is not the same as the long-term credentials of the created collection point (the latter is described in Collection Rule Side below) |
Collection Rule Side
| Configuration | Required | Description |
|---|---|---|
| Conditions | At least one | Typically starts with "discovered by a specific collection zone"; can add protocol / IP / port filters |
| Add Collection Point | Required for onboarding | Without this action, devices will not be created as collection points |
| Associate Template | Strongly recommended | A collection point without a template has no collection strategy — it's an empty shell |
| Credentials (Action Macros) | Required when the template needs them | When associating a template, fill the template's declared credential macros (e.g., {$SNMP_COMMUNITY}) in the action; auto-created collection points inherit them |
| Add to Collection Group / Enable | Recommended | Grouping enables bulk management; enabling lets it start collecting immediately |
Where Do Credentials Go?
In the Collection Zone + Collection Rule pipeline, credentials are split across two locations — don't mix them up:
| Credential Purpose | Where to Configure | Example |
|---|---|---|
| Identifying devices during scanning (lets the inspector read device info) | The Collection Zone's collection interface (configured alongside the probe protocol) | SNMP community string, used during scanning to read sysName and identify network devices |
| Long-term collection credentials for created collection points | In the Collection Rule's actions (fill credential macros when associating a template) | When associating the "Network Discovery by SNMP" template, fill {$SNMP_COMMUNITY} in the action; every auto-created collection point inherits it |
The key point: credentials for auto-created collection points are configured in the collection rule — the "associate template" action lists the template's declared macros, and you fill in the values there. Each time the rule creates a collection point, it carries the credentials along. Compared to writing credentials into the template, this approach lets one template be safely reused across different subnets / different community strings without credentials spreading with the template.
Both approaches "auto-create collection points," but the credential location differs based on the creation mechanism:
- Collection Zone + Collection Rule (this guide): collection points are created by the collection rule → credentials go in the collection rule's actions.
- Spiral Discovery (companion guide): collection points are created by host prototypes in the template → credentials go on the host prototype. Both scenarios follow the same principle: credential values are never written into templates; templates only declare which macros they need.
Difference From and Combination With Spiral Discovery
These two approaches to auto-creating collection points start from different origins, suit different scenarios, and can also be used in combination:
| Spiral Discovery | Collection Zone + Collection Rule | |
|---|---|---|
| Starting point | A structured entry point (vCenter / k8s cluster / an SNMP switch) | A network segment (unknown what's inside) |
| How it discovers | Platform API / hypervisor / neighbor protocols (CDP/LLDP) | Network scanning (ICMP / SNMP / TCP port) |
| What it discovers | Complete topology + child objects (VMs / nodes / neighbors) | The live devices themselves ("this IP is alive, these ports are open") |
| How collection points are created | Collection Point Discovery Rules + Host Prototypes in the template | The "Add Collection Point" action in a collection rule |
| Best suited for | Deep expansion of virtualization / container / network topologies | Bulk survey onboarding of new data centers and unfamiliar subnets |
Combination play: First use a Collection Zone + Collection Rule to scan a network segment and bulk-onboard the first batch of collection points. If a core switch or a vCenter is discovered among them, associate a by API template to that device and let Spiral Discovery expand deeper from it — sweeping broadly and digging deep, both approaches working in tandem.
Troubleshooting
- Collection Zone discovers no devices: Check three things first — ① Is the Collection Proxy correct (isolated networks must specify a proxy)? ② Is the IP Range written correctly? ③ Are the probe protocol and port correct (SNMP requires the device to actually have port 161 open with the correct community string; TCP requires the port to actually be open)?
- Devices are discovered but the collection rule doesn't match: The conditions are too restrictive. First verify the rule can trigger with the broadest condition (only "Collection Zone = X"), then tighten gradually.
- Rule matches but no collection points are generated: Check whether the actions include "Add Collection Point" — this is the essential onboarding action. Without it, devices remain in the "discovered" state only.
- Collection points are generated but have no data: Most likely no template is associated or the template is not enabled. Add "Associate Template" in the collection rule, or confirm that the associated template itself is in enabled status.
Summary
Collection Zone + Collection Rule is the standard approach for "batch auto-creating collection points from a network segment":
- The Collection Zone handles "where to look and how to probe" — periodically scanning to find live devices.
- The Collection Rule handles "what to do after finding them" — automatically creating collection points, attaching templates, assigning groups, and enabling them when conditions match.
Keep the "Inspector + Dispatcher" division of labor in mind, and bulk onboarding of new data centers and subnets runs entirely on autopilot.