@dx-do/cli 5.2.49 → 5.2.50

package/dist-node/configuration-1vczsdex.md

@@ -0,0 +1,104 @@
+
+## Environment Variables
+
+#### Basic Environment Vars
+
+* **DXDO_CONFIGURATION** : String containing entire JSON configuration
+* **DXDO_LOG_LEVEL** : "debug" or "info"
+* **DXDO_NO_COLOR** : disable colors in output
+* **FORCE_COLOR** : if 0 disable colors in logging
+* **DXDO_DEBUG_ARGS** : shows provided args as understood by the parser
+* **ALLOW_INSECURE_HTTPS** : allows connections to on-premise DX with self-signed certs.
+
+#### Request Logging Environment Vars
+
+* **DXDO_LOG_REQUESTS** : any value, true if exists.
+* **DXDO_REQUEST_LOG_FILE** : location to log requests
+* **DXDO_POSTMAN_EXPORT** : if set, along with DXDO_LOG_REQUESTS, will export a complete postman export of all network transactions.
+* **DXDO_POSTMAN_DIR** : set to the location for postman exports of runs
+
+## Experimental commands
+
+Some `dx-do` commands are marked **experimental** — they're being designed, may change shape between releases, or are only safe to run on test tenants. They're hidden from `dx-do help commands` and refused at runtime by default. Open the gate either way:
+
+* **Per-invocation flag**: `dx-do --enable-experimental-commands <group> <command> ...`
+* **Env var**: `export DXDO_ENABLE_EXPERIMENTAL_COMMANDS=true`
+
+Both forms behave identically; pick whichever fits your workflow. The env var is the better choice when you need experimental commands repeatedly (CI, scripts, an MCP-server-spawn config in Claude Code / Cursor).
+
+To see which commands are experimental, run any of:
+
+* `DXDO_ENABLE_EXPERIMENTAL_COMMANDS=true dx-do help commands` — list with `[experimental]` tag.
+* The `README.md` shipped with the binary — generated with experimental commands always included; each is suffixed with `[experimental]`.
+
+When an MCP client (Claude Code, Cursor, mcp-inspector) spawns `dx-do` as a subprocess for a currently-experimental command (e.g. `agentic mcp`), set the env var in the spawn config so the gate is open for the child process. The bundled `investigate@dx-do` Claude Code plugin already does this in its `plugin.json`.
+
+## Configuration
+* dx-do loads its default configuration from ~/.dxdo/default.dxo2.config.json
+* If that doesn't exist, the first time you run dx-do, it will prompt you for values and write the configuration file.
+* You can have multiple config files for different tenants, and pass them using the '--config=<config file>' argument.
+* If your configuration file is in ~/.dxdo directory, you do not have to specify the directory' argument.
+* Also, dx-do assumes that the extension is .json and will add it if the file doesn't exist as specified.
+
+* ```'npx dx-do --config=my-config'``` will find a config in ```~/.dxdo/my-config.dxo2.config.json```
+
+## Proxy Configuration
+
+* dx-do relies on system proxy by default.
+* if a system proxy is enabled but not working, you can try setting
+  * `export GLOBAL_AGENT_HTTP_PROXY=true`
+* user can also provide a proxy configuration file on the command line
+  * 'npx dx-do --config=my-config --proxyConfig=my-proxy.json'
+
+###  Proxy configuration file format
+```text
+{
+    host: <proxy hostname>
+    port:  <proxy port>
+    auth: {
+       username: <username>
+       password: <password> 
+    }
+    protocol: <proxy http mode = "https" | "http">
+}
+
+```
+## Generating keys
+
+* [userToken]  Launchpad -> Settings -> + New Token -> User Token ...
+
+## optional configuration
+
+* userToken is now required, tenant token is not necessary.
+
+## current version 4 configuration file format
+
+```
+{
+  "configurationVersion": "3"
+  "cohortId": "<cohortUD from Settings -> Connector Parameters>",
+  "userToken": <DX User Token from Settings -> Manage Tokens -> New Token -> User>,
+  "dxGatewayHost": "https://apmgw.dxi-na1.saas.broadcom.com/",
+}
+```
+
+
+## now disabled version 3 configuration file format, please use "config upgrade" command.
+
+```
+{
+  "tenantCN": "<>",
+  "tenantId": "<>",
+  "tenantToken": <DX Tenant Token>,
+  "userToken": <DX User Token>,
+  "hostUrl": "https://apmgw.dxi-na1.saas.broadcom.com/",
+  "axaHostUrl": "https://axa.dxi-na1.saas.broadcom.com/",
+  "oiHostUrl": "https://oi.dxi-na1.saas.broadcom.com/",
+  "axaSessionHostUrl": "https://axaservices-es-exporter.dxi-na1.saas.broadcom.com/",
+  "dashboardHostUrl": "https://dxi-dashboard.dxi-na1.saas.broadcom.com/",
+  "configurationVersion": "3"
+}
+```
+
+
+

package/dist-node/dashboards-x0xddksy.md

@@ -0,0 +1,17 @@
+# dx-do dashboard quirks
+
+### Configuration
+
+dx-do dashboard commands require an API key that is not able to be generated from the UI. 
+
+In order to generate a dashboard api key, follow these steps:
+
+1. Open a modern browser as a DX admin
+2. Open browser developer tools and find any XHR request ("search").
+3. In the request headers, ensure that it has keys starting with CA_ and SPP_
+4. Copy the entire cookie value.
+5. From the terminal, run
+   * ```npx dx-do dashboard create-dashboard-api-key liveBrowserSessionCookie="<paste cookie header>"```
+6. Add a key "dashboardApiKey" to your tenant's config.json with the value generated by the previous command.
+
+

package/dist-node/database_or_inferred-8vqf5gyr.md

@@ -0,0 +1,75 @@
+---
+id: database_or_inferred
+title: DATABASE / INFERRED_DATABASE — the APM-discovered backend database
+layer: ATC
+related_entities: [business_transaction, agent, mysql_db]
+related_cookbooks: [investigator-flow, metrics-grounding]
+tags: [apm, runtime-specific, inferred]
+---
+
+# DATABASE and INFERRED_DATABASE
+
+## What they are
+
+When an APM agent watches an application call out to a database, it records two pieces of identity:
+
+- **Per-call backend** — captured under the agent's metric source as `Backends|<provider>|<remote>:<metric>` (response time, errors, throughput).
+- **Vertex** — a `DATABASE` vertex describing the backend (provider, host:port, database name, agent-domain).
+
+Across multiple agents in different apps, **the same backing database often shows up as multiple DATABASE vertices** — one per producing agent, since each agent only sees its own connection. To unify these, the platform's **inference rules** create an `INFERRED_DATABASE` vertex matching by host+port+dbname (or whichever shape the rule recognized). The `INFERRED_*` prefix is the marker that a vertex was produced by platform inference, not by an agent.
+
+When you query "the database for application X":
+
+- Per-agent slice → `DATABASE` (one per agent).
+- Unified backend identity → `INFERRED_DATABASE`.
+
+## Where they live
+
+Both live in the **ATC** layer. The non-inferred type is more common in raw vertex counts; the inferred type is typically smaller in number but more reliable as an identity anchor.
+
+## Useful attributes
+
+DATABASE:
+- `name` — display label, often `<provider>:<host>:<port>` shape.
+- `provider` — `MySQL`, `Oracle`, `PostgreSQL`, etc.
+- `hostname`, `port`, `remoteName` — the connection target.
+- `applicationName`, `agentDomain`, `agent` — the agent that observed it.
+- `backendNode` — the agent-internal id used to correlate metrics.
+
+INFERRED_DATABASE:
+- `name`, `databasename` — display + db-name.
+- `inferredBackendNode` — the inference-rule id.
+- `cor.dbname.contains.from` — the rule's matching criterion.
+- `provider`, `hostname`, `port` — same identity fields.
+
+## How metrics are reported
+
+Backend-call metrics live under the **calling agent's metric source** (not on the DATABASE vertex). Path shape: `Backends|<provider>|<host>|<dbname>:<metric>`. Common metric names: `Average Response Time (ms)`, `Errors Per Interval`, `Responses Per Interval`, `Connections In Use`.
+
+A common authoring pattern:
+
+1. Identify the BT or application of interest.
+2. Find the DATABASEs it talks to via TAS edges (`agent-monitors` → DATABASE; or `composed_of` for INFERRED_DATABASE).
+3. For each DATABASE, find the agent that produced it (`agent` attribute).
+4. Query MM under that agent for `Backends|...` metric paths.
+
+When the user asks "how are the databases doing" without naming an app, use `INFERRED_DATABASE` as the identity anchor — it deduplicates across agents.
+
+## Common synonyms / mistakes
+
+- "DB" / "database" / "datastore" — ambiguous between DATABASE and MYSQL_DB / native types.
+- DATABASE is **APM-discovered** — it represents what the agent saw. If the customer monitors the database directly with a MySQL agent, you'll also see `MYSQL_DB` (different vertex type, different metric set).
+- Don't filter only on `INFERRED_DATABASE` — many tenants have agent-side DATABASE without the corresponding inference rule firing.
+
+## Related entities
+
+- **BUSINESSTRANSACTION** — BTs that talk to this DB.
+- **AGENT** — the producing observer for a (non-inferred) DATABASE.
+- **MYSQL_DB** — the direct-monitoring counterpart when a MySQL agent is deployed.
+- **GENERICBACKEND / INFERRED_GENERICBACKEND** — the same pattern for non-DB backends.
+
+## See also
+
+- `cookbooks/metrics-grounding` — the "backend metrics live under the producing agent" pattern.
+- `cookbooks/investigator-flow` — DB-level health rollups.
+- `lexicon/inferred` — what the `INFERRED_*` prefix means.

package/dist-node/default-licensing-config-0p879qpb.template

@@ -0,0 +1,122 @@
+{
+  "licenseGroups": [
+    {
+      "name": "Kubernetes",
+      "isPrimary": true,
+      "devicesPerHost": 4,
+      "membershipRules": [
+        {
+          "agentNameRegex": "Kubernetes Agent.*"
+        }
+      ]
+    },{
+      "name": "Java",
+      "isPrimary": true,
+      "devicesPerAgent": 4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(tomcat|weblogic|websphere|undertow|liberty).*"
+        }
+      ]
+    },
+    {
+      "name": ".NET",
+      "isPrimary": true,
+      "devicesPerAgent": 4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(\\.NET).*",
+          "excludeAgentNameRegex": "PerfMonCollector.*"
+        }
+      ]
+    },
+    {
+      "name": "NodeJS",
+      "isPrimary": true,
+      "devicesPerAgent": 0.4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(nodejs-).*"
+        }
+      ]
+    },
+    {
+      "name": "Go",
+      "isPrimary": true,
+      "devicesPerAgent": 0.4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(go-).*"
+        }
+      ]
+    },
+    {
+      "name": "Python",
+      "isPrimary": true,
+      "devicesPerHost": 4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(python-).*"
+        }
+      ]
+    },{
+      "name": "PHP",
+      "isPrimary": true,
+      "devicesPerAgent": 4,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(php-).*"
+        }
+      ]
+    },
+    {
+      "name": "NetOps",
+      "isPrimary": true,
+      "devicesPerAgent": 0,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(NFA|NetOps|Spectrum|VNA).*"
+        }
+      ]
+    },
+    {
+      "name": "Infrastructure",
+      "isPrimary": false,
+      "devicesPerAgent": 1,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(Infrastructure).*"
+        },
+        {
+          "agentProcessRegex": "Cluster.*"
+        },
+        {
+          "agentNameRegex": "Infrastructure.*"
+        },
+        {
+          "agentNameRegex": "Prometheus.*"
+        }
+      ]
+    },
+    {
+      "name": "PerfMon",
+      "isPrimary": false,
+      "devicesPerAgent": 1,
+      "membershipRules": [
+        {
+          "agentProcessRegex": "(PerfMonCollector).*"
+        }
+      ]
+    },
+    {
+      "name": "Built-In",
+      "isPrimary": false,
+      "devicesPerGroupMember": 0,
+      "membershipRules": [
+        {
+          "agentHostRegex": "(Custom Metric Host|Experience Collector Host)"
+        }
+      ]
+    }
+  ]
+}

package/dist-node/dependency-3b0neg5x.md

@@ -0,0 +1,40 @@
+---
+id: dependency
+title: dependency — when a relationship implies one
+aliases: [depends-on, dependent]
+category: topology
+related: [service]
+tags: [overloaded]
+---
+
+# dependency
+
+"Depends on" is one of those words that sounds precise but isn't. In DXO2, several different mechanisms can imply that A depends on B; **none of them is universally trustworthy**, and not every relationship is a dependency.
+
+## Things that *can* indicate a dependency
+
+1. **TAS edges** with semantic = `contains`, `runs_on`, `composed_of`, `orchestrates`, or `agent-monitors` — directional and concrete, but the semantic varies and ~17% of edges in real tenants have no semantic at all (1140 of 6513 in demo-prod).
+2. **Service hierarchy** — a parent service often depends on its children for health rollups; sometimes also has more specific service-to-service dependency edges.
+3. **Application-side observed calls** — APM-recorded backend calls (BUSINESSTRANSACTION → DATABASE) are dependencies in the runtime sense.
+4. **k8s ownership** — a deployment "depends on" its replicaset which "depends on" its pods. Mechanically these are control-plane links, not call-graph dependencies.
+5. **Attribute similarity** — entities sharing IP/hostname imply *some* relationship, not necessarily dependency.
+
+## Things that look like dependency but aren't
+
+- Two entities being members of the same DXO2 service. They're related, not necessarily dependent.
+- Two services in a parent-child relationship. The parent often groups for ownership, not because the parent calls the child.
+- An AGENT "monitoring" an entity. The agent observes; the entity doesn't depend on the agent.
+
+## Disambiguation rule
+
+When the user says "what does X depend on":
+
+1. Ask (or pick): runtime dependency (call graph) or organizational dependency (service hierarchy)?
+2. Runtime → traverse APM-observed edges (`BUSINESSTRANSACTION` → backends, `agent-monitors` to find producing agents). The `service-dependency-graph` API returns the runtime view as a TAS subgraph.
+3. Organizational → `discovery_service_hierarchy` and walk the parent/child tree.
+4. Cross-check both before stating "X depends on Y" definitively.
+
+## See also
+
+- `cookbooks/entity-relationships` — the five kinds of relationships.
+- `cookbooks/service-hierarchies` — DXO2 service mechanics.

package/dist-node/description.md-qwc2bj9r.template

@@ -0,0 +1,30 @@
+# ${bundleName} (${bundleVersion})
+
+## Description
+
+${bundleDisplayName}
+
+## APM version
+${agentMinimumVersion}
+
+## Supported third party versions
+
+## Limitations
+
+## License
+https://communities.ca.com/docs/DOC-231150910#license on the CA APM Developer Community.
+
+## Support
+This document and associated tools are made available from CA Technologies as examples and provided at no charge as a courtesy to the CA APM Community at large. This resource may require modification for use in your environment. However, please note that this resource is not supported by CA Technologies, and inclusion in this site should not be construed to be an endorsement or recommendation by CA Technologies. These utilities are not covered by the CA Technologies software license agreement and there is no explicit or implied warranty from CA Technologies. They can be used and distributed freely amongst the CA APM Community, but not sold. As such, they are unsupported software, provided as is without warranty of any kind, express or implied, including but not limited to warranties of merchantability and fitness for a particular purpose. CA Technologies does not warrant that this resource will meet your requirements or that the operation of the resource will be uninterrupted or error free or that any defects will be corrected. The use of this resource implies that you understand and agree to the terms listed herein.
+
+Although these utilities are unsupported, please let us know if you have any problems or questions by adding a comment to the CA APM Community Site area where the resource is located, so that the Author(s) may attempt to address the issue or question.
+
+Unless explicitly stated otherwise this field pack is only supported on the same platforms as the APM core agent. See [APM Compatibility Guide](http://www.ca.com/us/support/ca-support-online/product-content/status/compatibility-matrix/application-performance-management-compatibility-guide.aspx).
+
+
+# Change log
+Changes for each version of the field pack.
+
+Version | Author | Comment
+|--------|--------|--------|
+|${bundleVersion}| ${bundleAuthor} | First version of the field pack.|

package/dist-node/discovery-flow-fw79kbx4.md

@@ -0,0 +1,116 @@
+---
+id: discovery-flow
+title: Discovery flow — figure out what's queryable on this tenant
+applies_to: all
+tags: [getting-started, discovery]
+related: [tas-quickstart, nassql-quickstart, mm-quickstart]
+---
+
+# Discovery flow
+
+Before authoring any specific query, learn what the tenant has. The discovery tools are read-only and cached — call them freely.
+
+## The discovery hierarchy (READ FIRST)
+
+Multiple surfaces overlap in what they can tell you. Use them in this order — each tier is cheaper and more abstract than the next:
+
+1. **`discovery_capabilities`** — *(forthcoming)* what this tenant supports (LUCENE indexing, traversal, etc.). One call up front so you don't author against a feature that's off. Without this, you find out by failing.
+2. **`corpus_list("entities")` + `corpus_get("entities", "<id>")`** — universal *conceptual* knowledge. What a HOST is, what an AGENT is, where each lives, what it's commonly confused with. Tenant-independent; cheap; teaches the model the right ontology before it asks the tenant anything.
+3. **`discovery_layers` / `discovery_services` / `discovery_attributes(layer)` / `discovery_attribute_values(layer, attr)`** — live, tenant-specific. Cached per session. Use after the entity-level grounding when you need to know "what does THIS tenant actually have."
+4. **NASSQL `FROM_METADATA` with KEEP** — when you need the actual metric catalog as a *dataframe* (for downstream GROUP / COUNT / JOIN). `discovery_metrics` returns a flat string list capped at 1000; FROM_METADATA returns the full catalog with all columns.
+
+`corpus_list("queries", {type: "<type>"})` and `corpus_get("queries", "<id>")` sit alongside this hierarchy as the *worked-example* surface — read a known-good query when you want to pattern-match against an existing one rather than author from scratch.
+
+## TAS — layers and attributes
+
+```
+discovery_layers                              → ["INFRASTRUCTURE", "CONNECTOR", ...]
+discovery_attributes(layer)                   → ["hostname", "ip", "type", ...]
+discovery_attribute_values(layer, attribute)  → ["host-a", "host-b", ...]
+```
+
+Pattern:
+
+1. `discovery_layers` to know what layers exist
+2. Pick the layer relevant to the query goal (e.g. `INFRASTRUCTURE` for hosts)
+3. `discovery_attributes(layer)` to see what's filterable
+4. For IN-style filters: `discovery_attribute_values(layer, attribute)` to
+   see distinct values
+
+Caching: each call hits the live tenant once, then serves from session
+cache. Pass `refresh: true` on any discovery tool call to bust that key's
+cache; rebinding the session clears everything.
+
+## NASSQL — services and metrics catalog
+
+```
+discovery_services    → ["service-a", "service-b", ...]
+discovery_metrics     → ["cpu.utilization", "mem.free", ...]   (capped at 1000)
+```
+
+NASSQL queries that name services or metrics should validate names
+against discovery first.
+
+`discovery_metrics` is capped at 1000 names — see `gotchas.md` for the
+workaround if a known metric is missing.
+
+## MM — same metric catalog
+
+`discovery_metrics` is the same source — no separate MM-specific
+discovery tool today.
+
+## Corpus — multi-section reference content
+
+Separate from live discovery, the corpus has known-good worked
+examples and reference docs. The corpus is multi-section (queries,
+cookbooks today; entities/metrics/lexicon planned) and exposed through
+three generic tools:
+
+```
+corpus_sections                          → enumerate sections + per-section filter shapes
+corpus_list(section, filter?)            → list entries in a section
+corpus_get(section, id)                  → fetch a single entry (full payload + metadata)
+```
+
+For worked-example queries:
+
+```
+corpus_list("queries")                   → list all worked-example queries (filter by type or tags)
+corpus_get("queries", "01-discover-vertices")  → full canonical query + descriptions + tmd + md
+```
+
+For reference cookbooks (this is one of them):
+
+```
+corpus_list("cookbooks")                 → list all cookbooks (filter by applies_to or tags)
+corpus_get("cookbooks", "tas-quickstart")      → full markdown body
+```
+
+Use the corpus to pattern-match against queries known to work on a
+similar tenant, and to look up universal DXO2 behaviors before going to
+the tenant.
+
+## Working set vs corpus
+
+| Tool | Set | Mutable? |
+|---|---|---|
+| `list_queries` / `get_query` | User's queries under `~/.dxdo/queries/<alias>/` | Yes |
+| `corpus_list("queries")` / `corpus_get("queries", id)` | Universal worked examples shipped via `@dx-do/corpus` | No |
+
+Don't mix them up. The user's queries are scratch / in-progress. The
+corpus is reference / known-good.
+
+## Putting it together
+
+Typical agent flow for a new query:
+
+1. `corpus_sections` → see what corpus sections exist
+2. `corpus_list("cookbooks", {applies_to: "<type>"})` → find relevant reference docs
+3. `corpus_get("cookbooks", "<type>-quickstart")` → load the quickstart
+4. `discovery_layers` / `discovery_attributes` / `discovery_metrics` → know what's queryable
+5. `corpus_list("queries", {type: "<type>"})` → see known-good examples
+6. `corpus_get("queries", <id>)` → study a relevant example
+7. Draft the query
+8. `create_query(...)` → save to user's working set
+9. `run_query(...)` → execute, see results
+10. If wrong: `update_query(...)` to refine, `run_partial_query(...)` to debug a sub-tree

package/dist-node/dxi_service-13prnpd5.md

@@ -0,0 +1,59 @@
+---
+id: dxi_service
+title: DXI_SERVICE — APM-internal service abstraction (NOT the same as `service`)
+layer: APM_INFRASTRUCTURE
+synonyms: [APM service, monitored service, application service]
+related_entities: [service, agent, agent_connection]
+related_cookbooks: [universes-and-scopes, investigator-flow]
+tags: [apm, telemetry]
+---
+
+# DXI_SERVICE
+
+## What it is
+
+A `DXI_SERVICE` is a special entity that represents a portion of API surface for the current DXO2 tenant, at this time, it really only exposes the performance the "NASS Reactive Client", which is an important but small facet of the DXO2 tenant surface. It's NOT the same as the topology-level `service` (`saService`) used to organize and scope tenant data; the names collide in user vocabulary but the concepts are different. There is usually one per tenant.
+
+## Where it lives
+
+`type=DXI_SERVICE` vertices live in the **APM_INFRASTRUCTURE** layer (alongside `AGENT`, `AGENT_CONNECTION`, `APM_SAAS`, etc.).
+
+This is the same layer where APM telemetry collectors live — DXI_SERVICE is the *monitored target* abstraction, AGENT is the *collector* abstraction.
+
+## DXI_SERVICE vs `service` — the load-bearing distinction
+
+When a user says "service" in a DXO2 question, they almost never mean DXI_SERVICE. They usually mean one of:
+
+| User says                   | Probably means                                                    | Lives in | Vertex type |
+|-----------------------------|-------------------------------------------------------------------|---|---|
+| "the Mobile Service"        | A grouping / business service                                     | (organizational axis) | `saService` (topology) |
+| "the service that's failing" | Same — `saService`                                                | (organizational axis) | `saService` |
+| "the NASS service"          | part of DXO2, usually a deep meta question about slowness in DXO2 | APM_INFRASTRUCTURE layer | `DXI_SERVICE` |
+
+In an investigative conversation: if the user names a service, default to `saService` (the organizational axis). Only consider DXI_SERVICE when the user is specifically discussing APM-monitored applications, or when the context is "what is this agent watching."
+
+## Common uses
+
+- there are no common uses for DXI_service! 
+
+## Useful attributes
+
+DXI_SERVICE attributes overlap with other APM_INFRASTRUCTURE entities (it shares the layer's general attributes — `agent`, `SystemFQHostName`, `category`, `SourceProduct`, etc.). Beyond those:
+
+- `name` — SuperDomain|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)
+
+## Common synonyms / mistakes
+
+- **Confusing with `saService`** — happens often. The fix is to ask which kind of service the user means; if the answer is "I just want the things my Mobile Service includes," that's `saService` (use the SERVICE filter in TAS).
+- **Treating DXI_SERVICE as the unit of grouping** — it's not; it's a special entity that represents a platform feature. Grouping happens through `saService` and through universes.
+
+## Related entities
+
+- **`service`** (topology, `saService`) — the organizational service axis. Almost always what the user means when they say "service".
+- **`agent_connection`** (APM_INFRASTRUCTURE) — the connection lifecycle abstraction.
+
+## See also
+
+- `entities/service` — the more common "service" the user means.
+- `entities/agent` — the collector counterpart.
+- `cookbooks/universes-and-scopes` — universe-aware querying that may interact with both DXI_SERVICE and `saService`.