device_get
Fetch one device with its related state: tags, alerts, the ping / oid / interface / port / disk trackers configured on it, its SNMP walk trackers, and a netflow rollup. Wraps GET /api/device/{id} (permission: devices).
Bulk payloads are opt-in, and that is a change from how this tool used to behave. It returned every log row every tracker collected in the window, inline: one 8-hour call on an ordinary host measured ~127 KB — 85 KB of oid log rows across 12 trackers, 35 KB for a single ping tracker's 479 samples — so pulling three hosts to "see the state" could spend 300 KB of context before any reasoning started. By default each tracker now returns its identity and latest value (which is what state questions need) plus log_count, the number of rows sitting in the window.
include_logs:true puts the rows back. Pair it with max_log_rows (default 200 per tracker, newest kept) so one chatty tracker cannot swamp the response; a tracker that got cut carries logs_truncated:true next to the untrimmed log_count. When the question is "is this metric degrading?" rather than "what happened at 14:05?", device_metric_summary answers it from fixed-window stats and ships no rows at all.
include_walk_data:true returns the stored SNMP walk payloads, omitted for the same reason: one configured walk tracker reaches ~72 KB of JSON on its own. Without the flag each walk row keeps id / oid / interval / timestamp plus walk_entries, the payload's top-level entry count.
What stays unbounded: the tracker rows themselves. Both flags govern each tracker's history, never how many trackers come back — a switch with 190 monitored interfaces returns 190 interface rows in summary mode too. interfaces_search pages interface metadata across the fleet if that is the real question.
Window: hours (1-168, default 8) or explicit start_time+end_time (ISO-8601 UTC). It scopes the netflow rollup and log_count as well as the rows themselves, so it still matters with include_logs off. The appliance monitors itself as the device holding ip_address 127.0.0.1 — resolve that one by IP (device_find), never by assuming id 1; the id is whatever the sequence allocated.
Use device_list or device_find to locate an id first.
Examples: device_get({id: 42}) — state only, the cheap default device_get({id: 42, hours: 24, include_logs: true, max_log_rows: 50})
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Device id. Use device_list or device_find to locate. | |
| hours | No | Time window for log data and the netflow rollup (1-168). Default 8. | |
| end_time | No | ISO-8601 UTC; pairs with start_time. | |
| start_time | No | ISO-8601 UTC; pairs with end_time (overrides hours). | |
| include_logs | No | Return each tracker's log rows inline. Default false — trackers come back as identity + latest value + log_count, which is enough for state questions and roughly an order of magnitude smaller. Turn it on only when you need the individual samples, and cap it with max_log_rows. | |
| max_log_rows | No | Per-tracker ceiling on returned log rows when include_logs is true (1-2000, default 200). Keeps the newest rows; a trimmed tracker is flagged with logs_truncated:true and still reports the full in-window log_count. Ignored when include_logs is false. | |
| include_walk_data | No | Return the stored payload of each SNMP walk tracker. Default false — a single walk row can be ~72 KB. Without it each walk keeps id/oid/interval/timestamp and walk_entries (top-level entry count). |