Differences

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

--- gpfs_performance_monitoring [2026/07/31 19:32] – podman config bbruzzo
+++ gpfs_performance_monitoring [2026/08/14 13:56] (current) – [Containerizando el bridge] bbruzzo
@@ Line 1: / Line 1: @@
 ====== Performance Monitoring ======
+===== 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 145: / Line 148: @@
 Leer archivo ubicado en ''/data/admin/gpfs_perf_testing/apikey_config.txt''
-==== Set Up ====
+==== Set Up de prueba ====
 [[https://github.com/IBM/ibm-spectrum-scale-bridge-for-grafana/releases | Clonar la release
@@ Line 177: / Line 180: @@
 </code>
-=== Containerizando el bridge ===
+==== Containerizando el bridge ====
-Como vamos a correr el bridge en un nodo con un collector, necesitamos setear podman para esos nodos, ya que solo está configurado en mmgt02 y vlmgt01 que son quorum nodes de sus respectivos clusters.
+Utilizamos podman en mmgt02
-Podman ya está instalado en todos los nodos, pero necesitamos crearle un usuario y asignarle subuid y subgid.
+<code>systemd-run --pty --wait -p User=podman -p PAMName=login /bin/bash</code>
-En vlmgt01:
+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>
-mkdir /opt/containers
+-        if self.raw_data or "counter" in self.TOPO.getSensorMetricTypes(sensor).values():
-useradd -r -d /opt/containers -s /usr/sbin/nologin podman
+:            attrs.update({'nsamples': period, 'rawData': True, 'skipNullValues': True})
-chown -R podman:podman /opt/containers
+-            self.logger.debug(MSG['SensorForceRawData'].format(sensor))
-echo "podman:500000:65536" >> /etc/subuid
-echo "podman:500000:65536" >> /etc/subgid
 </code>
-Ya podemos usar podman en vlmgt01.
+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>
-<code>systemd-run --pty --wait -p User=podman -p PAMName=login /bin/bash</code>