SNMP es la forma en que CORE-M ingiere desde equipos que nunca ejecutarán un agente de CORE-M — switches, routers, SAIs, PDUs y controladores industriales. A diferencia de los otros protocolos, el dispositivo no envía datos a CORE-M. En su lugar, CORE-M sondea (poll) el dispositivo en busca de valores de OID según una programación y, opcionalmente, recibe traps que el dispositivo emite. Ambos se normalizan: los sondeos se convierten en telemetry, los traps se convierten en eventos de dispositivo.
| Modelo | Dirección | Puerto | Se convierte en |
|---|---|---|---|
| Polling | CORE-M → dispositivo (GET) | 161 | Telemetry (TelemetryPoint) |
| Traps | Dispositivo → CORE-M | 162 | Eventos de dispositivo |
162, que lo normaliza en un evento
de dispositivo.Se admiten tanto SNMP v2c como v3 por objetivo.
v2c se autentica con una community string. Configúrala en el objetivo:
| Campo | Valor |
|---|---|
version | v2c |
community | tu community de lectura (se mantiene secreta, nunca se registra en logs) |
v2c no tiene cifrado — úsalo solo en redes de gestión de confianza.
v3 usa USM (User-based Security Model) con un nombre de usuario y un nivel de seguridad:
| Campo | Valor |
|---|---|
version | v3 |
username | nombre de usuario USM |
security_level | noAuthNoPriv, authNoPriv o authPriv |
auth_protocol | SHA, SHA256 o SHA512 (para authNoPriv / authPriv) |
priv_protocol | AES, AES192 o AES256 (para authPriv) |
Usa authPriv en producción para un polling autenticado y cifrado.
El device profile mapea cada OID sondeado a un nombre de métrica de CORE-M. Los
valores numéricos de OID aterrizan en numeric_values; todo lo demás aterriza en
string_values. La respuesta del OID se usa solo para el valor — la identidad del
dispositivo y del tenant siempre proviene de la configuración del objetivo, nunca del cable.
| OID | Significado | Métrica de CORE-M |
|---|---|---|
.1.3.6.1.2.1.1.3.0 | sysUpTime | sys_uptime |
.1.3.6.1.2.1.2.2.1.10.1 | ifInOctets (if 1) | if1_in_octets |
.1.3.6.1.2.1.2.2.1.16.1 | ifOutOctets (if 1) | if1_out_octets |
.1.3.6.1.4.1.318.1.1.1.2.2.1.0 | capacidad de batería del SAI | ups_battery_pct |
Por ejemplo, sondear .1.3.6.1.2.1.1.3.0 en un intervalo de 60 segundos y mapearlo a
sys_uptime publica un TelemetryPoint con numeric_values.sys_uptime cada minuto.
sequenceDiagram
participant DL as poller SNMP de device-link
participant Dev as Dispositivo de red :161
participant RP as Redpanda telemetry.raw.{tenant}
loop cada intervalo de sondeo
DL->>Dev: SNMP GET (OIDs configurados)
Dev-->>DL: Valores de OID
DL->>DL: Mapear OIDs → métricas (identidad desde el objetivo)
DL->>RP: Publicar TelemetryPoint
DL->>DL: Registrar latencia + estado del sondeo
end
Cuando llega un trap desde un dispositivo conocido, el receptor de traps lo normaliza
en un evento de dispositivo y publica device.event.{tenant_id}.{device_id}. Así es como
las condiciones asíncronas (la caída de un puerto, un evento de energía) afloran en CORE-M
sin esperar al siguiente ciclo de sondeo.
Un trap desde una fuente que no coincide con ninguna credencial de objetivo ni mapeo
de gateway se rechaza — no se convierte en un evento. Se incrementa la métrica de
fallo de autenticación corem_protocol_auth_failures_total{protocol="snmp"}. Esto evita
que traps no solicitados o falsificados inyecten eventos para dispositivos que CORE-M no
reconoce.
Recurre a SNMP cuando…
Para dispositivos que controlas de extremo a extremo, un protocolo de push por agente — MQTT, HTTP, o CoAP — da un control más fino y menor latencia.