Connector load

How much weight is each connector group actually pulling? This report puts the answer in one row per connector group, sorted by segment count descending so the heavy ones show up first.

Endpoint

GET /api/v1/analytics/connector-load

Returns

type ConnectorLoadEntry struct {
    ConnectorGroupID   string
    ConnectorGroupName string
    PolicyCount        int  // distinct policies referencing this connector group
    SegmentGroupCount  int  // distinct segment groups touched by those policies
    SegmentCount       int  // distinct segments touched by those policies
    ScimGroupCount     int  // distinct SCIM groups granted access through those policies
}

How

For each connector group:

1. Get the list of policies via ConnectorGroupToPolicies.
2. For each policy, accumulate its segments (via the policy’s segment scope) and SCIM groups (via PolicyToScimGroups).
3. Count distinct entries in each set.

Use it for

• Capacity planning. A connector group serving 50 segments and 30 SCIM groups is more critical than one serving two of each. Plan upgrades and redundancy accordingly.
• Underused connectors. A connector group with PolicyCount = 0 is not serving any access policy. Possibly: someone forgot to bind it, it is on standby, or it can be retired.
• Combined with blast radius. The load view tells you which connector groups are biggest. Blast radius tells you exactly who notices when one fails.

Caveats

• “Load” here is structural, not runtime. ZPA does not give us per-rule hit counts. A connector group can have 200 policies attached and serve zero actual traffic. To get the runtime view you need the BI / OneAPI endpoint, which PainScaler does not yet integrate.
• A policy that targets a segment group is counted as touching every segment in that group, not just the ones with active server groups bound. This is the right answer for “who is theoretically affected”.