Reunión sobre Monitoreo

GCBA - ASI / 2018-09-19

Participantes

GCBA

• Gustavo Chuliver (GC)
• Sebastián Kroupa (SK)
• Martín Montero (MM)

(por favor, agregar los que faltan)

CABASE

• Andrés Pugawko (AP)

DGSI-SLyT

• Rodrigo Jiménez (RJ)

NIC.ar

• Robert Martin-Legène (RML)
• Mariano Absatz (MA)

Temas

• Monitorear todos los nodos selladores

• Monitorear todos los nodos gateway

• Monitorear parámetros de host (memoria, cpu, espacio en disco, etc)

• Monitorear parámetros de aplicación (normalmente se hace sobre un geth local)

• El monitoreo del NOC debe ser público. Es decir, quien opere el NOC de BFA no puede agregarlo directamente dentro de su propio esquema de monitoreo (aunque podría hacerlo "en paralelo" al monitoreo público si lo prefiere)

• La recolección de datos debería ser agnóstica a la herramienta de monitoreo

Sin embargo, RJ plantea que el modo de tomar información por parte de, por ejemplo, Zabbix, es específica de la herramienta, con lo cual dependerá de quién opere el NOC cómo se desarrollen los colectores.

RML plantea que independientemente del poll que se haga remotamente de la información, la misma debería guardarse localmente a intervalos regulares en cada host en un formato agnóstico (por ejemplo JSON), de modo tal que si se pierde conectividad entre el host y el NOC, pero el host sigue funcionando, no se pierdan lecturas por este hecho (cosa que ocurriría si la lectura sólo se dispara vía polling).

• GCBA-ASI utiliza Nagios y PRTG
• CABASE utiliza Observium y SmokePing
• SLyT-DGSI utiliza Zabbix

SK y MM plantean que de todos modos, dado que se define que el monitoreo del NOC estará separado del monitoreo de la entidad que opere el NOC, hay más libertad en la elección. RJ asiente, pero opina que debería ser una herramienta con la que el operador del NOC tenga experiencia y se sienta cómodo.

• Puede haber más de un NOC (operado por entidades distintas) pero todos los NOC monitorean toda la red (todos los nodos y todos los parámetros). Los múltiples NOC no serían complementarios sino redundantes.
• Los operadores de nodos selladores y gateways deben estar obligados a proveer la información de monitoreo al(os) NOC (esto debe ser agregado en el reglamento interno)
• Se conversó la posibilidad de monitorear asimismo nodos transaccionales que lo soliciten

Se plantea que además de enviar alertas (mail, sms, telegram, etc) ante eventos que se definan, debe haber una herramienta que permita ver y analizar el comportamiento histórico, que permita identificar qué es normal y qué no, tendencias de crecimiento, etc.

MM plantea el uso de Pentaho. También se propone el uso de Elastic y Kibana.