En l'ecosistema de Kubernetes, l'escalabilitat basada únicament en CPU i memòria es queda curta per a la majoria dels escenaris reals. Un clúster pot tenir els seus nodes amb recursos sobrats, però si una cua de missatges creix sense control o el nombre de connexions WebSocket es dispara, el rendiment se'n ressent. Per capturar aquests senyals —com la profunditat d'una cua, la durada de processos batch o la latència de peticions— es necessita un exportador de mètriques personalitzat. Aquest article explica com dissenyar-ne un des de zero, empaquetar-lo com a contenidor i integrar-lo amb Prometheus, tot això amb un enfocament pràctic i professional. A més, veurem com empreses com Q2BSTUDIO apliquen aquestes tècniques en projectes d'aplicacions a mida per oferir solucions de monitoratge avançades.
Un exportador de mètriques no és més que un petit servidor HTTP que exposa dades en un endpoint /metrics en format de text pla que Prometheus sap interpretar. Hi ha llibreries client per a diversos llenguatges; aquí farem servir Go, molt estès al món Kubernetes pel seu rendiment i perquè els components oficials de l'orquestrador també estan escrits a Go. La decisió de construir un exportador separat —i no instrumentar l'aplicació directament— sol venir motivada perquè la font de dades és externa (una base de dades, un broker de missatges) o perquè no disposem del codi de l'aplicació. En qualsevol cas, el patró és el mateix: un bucle que recol·lecta valors i els actualitza en les mètriques registrades.
Abans d' escriure codi, convé triar el tipus de mètrica adequat. Prometheus ofereix tres primitives: counter (només augmenta, ideal per a totals com peticions ateses), gauge (puja i baixa, perfecte per a cues, connexions actives o temperatura) i histogram (distribució de valors, com temps de resposta, que permet calcular percentils). La convenció de nomenat és namespace_nombre_unidad en snake_case, per exemple cola_procesos_pendientes (gauge) o cola_tiempo_procesamiento_segundos (histogram). Un nom clar estalvia dolors de cap en depurar alertes o panells a Grafana.
Muntar el projecte Go és senzill: es crea un mòdul, s'afegeix la dependència de prometheus/client_golang i es declaren les mètriques amb les opcions adequades. És recomanable registrar-les en el registre per defecte de Prometheus usant MustRegister perquè qualsevol duplicat es detecti en arrencar. Després, un bucle en una gorutina actualitza els valors periòdicament: per exemple, cada cinc segons es llegeix la profunditat d'una cua real (o simulada) i s'anomena a Set() per a un gauge o a Inc() per a un counter. La durada de cada treball es mesura amb Observe() en l' histograma. L'interval de mostreig ha de ser menor que el de scrape de Prometheus (per defecte 15 segons) perquè cada recol·lecció vegi dades fresques.
El servidor HTTP es configura amb promhttp. Handler() per exposar les mètriques i un endpoint /healthz per a les sondes de Kubernetes. En executar localment, podem verificar amb curl localhost:8080/metrics | grep cola_ que les línies HELP i TYPE apareixen correctament. Un cop funciona, s'ha de fer. Una bona pràctica és usar compilació multi-etapa: en la primera es genera un binari estàtic (sense CGO), en la segona es copia a una imatge lleugera com a distronòbils/static:nonroot, que a més executa com a usuari no root, millorant la seguretat. La imatge es construeix amb Docker o Buildah i es puja a un registre.
El desplegament al clúster requereix dos manifestos: un Deployment i un Service. El Deployment defineix un contenidor amb recursos conservadors (50m CPU, 32Mi RAM com a requests) i una sonda de vida contra /healthz. El Service exposa el port 8080 amb nom metrics. Després, la configuració de scraping depèn de com es va instal·lar Prometheus. Si es fa servir el Prometheus Operator (o el chart kube-prometheus-stack), es crea un ServiceMonitor amb el selector adequat i l'etiqueta release: kube-prometheus-stack. Per a configuracions basades en anotacions, s'afegeixen prometheus.io/scrape: 'true' i prometheus.io/port: '8080' al Podeu. Després d'aplicar els manifestos, es verifica en la interfície de targets de Prometheus que l'estat sigui UP.
Amb les mètriques ja a Prometheus, el següent pas natural és fer que l'HoritzontalPodAutoscaler (HPA) de Kubernetes pugui fer-les servir per escalar pods. Però l'HPA no consumeix directament mètriques de Prometheus; necessita un adaptador que exposi les dades a través de l'API de mètriques personalitzades de Kubernetes. El Prometheus Adapter compleix aquest rol. Un cop instal·lat, es poden definir regles que mapegin una consulta PromQL —per exemple sum(worker_queue_depth)— a un recurs de l'API de mètriques. Llavors qualsevol HPA pot referenciar aquesta mètrica i escalar en funció de la profunditat de la cua, no només de CPU. Aquest enfocament és el que moltes organitzacions adopten per automatitzar l' escalabilitat en entorns de producció amb pics de càrrega impredictibles.
Q2BSTUDIO, com a empresa especialitzada en tecnologia, integra aquestes capacitats en els seus projectes d ' IA per a empreses i programari a mida. Per exemple, en solucions d'intel·ligència artificial que processen grans volums de dades, els exportadors de mètriques permeten monitoritzar el rendiment dels models, la latència d'inferència o l'ús de GPUs. A més, combinats amb serveis cloud AWS i Azure i serveis intel·ligència de negoci com Power BI, ofereixen panells complets on conflueixen mètriques tècniques i de negoci. Fins i tot es poden construir agents IA que actuïn automàticament en detectar certs llindars, tot sobre una base de ciberseguretat robusta. La capacitat de dissenyar exportadors a mida és clau per a qualsevol empresa que vulgui escalar de forma intel·ligent i basada en dades reals.
Un bon exportador no només exposa números; és el pont entre el comportament real de l' aplicació i les decisions d' infraestructura. La combinació de Kubernetes, Prometheus i adaptadors de mètriques permet crear sistemes auto-regulables que responen a la demanda sense intervenció manual. Per a equips que treballen amb aplicacions a mida, aquesta arquitectura es torna indispensable quan els indicadors tradicionals ja no n'hi ha prou. Si a més es necessita integrar fonts de dades externes o heretades, un exportador personalitzat és la solució més neta i mantenible.
En resum, el procés per construir un exportador de mètriques personalitzat per a Kubernetes inclou: triar el tipus de mètrica, escriure el recol·lector a Go, contenidor amb multi-stage, desplegar amb Deployment i Service, configurar l'scraping a Prometheus, i finalment connectar amb l'HPA mitjançant un adaptador. Cada pas té les seves bones pràctiques, que hem recorregut de forma general. Amb aquesta base, qualsevol equip pot ampliar el monitoratge del seu clúster més enllà dels límits de CPU i memòria, i prendre decisions d' escalat basades en senyals de negoci reals.
