Skip to content

Commit 6aa9340

Browse files
authored
chore(skill): investigate orb (#1325)
making sure whomever is on-call has a good time
1 parent bf279e9 commit 6aa9340

3 files changed

Lines changed: 179 additions & 0 deletions

File tree

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
---
2+
name: investigate-orb
3+
description: Use when diagnosing what happened on a field Orb, especially when given an orb_id tag, a service tag, an incident time, or symptoms involving health, connectivity, MCUs, attestation, updates, remote jobs, backend reporting, or signups.
4+
---
5+
6+
# Investigate Orb
7+
8+
## Overview
9+
10+
Investigate field Orbs from Datadog evidence. Build a UTC chronology, distinguish observations from inferences, and treat missing telemetry as an unknown rather than proof of health.
11+
12+
## Establish Scope
13+
14+
Extract these values from the request:
15+
16+
- `orb_id:<orb_id>`: required. Ask for it only when the context does not identify one Orb.
17+
- `service:<service_name>`: optional. Use it as the starting service, not the investigation boundary.
18+
- Incident window: use the supplied bounds. Otherwise start at `1h` and widen to `6h` or `24h` only when needed.
19+
- Symptom: select related services from [references/services.md](references/services.md).
20+
21+
Keep this skill's work read-only and limited to Datadog. Do not SSH into the Orb, run remote commands, restart services, create probes or downtimes, deploy software, or investigate the whole fleet unless the user explicitly expands the scope.
22+
23+
## Use Pup
24+
25+
1. If `dd-pup` is available in the current skill catalog, read and follow it.
26+
2. Check for the CLI with `command -v pup`.
27+
3. When both are available, use the skill's authentication guidance and the `pup` CLI.
28+
4. When only the CLI is available, inspect `pup logs search --help` before querying.
29+
5. When the CLI is absent, report the missing dependency. Do not install it without authorization.
30+
31+
Check authentication with `pup auth status`. On authentication failure, follow `dd-pup` when available; otherwise report the failure and the required login or permission. Never expose credentials or raw configuration.
32+
33+
Pass `--read-only` to every Pup data query. Prefer JSON output so timestamps, tags, and attributes remain inspectable.
34+
35+
## Investigation Loop
36+
37+
1. Query the Orb without a service filter. Confirm that `orb_id` is the correct facet and discover the actual `service`, `host`, `source`, version, and status fields.
38+
2. Query the requested or symptom-selected service over the same window.
39+
3. Order results ascending and build a timeline of state changes, starts, exits, restarts, warnings, errors, and recovery.
40+
4. Expand only to dependencies named in the service reference or revealed by the evidence.
41+
5. If a query reaches its limit, split the time window into smaller slices. Do not assume the truncated result is complete.
42+
6. Widen the time window only when the current evidence does not show the onset or recovery.
43+
7. Stop when evidence answers the question or when a specific missing signal blocks further Datadog investigation.
44+
45+
Start with:
46+
47+
```bash
48+
pup logs search \
49+
--query "orb_id:<orb_id>" \
50+
--from 1h \
51+
--sort asc \
52+
--limit 100 \
53+
--output json \
54+
--read-only
55+
```
56+
57+
Then scope by service:
58+
59+
```bash
60+
pup logs search \
61+
--query "orb_id:<orb_id> service:<service_name>" \
62+
--from 1h \
63+
--sort asc \
64+
--limit 100 \
65+
--output json \
66+
--read-only
67+
```
68+
69+
Use `--from` and `--to` with explicit RFC3339 timestamps when the incident window is known. Preserve the user's timezone in the report, but correlate evidence in UTC.
70+
71+
## Interpret Evidence
72+
73+
- Treat repeated starts after the configured `RestartSec` as evidence of a restart loop only when logs show distinct process lifecycles.
74+
- Treat a graceful stop, crash, reboot, dependency failure, and telemetry loss as separate hypotheses.
75+
- Correlate a service failure with its dependencies before assigning root cause.
76+
- Treat absent logs as inconclusive. Check whether other services on the same Orb continued reporting.
77+
- If every service disappears together, consider connectivity, power, reboot, `datadog-agent`, monitoring authentication, or ingestion failure.
78+
- Do not infer a deployed service tag from a unit filename. Confirm tags from the broad Orb query.
79+
- Use metrics, traces, or events only when the repository or returned logs identify a concrete signal relevant to the hypothesis. Inspect the Pup subcommand help first and keep the query read-only.
80+
81+
## Report
82+
83+
Lead with the narrowest supported conclusion. Include:
84+
85+
1. Orb ID, UTC window, original timezone, and services queried.
86+
2. Finding and confidence: confirmed, likely, or inconclusive.
87+
3. Short chronological evidence table with timestamps and sources.
88+
4. Supporting and contradicting evidence for the leading hypothesis.
89+
5. Telemetry gaps, query limits, tag uncertainty, and other limitations.
90+
6. The smallest useful next query or separately authorized action.
91+
92+
Quote only short log fragments needed to identify an event. Never claim root cause from temporal proximity alone.
93+
94+
## Common Mistakes
95+
96+
- Starting with `service:` and missing an Orb-wide reboot or telemetry outage.
97+
- Querying every related service before establishing a timeline.
98+
- Omitting `--read-only`.
99+
- Treating `check-my-orb` as a continuously running daemon; it is an on-demand composite diagnostic.
100+
- Treating silence as health or as proof that a process stopped.
101+
- Expanding into SSH, remediation, or fleet comparison without authorization.
102+
- Reporting a hypothesis as fact when logs only show correlation.
Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
interface:
2+
display_name: "Investigate Orb"
3+
short_description: "Investigate field Orb incidents in Datadog"
4+
default_prompt: "Use $investigate-orb to investigate orb_id:<orb_id> and explain what happened."
Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
# Orb Service Map
2+
3+
Read the section that matches the symptom. Query the primary service first, then add related services only when the timeline or dependency chain calls for them. Confirm every deployed Datadog `service` tag from an Orb-wide query because unit names and tags can differ across Orb generations.
4+
5+
## General health
6+
7+
- `check-my-orb`: on-demand composite diagnostic. Its output can cover OS release, hardware platform, active update slot, mounts, model artifacts, persistent storage, service state, SE050 operations, and MCU firmware versions. Remote jobs can return its output through `worldcoin-jobs-agent`.
8+
- `worldcoin-update-verifier`: checks system health after an update and manages slot and rootfs approval.
9+
- `datadog-agent`: inspect when multiple service logs disappear or the Orb has no recent telemetry.
10+
11+
## MCU health
12+
13+
- `worldcoin-orb-telemetry`: primary MCU telemetry service supplied by the operator runbook.
14+
- `worldcoin-mcu-telemetry`: older observed name; use only when the Orb-wide query returns it.
15+
- `worldcoin-configure-can@can0`: CAN setup used by attestation and MCU-aware services.
16+
17+
## Connectivity
18+
19+
- `worldcoin-connd`: Orb connectivity daemon for Wi-Fi, cellular, and Bluetooth. Its unit requires `NetworkManager` and `zenohd`.
20+
- `NetworkManager`: connection profiles, interface state, routes, and failover.
21+
- `ModemManager`: cellular modem state and recovery.
22+
- `wpa_supplicant` or platform-specific variants: Wi-Fi authentication and control.
23+
- `systemd-networkd`: older or platform-specific network management; query only when observed.
24+
- `zenohd`: messaging dependency whose failure can affect connd and several Orb services.
25+
26+
## Attestation
27+
28+
- `worldcoin-attest`: retrieves and refreshes the short-lived backend authorization token through the SE050 and exposes it on D-Bus.
29+
- `worldcoin-se050-reprovision`: SE050 reprovisioning; relevant after provisioning or secure-element failures.
30+
- `worldcoin-dbus`: session bus used to distribute the attestation token.
31+
- `zenohd` and `worldcoin-configure-can@can0`: soft dependencies and hardware communication paths.
32+
33+
## Updates
34+
35+
- `worldcoin-supervisor`: coordinates privileged device state and shutdown behavior.
36+
- `worldcoin-update-agent`: fetches and installs update components; coordinates with supervisor and update storage mounts.
37+
- `worldcoin-update-verifier`: waits for system stability, then approves or rejects the active slot.
38+
- `mnt-scratch.mount`, `mnt-updates.mount`, `worldcoin-ssd-setup-scratch`, and `worldcoin-ssd-setup-models`: inspect when downloads, artifacts, models, or slot verification fail.
39+
40+
## Remote jobs
41+
42+
- `worldcoin-jobs-agent`: receives, executes, cancels, and reports prescribed remote jobs.
43+
- `worldcoin-attest`: supplies backend authorization.
44+
- `zenohd`: carries the job messaging path.
45+
- `datadog-agent`: relevant when job execution appears silent rather than failed.
46+
47+
## Backend reporting
48+
49+
- `worldcoin-backend-status`: collects Orb status over D-Bus and sends it to the fleet backend.
50+
- `worldcoin-attest`, `worldcoin-dbus`, and `zenohd`: hard dependencies in its unit.
51+
52+
## Signups
53+
54+
- `worldcoin-core`: owns signup logic and sensor orchestration.
55+
- `worldcoin-ui`: presents operator and user feedback.
56+
- `worldcoin-supervisor`: controls device state that can permit or block signups.
57+
- `worldcoin-attest` and `worldcoin-connd`: backend authorization and connectivity.
58+
- `worldcoin-backend-status`: observes and reports signup lifecycle states. Distinguish not-ready, in-progress, completed-failure, hung, and successful-but-unreported signups.
59+
60+
## Observability and shared IPC
61+
62+
- `datadog-agent`: log and metric collection and forwarding.
63+
- Orb monitoring-auth client/server: supplies Datadog monitoring credentials; discover the exact deployed service tags before filtering.
64+
- `worldcoin-dbus`: shared local IPC bus.
65+
- `zenohd`: shared messaging transport. Correlate it when several dependent services fail together.
66+
67+
## Repository sources
68+
69+
- Unit files: `*/debian/*.service`
70+
- Composite health example: `orb-jobs-agent/tests/docker/check-my-orb_output.txt`
71+
- Component descriptions: top-level `README.md`, component `README.md`, and component `Cargo.toml`
72+
- Connectivity implementation: `orb-connd/`
73+
- Telemetry transport: `telemetry/`, `orb-dogd/`, and `orb-monitoring-auth/`

0 commit comments

Comments
 (0)