Differences

This shows you the differences between two versions of the page.

--- gpfs_performance_monitoring [2026/07/31 17:12] – bbruzzo
+++ gpfs_performance_monitoring [2026/08/14 13:56] (current) – [Containerizando el bridge] bbruzzo
@@ Line 1: / Line 1: @@
 ====== Performance Monitoring ======
-La **performance monitoring tool** colecciona métricas de GPFS y provee información de performance del sistema.
+===== Intro a componentes ======
+La [[https://www.ibm.com/docs/en/storage-scale/5.2.3?topic=monitoring-using-performance-tool | performance monitoring tool]] colecciona métricas de GPFS y provee información de performance del sistema.
 Está habilitada por default e incluye //Collectors, Sensors // y // Proxies//.
-===== Collector =====
+==== Collector ====
 Un collector soporta hasta 150 sensor nodes. Con un collector debería ser suficiente para nuestro sistema. Se pueden armar esquemas con más de un collector (multi-collector federation) por razones de escala y de tolerancia a fallas.
@@ Line 11: / Line 14: @@
 Podemos utilizar mmgt01 como Node Collector en el cluster de storage y vlmgt02 en el cluster cliente, ya que es buena práctica mantener servicios extra (como monitoreo) fuera de los quorum nodes.
-===== Sensors =====
+==== Sensors ====
 El componente que recopila datos de performance de un nodo
-===== Proxy =====
+==== Proxy ====
  Se corre un proxy por cada protocolo para recopilar métricas de ese protocolo.
@@ Line 25: / Line 28: @@
 Para eso necesitamos configurar la performance monitoring tool de GPFS.
-==== Configurar performance monitoring tool ====
+==== Resolución de dependencias ====
 Necesitamos los paquetes
@@ Line 133: / Line 136: @@
 systemctl status pmsensors</code>
-===== CherryPy =====
+==== CherryPy ====
 En el nodo collector tiene que estar instalado el paquete de python CherryPy.
+<code>[root@vlmgt02 gpfs_perf_testing]# python -m venv env
+[root@vlmgt02 gpfs_perf_testing]# source env/bin/activate
+(env) [root@vlmgt02 gpfs_perf_testing]# pip install cherrypy</code>
+==== Generación de API Keys ====
+Leer archivo ubicado en ''/data/admin/gpfs_perf_testing/apikey_config.txt''
+==== Set Up de prueba ====
+[[https://github.com/IBM/ibm-spectrum-scale-bridge-for-grafana/releases | Clonar la release
+]]
+Necesitamos python3.11.
+Para una prueba de concepto voy a usar micromamba, pero vamos a tener que containerizar con podman.
+<code>
+curl -Ls https://micro.mamba.pm/install.sh | bash
+source ~/.bashrc
+micromamba create -n grafana_bridge python=3.11 -c conda-forge -y
+micromamba run -n grafana_bridge pip install CherryPy
+micromamba run -n grafana_bridge pip install requests
+micromamba run -n grafana_bridge python zimonGrafanaIntf.py
+</code>
+No está armada la config de perf monitoring
+<code>[root@vlmgt02 source]# micromamba run -n grafana_bridge python zimonGrafanaIntf.py
+-07-31 14:50 - MainThread                               - INFO     -  *** IBM Storage Scale bridge for Grafana - Version: 8.1.3 ***
+-07-31 14:50 - MainThread                               - ERROR    - QueryHandler: getTopology returns no data.
+-07-31 14:50 - MainThread                               - WARNING  - No Metadata results received from the pmcollector. Start retry attempt 1 in 60s (MAX_ATTEMPTS_COUNT:3)
+-07-31 14:51 - MainThread                               - ERROR    - QueryHandler: getTopology returns no data.
+-07-31 14:51 - MainThread                               - WARNING  - No Metadata results received from the pmcollector. Start retry attempt 2 in 60s (MAX_ATTEMPTS_COUNT:3)
+-07-31 14:52 - MainThread                               - ERROR    - QueryHandler: getTopology returns no data.
+-07-31 14:52 - MainThread                               - WARNING  - No Metadata results received from the pmcollector. Start retry attempt 3 in 60s (MAX_ATTEMPTS_COUNT:3)
+%s Server internal error occurred. Reason: Empty results received
+-07-31 14:53 - MainThread                               - ERROR    - Metadata could not be retrieved. Check log file for more details, quitting
+</code>
+==== Containerizando el bridge ====
+Utilizamos podman en mmgt02
+<code>systemd-run --pty --wait -p User=podman -p PAMName=login /bin/bash</code>
+Actualmente estamos trabajando con la [[https://github.com/IBM/ibm-spectrum-scale-bridge-for-grafana/releases/tag/v9.1.0
+ | release 9.1.0]] del bridge.
+Tiene un bug que debemos parchear para poder ver correctamente las métricas que son counters.
+Editar el archivo source/prometheus.py
+Cambiar la sección que figura como:
+<code>
+-        if self.raw_data or "counter" in self.TOPO.getSensorMetricTypes(sensor).values():
+:            attrs.update({'nsamples': period, 'rawData': True, 'skipNullValues': True})
+-            self.logger.debug(MSG['SensorForceRawData'].format(sensor))
+</code>
+Para que skipNullValues sea False
+<code>
+-        if self.raw_data or "counter" in self.TOPO.getSensorMetricTypes(sensor).values():
+:            attrs.update({'nsamples': period, 'rawData': True, 'skipNullValues': False})
+-            self.logger.debug(MSG['SensorForceRawData'].format(sensor))
+</code>
+Esto generaba que se inyecte la flag -s en la REST API de GPFS, que no era soportada. Generaba un log:
+<code>400: unknown option 's',</code>
+<code>
+[podman@vlmgt02 ~]$ cd ibm-spectrum-scale-bridge-for-grafana-9.1.0
+</code>
+Buildeamos la imagen
+<code>podman build --format=docker -t bridge_image:latest .</code>
+Generamos unit file en /opt/containers/.config/containers/systemd/monitoring/gpfs-bridge.container
+El contenido del unit file es:
+<code>
+[Unit]
+Description=GPFS Grafana Bridge
+After=pmcollector.service
+[Container]
+ContainerName=gpfs_bridge
+Image=localhost/bridge_image:latest
+Volume=/opt/IBM/zimon/ZIMonSensors.cfg:/opt/IBM/zimon/ZIMonSensors.cfg:ro
+Volume=/opt/containers/monitoring/gpfs_bridge/config.ini:/opt/IBM/bridge/config.ini:ro
+Volume=/opt/IBM/zimon/defaults:/opt/IBM/zimon/defaults:ro
+Network=host
+[Install]
+WantedBy=default.target
+</code>
+Asegurarse que los permisos de /opt/IBM/zimon sean lo suficientemente permisivos para que el usuario podman pueda leer sus contenidos. Tuvimos que editar esto.
+Luego se puede lanzar o detener el container con systemd.
+<code>
+podman $  systemctl --user daemon-reload
+podman $  systemctl --user start gpfs-bridge
+podman $  podman logs gpfs_bridge
+</code>