К основному содержанию
скилл CX Codex

dt-obs-network-devices — скилл для Claude Code: SNMP-устройства

Скилл разбирает данные SNMP-мониторинга в Dynatrace: инвентарь устройств, состояние интерфейсов, топологию и логи. Пригодится, когда надо найти упавший порт или перегруженный коммутатор.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add Dynatrace/dynatrace-for-ai --skill dt-obs-network-devices -a claude-code
Открыть на GitHub

Что делает dt-obs-network-devices

Скилл работает с тремя слоями данных Dynatrace. Топология — это узлы Smartscape EXT_NETWORK_DEVICE и EXT_NETWORK_INTERFACE с вендором, моделью, прошивкой, адресами и связями belongs_to и calls. Метрики лежат в пространстве com.dynatrace.extension.network_device.*: CPU, память, uptime, пропускная способность, насыщение, ошибки. Логи собирают SNMP-ловушки, syslog и записи автообнаружения.

Слои соединяются по Smartscape ID. Каждая метрика несёт измерение dt.smartscape.ext_network_device, у интерфейсных метрик есть ещё dt.smartscape.ext_network_interface, поэтому через lookup [smartscapeNodes …] к цифрам подтягиваются читаемые имена. Запросы на DQL лежат в файлах-справочниках, скилл сам направляет вопрос в нужный: инвентарь и топология, здоровье и производительность, события.

Первое, что стоит проверить у устройства, — поле monitoring_mode. Метрики есть только у режима Extension, когда устройство опрашивается SNMP-расширением напрямую. Устройства в режимах Discovery и Neighbor метрик не имеют, и если по ним пусто, это не пробел в данных. Скилл не подходит для трафика между узлами и top talkers — для этого есть dt-obs-network-flows, а пропускная способность сетевых карт хостов разбирается в dt-obs-hosts.

Какие задачи решает

  • собрать инвентарь коммутаторов, маршрутизаторов и межсетевых экранов
  • найти интерфейсы в состоянии down
  • проверить загрузку CPU и памяти на конкретном устройстве
  • построить карту соседей по LLDP и CDP
  • разобрать повторяющиеся syslog-ошибки и SNMP-ловушки

Примеры запросов агенту

  • Покажи все SNMP-устройства в Dynatrace с режимом Extension
  • Какие интерфейсы на core-роутере сейчас down?
  • Какие SNMP-ловушки отправлял этот коммутатор за последний час?

Как установить dt-obs-network-devices

1Через Skills CLI (Vercel)

npx skills add Dynatrace/dynatrace-for-ai --skill dt-obs-network-devices -a claude-code

2Вручную: положить файлы

~/.claude/skills/dt-obs-network-devices/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/dt-obs-network-devices/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора29

dt-platform-costs Анализирует фактическое потребление и расходы тенанта Dynatrace по модели DPS через DQL. Помогает найти главные драйверы трат и распределить расходы по командам. CX Codex +1 1 400установок dt-obs-ext-monitors Скилл настраивает отправку результатов внешних проверок и CI-мониторинга в Dynatrace Grail через API событий. Пригодится при замене устаревшего эндпоинта synthetic v1. CX Codex +1 1 100установок dt-sec-ioc-hunting Ищет индикаторы компрометации из отчётов и адвизори в логах и спанах Dynatrace и считает оценку подверженности угрозе от 0 до 100. CX Codex +1 1 000установок dt-obs-network-flows Скилл для Dynatrace: разбирает сетевые потоки из трёх источников и отвечает, кто с кем говорит и где рвутся соединения. CX Codex +1 912установок dt-obs-compliance-assistant Отслеживает соответствие регламенту EU DORA через Dynatrace Compliance Assistant. Помогает оценивать compliance score, состояние CIF и инциденты. CX Codex +1 889установок dt-setup-react-native Пошагово настраивает плагин Dynatrace в проектах на React Native или Expo: правит конфиги Babel, подключает зависимости и проверяет параметры приватности. CX Codex +1 860установок dt-setup-android Подключает базовый мониторинг Dynatrace к Android-проекту на Kotlin или Java. Помогает настроить плагин Gradle, параметры агента и сбор согласия пользователя. CX Codex +1 857установок dt-setup-flutter Пошагово подключает Dynatrace к проекту на Flutter: настраивает зависимости и генерирует нативные конфиги для мониторинга. CX Codex +1 852установок

Похожие

dtctl Dynatrace Управляет Dynatrace через CLI: исследует инциденты, логи, трассировки и состояние сервисов. Пригодится для запросов DQL и работы с дашбордами. CX Codex +1 1 300установок Dynatrace Expert официальный github Субагент подключает наблюдаемость и безопасность Dynatrace прямо к рабочим процессам в репозитории. Он разбирает инциденты, валидирует релизы и ищет уязвимости по логам и спанам. ★ 40 418звёзд репо network-101 zebbern Скилл помогает агенту поднять и протестировать HTTP, HTTPS, SNMP и SMB в учебной лаборатории: от настройки сервисов до разбора логов. CX Codex +1 ★ 4 676звёзд репо network-debugging aj-geddes Помогает агенту разобраться, почему запросы падают, грузятся медленно или рвутся. Пригодится, когда приложение тормозит из-за сети, а причина неясна. CX Codex +1 526установок analyzing-network-flow-data-with-netflow mahipal Скилл разбирает записи NetFlow v9 и IPFIX, ищет аномалии по объёму, сканирование портов, утечку данных и периодические обращения к C2. CX Codex +1 372установок network-protocol-attacks yaklang Плейбук по атакам на сетевые протоколы: ARP-спуфинг, отравление LLMNR и NBT-NS, WPAD, DHCPv6, VLAN hopping. Пригодится на внутреннем пентесте. CX Codex +1 3 600установок

Рядом в теме «DevOps и инфраструктура»

Всё по теме «DevOps и инфраструктура» →

Вопросы о dt-obs-network-devices

Как установить dt-obs-network-devices в Claude?

Выполните npx skills add Dynatrace/dynatrace-for-ai --skill dt-obs-network-devices -a claude-code. Скилл окажется в ~/.claude/skills/dt-obs-network-devices/SKILL.md.

Что делает dt-obs-network-devices?

Разбирает данные SNMP-мониторинга Dynatrace: инвентарь устройств и интерфейсов, метрики здоровья, топологию и логи. Скилл сам выбирает нужный справочник с DQL-запросами под вопрос.

Почему у устройства нет метрик?

Проверьте monitoring_mode. Метрики собираются только в режиме Extension, когда устройство опрашивается SNMP-расширением. В режимах Discovery и Neighbor их нет.

Исходный текст

SKILL.md · Apache-2.0
---
name: dt-obs-network-devices
description: >-
  Analyze SNMP-monitored network devices (switches, routers, firewalls, load
  balancers) in Dynatrace. Three data layers: Smartscape topology
  (`EXT_NETWORK_DEVICE` / `EXT_NETWORK_INTERFACE` nodes, `belongs_to` and
  `calls` edges); `com.dynatrace.extension.network_device.*` metrics (CPU,
  memory, uptime, throughput, saturation, errors); and logs (SNMP traps,
  syslog, auto-discovery). Use to inventory devices, find down or saturated
  interfaces, check device CPU/memory/uptime, map topology and neighbors,
  detect interface errors, and investigate traps and syslog events.
  Trigger: "network device", "switch", "router", "firewall", "SNMP",
  "interface status", "interface down", "interface utilization",
  "link saturation", "device CPU", "device memory", "device uptime",
  "device neighbors", "LLDP", "CDP", "SNMP trap", "syslog".
  Do NOT use for network flow/traffic or top talkers (use dt-obs-network-flows),
  host NIC throughput (use dt-obs-hosts), or service request/latency (use
  dt-obs-services).
license: Apache-2.0
---

# Network Devices Skill

Analyze SNMP-monitored network infrastructure in Dynatrace — switches, routers, firewalls, load balancers, access points, and any other device polled by a **network device extension** (the SNMP-generic and vendor SNMP extensions). This skill covers the **device and interface data model** and routes each question to the right reference file. All DQL lives in the reference files and was validated against a live tenant with `dtctl query`.

## What Network Device Monitoring Tells You

SNMP extensions poll network hardware and expose it in Dynatrace as **three layers**:

- **Topology** — an inventory of devices and their interfaces as Smartscape nodes (`EXT_NETWORK_DEVICE`, `EXT_NETWORK_INTERFACE`), with attributes (vendor, model, OS/firmware, location, contact, IPs, MACs, link speed) and relationships (which interface belongs to which device; which devices are neighbors via LLDP/CDP).
- **Metrics** — time series for device health (CPU, memory, uptime) and per-interface health (operational/admin status, in/out throughput, errors, discards, packet mix), under the `com.dynatrace.extension.network_device.*` namespace.
- **Logs** — event-driven records: SNMP traps (link-up/down, hardware faults), syslog messages (config changes, authentication, interface events), and auto-discovery activity (devices and neighbors found per poll cycle).

This answers questions such as: *Which interfaces are down? Which links are saturated? Is this router's CPU pegged? Which devices rebooted? What is connected to this switch? What traps has this device sent? What syslog errors are recurring?*

## The Three Layers (and how they join)

| Layer | Query with | Grain | Key fields |
|---|---|---|---|
| **Topology** | `smartscapeNodes "EXT_NETWORK_DEVICE"` / `smartscapeNodes "EXT_NETWORK_INTERFACE"` | One row per device / interface (current inventory) | `id`, `name`, `monitoring_mode`, `device_type`, `location`, `ip`, `speed`, edges via `belongs_to` / `calls` |
| **Metrics** | `timeseries … com.dynatrace.extension.network_device.*` | Time series per device / interface | grouped by `dt.smartscape.ext_network_device` and (interface metrics) `dt.smartscape.ext_network_interface` |
| **Logs** | `fetch logs \| filter dt.openpipeline.source == "…"` | Individual log records (traps, syslog, discovery) | joined to topology by expanding the device `ip[]` array and matching `device.address` / `dt.ingest.source.ip` — see [references/logs.md](references/logs.md) |

**The join key is the Smartscape ID.** Every metric carries a `dt.smartscape.ext_network_device` dimension (and interface metrics also carry `dt.smartscape.ext_network_interface`). Use `lookup [smartscapeNodes …]` to attach human-readable device/interface names to metric results, and to attach live metrics to an inventory listing. Both reference files show this pattern.

## Monitoring Mode Determines What Data Exists

Every device has a `monitoring_mode`. **This is the first thing to check** — it decides whether metrics exist at all:

| `monitoring_mode` | Meaning | Has metrics? | Has full attributes? |
|---|---|---|---|
| **`Extension`** | Directly polled by an SNMP extension | **Yes** — full `com.dynatrace.extension.network_device.*` set | Yes |
| **`Discovery`** | Discovered on the network but not directly polled | **No** | Partial |
| **`Neighbor`** | Known only because a polled device names it as an LLDP/CDP neighbor | **No** | Minimal (name, chassis MAC) |

> If a device has no metrics, check its `monitoring_mode` before assuming a data gap — only `Extension`-mode devices are polled. When listing "monitored devices," exclude `Neighbor` (and usually `Discovery`).

## Routing

1. **Inventory, attributes, or topology** (list devices, find a device's interfaces, map neighbors, read model/firmware/location) → [references/topology-model.md](references/topology-model.md).
2. **Health or performance** (CPU, memory, uptime, interface up/down, throughput, saturation, errors) → [references/metrics.md](references/metrics.md).
3. **Event-driven signals** (SNMP traps, syslog messages, discovery activity) → [references/logs.md](references/logs.md).
4. Most real questions combine layers (e.g. *"which interfaces on the core router are down"* = metric status filtered to one device, joined to interface names). The metrics and logs references show these joined queries.

## Related Skills

Network device monitoring is one part of Dynatrace network observability. Route elsewhere when the question is not about device/interface health or topology:

| The user wants… | Use |
|---|---|
| Traffic **between** entities, top talkers, conversations, connection health (the flows *through* the network) | [dt-obs-network-flows](../dt-obs-network-flows/SKILL.md) — including NetFlow/IPFIX/sFlow that these same devices export |
| Host NIC throughput / packet drops on **OneAgent-monitored hosts** (not SNMP devices) | [dt-obs-hosts](../dt-obs-hosts/SKILL.md) → `references/host-metrics.md` |
| Service request rate, latency, error rate | [dt-obs-services](../dt-obs-services/SKILL.md) |
| Setting up or configuring an extension (this skill covers the resulting **data model**, not extension authoring) | [dt-obs-extensions](../dt-obs-extensions/SKILL.md) |
| General Smartscape traversal syntax (`traverse`, `smartscapeEdges`, `references[…]`) | [dt-dql-essentials](../dt-dql-essentials/references/smartscape-topology-navigation.md) |

> **Network devices vs. network flows.** This skill answers *"what is the state of the box and its ports"* (SNMP device/interface health and topology). `dt-obs-network-flows` answers *"what traffic is crossing the network"* (conversations, bytes, talkers). The same router appears in both: here as an `EXT_NETWORK_DEVICE` with interface counters, there as a NetFlow exporter. A future macro **`dt-obs-network`** skill may unify them; until then, cross-link.

## Reference Files

- [references/topology-model.md](references/topology-model.md) — **Validated.** The Smartscape model: `EXT_NETWORK_DEVICE` and `EXT_NETWORK_INTERFACE` node types with full field reference, monitoring modes, and the `belongs_to` / `calls` edges. DQL for device inventory (with filtering by mode/type/location/vendor), listing a device's interfaces, resolving an interface to its device, and mapping device/interface neighbor topology.
- [references/metrics.md](references/metrics.md) — **Validated.** The `com.dynatrace.extension.network_device.*` metric catalog with units, dimensions, and field-typing rules. DQL for device health (top CPU, memory % with fallback, uptime and reboot detection) and interface health (down interfaces, throughput and saturation vs. link speed, error/discard counts, per-device interface detail), each joined to device/interface names.
- [references/logs.md](references/logs.md) — **Validated.** The three log sources: SNMP traps (`extension:com.dynatrace.extension.snmp-traps-generic`), syslog (`extension:syslog`), and auto-discovery activity (`extension:com.dynatrace.extension.snmp-auto-discovery`). Covers the IP-to-Smartscape join pattern (`device.address` / `dt.ingest.source.ip` → `snmp.ip`), field references for all three sources, and DQL for recent traps with device names, trap frequency by OID, error syslog, top event patterns, combined per-device view, and LLDP/CDP neighbor discovery logs.

© Dynatrace · Apache-2.0 · Dynatrace/dynatrace-for-ai

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой