# 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**.