...
Esta funcionalidad permite monitorizar el consumo individual y en conjunto de los notebooks y tener controles sobre los mismos en plataforma (UI de los notebooks). De esta forma podremos conocer el estado de cada Notebook, ver los procesos en ejecución, controlar el estado,…estado…
Funcionamiento de los Notebooks
Para entender la funcionalidad de Monitorización es importante conocer algunos conceptos de los NoteooboksNotebooks.
Modos de ejecución de notebooks
...
Shared → El proceso del intérprete, se comparte con todos los notebooks, de modo que no se pueden hacer ejecuciones paralelas del mismo de este intérprete en varios notebook. El manager es el mismo para ese intérprete. En estos casos, al no estar asociado el intérprete a un notebook, no podrá saberse de forma sencilla cuál es el notebook que ha ejecutado, ya que podrá ir saltando de unos a otros y tendrá que cruzarse la entidad de recursos con la entidad de ejecuciones para poderse conocer el detalle.
Por notebook:
Scoped → El proceso del intérprete es común para todos los notebooks por lo tanto es un manager de varias ejecuciones.
Isolated → El proceso del intérprete está separado también por notebook con lo que el manager sólo maneja un notebook. En este caso, el intérprete estará asociado a un notebook con lo que se podrá saber que notebook es en todo momento por el nombre del intérprete. Si se quiere saber el detalle de párrafos habrá que cruzar la entidad de recursos con la de ejecuciones.
Además, existen los modos de ejecución en k8s de modo que la ejecución de cada notebook se delega en cada pod. El manager se mantiene en este pod a modo de control de los diversos tipos de ejecuciones.
...
Con esta monitorización, cruzada con la anterior, podremos saber el consumo real por párrafo.
...
Reporte de Métricas
Para el reporte de métricas existen dos métodos:
Reporte push desde intérprete → a traves de estas variables de entorno (incluidas en el zeppelin-env.sh) se configura el acceso, vía digital client, a dos entidades sobre las que se insertarán las métricas anteriores.
Code Block | ||
---|---|---|
| ||
#### Monitor reporter zeppelin onesait platform ####
export ZEPPELIN_INTERPRETER_MONITORREPORTER_ENABLE=true
export ZEPPELIN_INTERPRETER_MONITORREPORTER_DIGITALCLIENT_HOST=https://development.onesaitplatform.com/iot-broker
export ZEPPELIN_INTERPRETER_MONITORREPORTER_DIGITALCLIENT_NAME=notebook_metrics_client
export ZEPPELIN_INTERPRETER_MONITORREPORTER_DIGITALCLIENT_INSTANCE=notebook_metrics_client_interpreter
export ZEPPELIN_INTERPRETER_MONITORREPORTER_DIGITALCLIENT_TOKEN=XXXXXXX
export ZEPPELIN_INTERPRETER_MONITORREPORTER_ENTITY_RESOURCES=notebook_metrics_resources
export ZEPPELIN_INTERPRETER_MONITORREPORTER_ENTITY_EXECUTIONS=notebook_metrics_executions |
Reporte desde API Rest de zeppelin → a través de un nuevo api creado (tipo actuator) se podrá conocer el consumo de todos los intérpretes (métrica de recursos). En este caso, no es posible obtener la métrica de ejecución al depender en si de la temporalidad de la misma.
Pasos siguientes:
Tener controles sobre los mismos en plataforma (UI de los notebooks) → poder usar los elementos anteriores en la UI de los notebooks para conocer los activos, poder pararlos de forma sencilla, etc, etc
Dashboard de visualización de métricas de forma sencilla
Limitar el uso de procesos de notebooks tanto por RAM como por CPU