Arquitectura de Prometheus¶

Prometheus es una plataforma de monitorización basada en series temporales. Su función principal es recopilar métricas de diferentes objetivos, almacenarlas y permitir su consulta mediante PromQL.

En este bloque se utilizará una arquitectura formada por:

Sistema operativo
        |
        v
Node Exporter
        |
        | Scraping HTTP
        v
Prometheus
        |
        | Consultas PromQL
        v
Grafana
        |
        v
Dashboards

La arquitectura sigue normalmente un modelo pull: Prometheus consulta periódicamente los endpoints de métricas de los sistemas monitorizados.

Objetivos¶

Al finalizar esta sección, el alumno podrá:

Explicar la función de Prometheus dentro de una plataforma de monitorización.
Identificar los componentes principales de la arquitectura.
Diferenciar entre Prometheus, Node Exporter y Grafana.
Explicar el modelo de recopilación pull.
Diferenciar entre un job, un target, una métrica y una serie temporal.
Comprender la función de las etiquetas.
Identificar el endpoint /metrics.
Interpretar la métrica up.
Consultar los objetivos configurados en Prometheus.
Consultar la API HTTP de Prometheus.
Comprender el recorrido de una métrica desde el sistema operativo hasta Grafana.
Diagnosticar dónde puede producirse un error en la cadena de monitorización.

Introducción¶

Una plataforma de monitorización debe responder a preguntas como:

¿Está disponible un servidor?
¿Cuánto CPU está utilizando?
¿Cuánta memoria queda disponible?
¿Qué sistemas de ficheros están próximos a llenarse?
¿Qué cantidad de tráfico circula por una interfaz de red?
¿Desde cuándo está funcionando un servicio?
¿Cuándo comenzó a degradarse el rendimiento?

Prometheus responde a estas preguntas recopilando valores medibles llamados métricas.

Una métrica es un valor asociado a un nombre y, opcionalmente, a un conjunto de etiquetas.

Ejemplo:

node_memory_MemAvailable_bytes 2147483648

Esta métrica indica la memoria disponible expresada en bytes.

Una métrica con etiquetas puede tener esta forma:

node_network_receive_bytes_total{
  device="ens33",
  instance="localhost:9100",
  job="node_exporter"
} 123456789

Las etiquetas permiten distinguir distintas series. Por ejemplo, el tráfico recibido puede medirse por cada interfaz de red.

Componentes de la arquitectura¶

Prometheus¶

Prometheus es el componente central de la plataforma.

Sus funciones principales son:

Consultar objetivos de monitorización.
Recopilar métricas periódicamente.
Almacenar muestras como series temporales.
Asociar etiquetas a los datos.
Ejecutar consultas PromQL.
Evaluar reglas de grabación.
Evaluar reglas de alerta.
Exponer una API HTTP.
Proporcionar una interfaz web.

Prometheus escucha normalmente en el puerto:

URL habitual:

http://localhost:9090

Flujo interno simplificado¶

Configuración
      |
      v
Descubrimiento de objetivos
      |
      v
Scraping
      |
      v
Procesamiento de etiquetas
      |
      v
Almacenamiento local
      |
      v
Consultas PromQL

Node Exporter¶

Node Exporter es un componente que expone métricas del sistema operativo.

Recopila información como:

Tiempo de CPU.
Memoria.
Sistemas de ficheros.
Interfaces de red.
Tiempo de actividad.
Procesos.
Información del kernel.
Carga del sistema.

Node Exporter no suele enviar los datos directamente a Prometheus. En su lugar, publica un endpoint HTTP que Prometheus consulta.

Endpoint habitual:

http://localhost:9100/metrics

Puerto habitual:

Ejemplo de consulta:

curl http://localhost:9100/metrics

Ejemplo de respuesta:

# HELP node_memory_MemAvailable_bytes Memory information field MemAvailable_bytes.
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 2.147483648e+09

La respuesta contiene:

Comentarios de ayuda.
Tipo de métrica.
Nombre de la métrica.
Etiquetas, si existen.
Valor actual.

Exporters¶

Un exporter es un componente que transforma información de un sistema en métricas que Prometheus puede consultar.

No todos los sistemas exponen métricas en el formato de Prometheus. Un exporter actúa como adaptador.

Ejemplos:

Exporter	Sistema monitorizado
Node Exporter	Sistema operativo
MySQL Exporter	MySQL
PostgreSQL Exporter	PostgreSQL
Blackbox Exporter	HTTP, DNS, ICMP y TCP
SNMP Exporter	Dispositivos de red mediante SNMP
Windows Exporter	Servidores Windows

El patrón general es:

Sistema o aplicación
          |
          v
Exporter
          |
          v
Endpoint /metrics
          |
          v
Prometheus

Grafana¶

Grafana es la herramienta utilizada para visualizar los datos almacenados en Prometheus.

Grafana no sustituye a Prometheus:

Prometheus recopila y almacena métricas.
Grafana consulta y representa esas métricas.
PromQL se utiliza para obtener los datos desde Prometheus.
Grafana puede utilizar otras fuentes de datos además de Prometheus.

Puerto habitual:

URL habitual:

http://localhost:3000

Flujo entre Grafana y Prometheus:

Usuario
   |
   v
Grafana
   |
   | Consulta PromQL
   v
Prometheus
   |
   | Devuelve series temporales
   v
Grafana muestra un panel

Modelo de recopilación¶

Modelo pull¶

Prometheus utiliza normalmente un modelo pull. Esto significa que Prometheus inicia la conexión con el objetivo y solicita sus métricas.

Prometheus ---- HTTP GET /metrics ----> Node Exporter
Prometheus <--- Respuesta con métricas -- Node Exporter

La configuración determina:

Qué objetivos se consultan.
Cada cuánto tiempo se consultan.
Qué etiquetas se asignan.
Qué protocolo y ruta se utilizan.

Ventajas del modelo pull:

Prometheus controla el intervalo de recopilación.
Es sencillo comprobar si un objetivo responde.
La configuración está centralizada.
Se puede detectar si un objetivo está caído.
No es necesario configurar cada exporter para enviar datos.

Modelo push¶

En un modelo push, el sistema monitorizado inicia la comunicación y envía los datos hacia otro componente.

Aplicación ---- métricas ----> Receptor

Prometheus no utiliza normalmente este modelo para la monitorización habitual. Sin embargo, existen mecanismos complementarios, como Pushgateway, para casos concretos.

Comparación¶

Característica	Modelo pull	Modelo push
Quién inicia la conexión	Prometheus	Sistema monitorizado
Configuración principal	Prometheus	Cliente o emisor
Detección de objetivos caídos	Directa mediante `up`	Requiere mecanismos adicionales
Uso habitual en Prometheus	Sí	Casos específicos

Jobs y targets¶

Job¶

Un job es un grupo lógico de objetivos relacionados.

Ejemplo:

job_name: node_exporter

Este trabajo agrupa objetivos que exponen métricas del sistema operativo.

Otros ejemplos:

job_name: prometheus

job_name: database

job_name: web_servers

Target¶

Un target es un endpoint concreto que Prometheus consulta.

Ejemplo:

targets:
  - localhost:9100

Un mismo job puede contener varios objetivos:

- job_name: linux_servers
  static_configs:
    - targets:
        - server-01.example.local:9100
        - server-02.example.local:9100
        - server-03.example.local:9100

Representación:

Job: linux_servers
├── server-01.example.local:9100
├── server-02.example.local:9100
└── server-03.example.local:9100

Ejemplo de configuración¶

scrape_configs:
  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100

En este ejemplo:

Elemento	Valor
Job	`node_exporter`
Target	`localhost:9100`
Protocolo	HTTP
Ruta predeterminada	`/metrics`
Puerto	`9100`

Scraping¶

El scraping es el proceso mediante el cual Prometheus consulta un endpoint de métricas.

La secuencia es:

Prometheus lee su configuración.
Identifica los objetivos.
Espera el intervalo configurado.
Realiza una petición HTTP.
Lee las métricas devueltas.
Aplica etiquetas.
Almacena las muestras.
Actualiza el estado del objetivo.

Configuración básica:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100

La propiedad scrape_interval indica cada cuánto tiempo se consulta un objetivo.

Ejemplo:

global:
  scrape_interval: 30s

En este caso, Prometheus intentará recopilar las métricas cada treinta segundos.

Intervalo global e intervalo específico¶

Es posible definir un intervalo global:

global:
  scrape_interval: 15s

Y sobrescribirlo para un trabajo concreto:

scrape_configs:
  - job_name: node_exporter
    scrape_interval: 10s
    static_configs:
      - targets:
          - localhost:9100

El intervalo específico del trabajo tiene prioridad sobre el intervalo global.

Modelo de datos¶

Series temporales¶

Prometheus almacena los datos como series temporales.

Una serie se identifica mediante:

El nombre de la métrica.
El conjunto de etiquetas.

Ejemplo:

node_memory_MemAvailable_bytes{
  instance="localhost:9100",
  job="node_exporter"
}

Cada muestra contiene:

Un valor.
Una marca temporal.

Representación conceptual:

Métrica + etiquetas + tiempo + valor

Ejemplo:

Nombre:     node_memory_MemAvailable_bytes
Instancia:  localhost:9100
Job:        node_exporter
Timestamp:  2026-09-24 16:30:00
Valor:      2147483648

Etiquetas¶

Las etiquetas permiten añadir contexto a una métrica.

Ejemplo:

node_cpu_seconds_total{
  cpu="0",
  mode="idle",
  instance="localhost:9100",
  job="node_exporter"
}

En este caso:

cpu="0" identifica el procesador.
mode="idle" identifica el modo de CPU.
instance="localhost:9100" identifica el objetivo.
job="node_exporter" identifica el trabajo.

Etiquetas habituales¶

Etiqueta	Significado
`job`	Trabajo al que pertenece el objetivo
`instance`	Dirección del objetivo
`device`	Dispositivo, interfaz o recurso
`mountpoint`	Punto de montaje
`mode`	Modo de una métrica
`cpu`	Identificador de procesador

Tipos de métricas¶

Prometheus utiliza varios tipos de métricas.

Counter¶

Un counter representa un valor acumulativo que normalmente solo aumenta.

Ejemplo:

node_network_receive_bytes_total

Los contadores pueden reiniciarse cuando se reinicia el proceso o el sistema.

Para calcular una velocidad de cambio se utiliza normalmente rate():

rate(node_network_receive_bytes_total[5m])

Gauge¶

Un gauge representa un valor que puede aumentar o disminuir.

Ejemplos:

node_memory_MemAvailable_bytes

node_load1

node_filesystem_avail_bytes

Histogram¶

Un histograma agrupa observaciones en intervalos.

Se utiliza habitualmente para estudiar distribuciones, como latencias de peticiones.

Summary¶

Un summary calcula determinados cuantiles en el cliente que genera la métrica.

En las primeras prácticas se trabajará principalmente con:

counter.
gauge.

La métrica `up`¶

La métrica up es una métrica especial que indica si Prometheus ha podido recopilar métricas de un objetivo.

Ejemplo:

up

Resultado conceptual:

up{instance="localhost:9090",job="prometheus"} 1
up{instance="localhost:9100",job="node_exporter"} 1

Interpretación:

Valor	Significado
`1`	El objetivo respondió correctamente
`0`	El objetivo no respondió correctamente

Filtrar Node Exporter:

up{job="node_exporter"}

Filtrar una instancia:

up{instance="localhost:9100"}

Consultar objetivos caídos:

up == 0

Contar objetivos disponibles:

sum(up)

Contar objetivos caídos:

count(up == 0)

La métrica up indica si Prometheus pudo realizar el scraping. No significa necesariamente que todos los componentes internos del objetivo funcionen correctamente.

Configuración mínima¶

Un fichero de configuración básico puede ser:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - localhost:9090

  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100

Elementos de la configuración¶

`global`¶

Define valores generales:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_interval: frecuencia de recopilación.
evaluation_interval: frecuencia de evaluación de reglas.

`scrape_configs`¶

Contiene la configuración de los trabajos:

scrape_configs:
  - job_name: node_exporter

`job_name`¶

Identifica el trabajo:

job_name: node_exporter

`static_configs`¶

Define objetivos estáticos:

static_configs:
  - targets:
      - localhost:9100

`targets`¶

Lista de endpoints que deben consultarse:

targets:
  - localhost:9100
  - server-02:9100

Etiquetas externas y personalizadas¶

Es posible añadir etiquetas a los objetivos mediante labels.

scrape_configs:
  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100
        labels:
          environment: laboratorio
          team: sistemas

Las etiquetas pueden utilizarse en las consultas:

up{environment="laboratorio"}

node_memory_MemAvailable_bytes{team="sistemas"}

También se pueden definir etiquetas externas para identificar una instalación de Prometheus:

global:
  external_labels:
    environment: laboratorio
    region: madrid

Service discovery¶

En un laboratorio pequeño se pueden definir los objetivos manualmente:

static_configs:
  - targets:
      - localhost:9100

En entornos más grandes, los objetivos pueden descubrirse automáticamente mediante mecanismos como:

DNS.
Kubernetes.
Consul.
EC2.
Azure.
Google Cloud.
Ficheros.
Otros sistemas de descubrimiento.

Ejemplo conceptual mediante fichero:

scrape_configs:
  - job_name: linux_servers
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/*.yml

El descubrimiento permite evitar la modificación constante del fichero principal de Prometheus cuando se incorporan nuevos servidores.

Recorrido completo de una métrica¶

Consideremos la métrica de memoria disponible.

Paso 1: el sistema operativo genera el dato¶

El sistema operativo conoce la memoria total y disponible.

Memoria disponible: 2 GiB

Paso 2: Node Exporter expone la métrica¶

node_memory_MemAvailable_bytes 2147483648

Paso 3: Prometheus realiza el scraping¶

Prometheus consulta:

http://localhost:9100/metrics

Paso 4: Prometheus añade etiquetas¶

node_memory_MemAvailable_bytes{
  instance="localhost:9100",
  job="node_exporter"
} 2147483648

Paso 5: Prometheus almacena la muestra¶

La muestra se guarda con su valor y marca temporal.

Paso 6: PromQL consulta el dato¶

node_memory_MemAvailable_bytes

Paso 7: Grafana representa el resultado¶

Grafana puede mostrar el dato como:

Valor instantáneo.
Serie temporal.
Indicador.
Tabla.
Gráfico de área.
Panel de capacidad.

Ejemplo completo¶

Arquitectura del laboratorio¶

Servidor Ubuntu: 192.168.1.50

+---------------------------------------------------+
|                                                   |
|  Node Exporter                                    |
|  192.168.1.50:9100/metrics                       |
|                                                   |
|  Prometheus                                       |
|  192.168.1.50:9090                               |
|                                                   |
|  Grafana                                          |
|  192.168.1.50:3000                               |
|                                                   |
+---------------------------------------------------+

Configuración¶

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets:
          - localhost:9090

  - job_name: node_exporter
    static_configs:
      - targets:
          - localhost:9100

Comprobación de Node Exporter¶

curl -s http://localhost:9100/metrics \
  | grep '^node_memory_MemAvailable_bytes'

Ejemplo:

node_memory_MemAvailable_bytes 2.147483648e+09

Comprobación del objetivo¶

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | [
        .labels.job,
        .labels.instance,
        .health
      ]
    | @tsv
  '

Ejemplo:

prometheus      localhost:9090  up
node_exporter   localhost:9100  up

Consulta desde PromQL¶

node_memory_MemAvailable_bytes

Consulta filtrada¶

node_memory_MemAvailable_bytes{
  job="node_exporter"
}

Consulta para Grafana¶

100 * (
  1 -
  node_memory_MemAvailable_bytes
  /
  node_memory_MemTotal_bytes
)

Esta consulta calcula un porcentaje aproximado de memoria utilizada.

Sesiones prácticas¶

Sesión 1: identificar los componentes¶

Objetivo¶

Reconocer los componentes que forman la arquitectura del laboratorio.

Actividad¶

Completar la tabla:

Componente	Función	Puerto	¿Inicia la conexión?
Prometheus		9090
Node Exporter		9100
Grafana		3000

Preguntas¶

¿Qué componente recopila las métricas?
¿Qué componente expone las métricas?
¿Qué componente visualiza los datos?
¿Qué componente inicia normalmente el scraping?

Sesión 2: consultar el endpoint de Node Exporter¶

Objetivo¶

Comprobar que Node Exporter expone métricas HTTP.

Comandos¶

curl -I http://localhost:9100/metrics

Mostrar las primeras líneas:

curl -s http://localhost:9100/metrics | head -n 20

Buscar métricas de CPU:

curl -s http://localhost:9100/metrics \
  | grep '^node_cpu_seconds_total' \
  | head

Buscar métricas de memoria:

curl -s http://localhost:9100/metrics \
  | grep '^node_memory_' \
  | head

Buscar métricas de red:

curl -s http://localhost:9100/metrics \
  | grep '^node_network_' \
  | head

Ejemplo de sesión¶

$ curl -I http://localhost:9100/metrics
HTTP/1.1 200 OK
Content-Type: text/plain; version=0.0.4; charset=utf-8

$ curl -s http://localhost:9100/metrics | grep '^node_memory_' | head
node_memory_MemTotal_bytes 4.10437632e+09
node_memory_MemFree_bytes 6.291456e+08
node_memory_MemAvailable_bytes 2.414534656e+09

Actividades¶

Comprueba que el endpoint responde con código 200.
Localiza tres métricas de CPU.
Localiza tres métricas de memoria.
Localiza tres métricas de red.
Identifica las etiquetas presentes.
Explica la diferencia entre MemFree y MemAvailable.

Sesión 3: inspeccionar los objetivos configurados¶

Objetivo¶

Comprobar los jobs, targets y estados detectados por Prometheus.

Consultar todos los objetivos¶

curl -s http://localhost:9090/api/v1/targets | jq

Mostrar la información relevante¶

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | {
        job: .labels.job,
        instance: .labels.instance,
        health: .health,
        scrapeUrl: .scrapeUrl,
        lastError: .lastError
      }
  '

Mostrar solo los objetivos caídos¶

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | select(.health != "up")
    | [
        .labels.job,
        .labels.instance,
        .health,
        .lastError
      ]
    | @tsv
  '

Actividades¶

Cuenta cuántos objetivos hay.
Anota el nombre de cada job.
Anota la dirección de cada target.
Comprueba el estado de salud.
Indica qué error aparece cuando un objetivo está caído.
Relaciona cada objetivo con su puerto.

Sesión 4: experimentar con `up`¶

Objetivo¶

Utilizar up para comprobar la disponibilidad de los objetivos.

Consultas¶

up

up{job="prometheus"}

up{job="node_exporter"}

up == 0

sum(up)

count(up)

Actividades¶

Ejecuta up.
Identifica los objetivos disponibles.
Detén temporalmente Node Exporter:

sudo systemctl stop node_exporter

Espera varios intervalos de scraping.
Ejecuta:

up{job="node_exporter"}

Inicia de nuevo el servicio:

sudo systemctl start node_exporter

Comprueba cuándo vuelve a aparecer como disponible.

Esta práctica debe realizarse únicamente en el entorno de laboratorio. Detener un exporter en un servidor de producción puede generar alertas o pérdida de información.

Sesión 5: seguir una métrica¶

Objetivo¶

Seguir el recorrido de una métrica desde Node Exporter hasta Prometheus.

Paso 1: consultar directamente Node Exporter¶

curl -s http://localhost:9100/metrics \
  | grep '^node_memory_MemAvailable_bytes'

Paso 2: consultar Prometheus mediante la API¶

curl -sG http://localhost:9090/api/v1/query \
  --data-urlencode 'query=node_memory_MemAvailable_bytes' \
  | jq

Paso 3: mostrar únicamente el valor¶

curl -sG http://localhost:9090/api/v1/query \
  --data-urlencode 'query=node_memory_MemAvailable_bytes' \
  | jq -r '.data.result[] | [.metric.instance, .value[1]] | @tsv'

Ejemplo de respuesta¶

localhost:9100    2414534656

Paso 4: consultar la misma métrica en PromQL¶

node_memory_MemAvailable_bytes

Actividades¶

Compara el valor de Node Exporter con el valor de Prometheus.
Explica por qué puede existir una pequeña diferencia temporal.
Identifica las etiquetas añadidas por Prometheus.
Explica qué representa value[1] en la respuesta de la API.

Sesión 6: analizar etiquetas¶

Objetivo¶

Comprender cómo las etiquetas identifican una serie temporal.

Consulta¶

node_cpu_seconds_total

Observar especialmente:

cpu
mode
instance
job

Filtrar por modo¶

node_cpu_seconds_total{
  mode="idle"
}

Filtrar por procesador¶

node_cpu_seconds_total{
  cpu="0"
}

Filtrar por trabajo¶

node_cpu_seconds_total{
  job="node_exporter"
}

Combinar filtros¶

node_cpu_seconds_total{
  job="node_exporter",
  cpu="0",
  mode="idle"
}

Actividades¶

Consulta todas las series de CPU.
Filtra el procesador 0.
Filtra el modo idle.
Combina ambos filtros.
Explica por qué cada combinación representa una serie diferente.

Sesión 7: comprobar el modelo pull¶

Objetivo¶

Observar que Prometheus consulta a Node Exporter.

Paso 1: consultar Node Exporter¶

curl -s http://localhost:9100/metrics | head

Paso 2: revisar la configuración¶

sudo grep -A8 -B2 'node_exporter' /etc/prometheus/prometheus.yml

Paso 3: consultar el objetivo¶

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | select(.labels.job == "node_exporter")
    | [
        .scrapeUrl,
        .lastScrape,
        .lastScrapeDuration,
        .health
      ]
    | @tsv
  '

Actividades¶

Identifica la URL de scraping.
Identifica el momento del último scraping.
Identifica la duración del último scraping.
Comprueba el estado.
Explica qué componente inicia la petición HTTP.

Diagnóstico de la arquitectura¶

Caso 1: Node Exporter no responde¶

Síntoma¶

curl http://localhost:9100/metrics

Devuelve un error de conexión.

Comprobaciones¶

systemctl status node_exporter

sudo ss -lntp | grep ':9100'

sudo journalctl -u node_exporter --no-pager -n 50

Posibles causas¶

El servicio está detenido.
El binario no existe.
El puerto está ocupado.
Hay un error en la unidad de systemd.
El cortafuegos bloquea la conexión.
Node Exporter está escuchando en otra dirección.

Caso 2: Node Exporter responde, pero Prometheus lo muestra como `down`¶

Comprobaciones¶

curl http://localhost:9100/metrics

curl -s http://localhost:9090/api/v1/targets \
  | jq -r '
    .data.activeTargets[]
    | select(.labels.job == "node_exporter")
    | [.health, .lastError, .scrapeUrl]
    | @tsv
  '

Posibles causas¶

El target está mal escrito.
El puerto es incorrecto.
La dirección no es accesible desde Prometheus.
Hay un error de configuración YAML.
El objetivo utiliza HTTPS cuando debería utilizar HTTP.
El cortafuegos bloquea el puerto.

Caso 3: Grafana no muestra datos¶

Comprobaciones¶

Verificar que Prometheus responde:

curl http://localhost:9090/-/healthy

Verificar que existen datos:

curl -sG http://localhost:9090/api/v1/query \
  --data-urlencode 'query=up' \
  | jq

Verificar la fuente de datos en Grafana.
Comprobar que la URL es correcta.
Comprobar que se utiliza el puerto 9090.
Ejecutar primero la consulta:

up

Error habitual¶

Si Grafana y Prometheus están en máquinas diferentes, esta URL puede ser incorrecta:

http://localhost:9090

Debe utilizarse una dirección accesible desde el servidor de Grafana:

http://<IP-DE-PROMETHEUS>:9090

Actividad integradora¶

Objetivo¶

Representar y comprobar la arquitectura completa del laboratorio.

Tareas¶

Dibuja la arquitectura del laboratorio.
Identifica todos los componentes.
Anota los puertos.
Comprueba que Node Exporter responde.
Comprueba que Prometheus puede realizar scraping.
Comprueba la métrica up.
Consulta una métrica de memoria.
Conecta Grafana con Prometheus.
Ejecuta una consulta desde Grafana.
Documenta cualquier error encontrado.

Diagrama que debe completar el alumno¶

________________________
        |
        | ________________________
        v
________________________
        |
        | ________________________
        v
________________________
        |
        | ________________________
        v
________________________

Tabla de resultados¶

Comprobación	Comando o consulta	Resultado
Node Exporter responde
Prometheus está saludable
Target de Node Exporter
`up{job="node_exporter"}`
Métrica de memoria
Fuente de datos de Grafana
Consulta desde Grafana

Puntos clave¶

Prometheus es el componente central de recopilación y consulta.
Node Exporter expone métricas del sistema operativo.
Grafana visualiza los datos obtenidos desde Prometheus.
Prometheus utiliza normalmente un modelo de recopilación pull.
Un job agrupa objetivos relacionados.
Un target es un endpoint concreto.
El endpoint habitual de métricas es /metrics.
La métrica up indica si el último scraping fue correcto.
Un valor up = 1 indica que el objetivo respondió.
Un valor up = 0 indica que el objetivo no respondió correctamente.
Las etiquetas identifican y clasifican las series temporales.
counter representa valores acumulativos.
gauge representa valores que pueden subir o bajar.
rate() se utiliza habitualmente con contadores.
Prometheus almacena muestras asociadas a marcas temporales.
La API HTTP permite consultar objetivos y métricas.
Grafana necesita conectividad con Prometheus.
Un fallo puede producirse en el exporter, en la red, en Prometheus o en Grafana.
La arquitectura debe verificarse de extremo a extremo.
Una métrica visible en Node Exporter no garantiza que ya esté disponible en Prometheus.

Preguntas de comprobación¶

¿Qué función cumple Prometheus?
¿Qué función cumple Node Exporter?
¿Qué función cumple Grafana?
¿Qué significa que Prometheus utilice un modelo pull?
¿Qué es un job?
¿Qué es un target?
¿Qué endpoint expone normalmente Node Exporter?
¿Qué puerto utiliza normalmente Prometheus?
¿Qué puerto utiliza normalmente Node Exporter?
¿Qué indica la métrica up?
¿Qué diferencia existe entre up = 1 y up = 0?
¿Qué es una serie temporal?
¿Para qué sirven las etiquetas?
¿Qué diferencia existe entre un counter y un gauge?
¿Por qué se utiliza rate() con algunas métricas?
¿Qué información contiene una muestra?
¿Qué componente inicia normalmente la petición HTTP de scraping?
¿Qué puede provocar que un target aparezca como down?
¿Por qué una métrica puede aparecer en Node Exporter pero no en Prometheus?
¿Por qué Grafana no debe utilizar localhost para acceder a Prometheus cuando están en equipos diferentes?
¿Qué comando permite consultar los objetivos de Prometheus?
¿Qué comando permite comprobar el endpoint de Node Exporter?
¿Qué consulta muestra todos los objetivos disponibles?
¿Qué consulta muestra únicamente los objetivos caídos?
¿Qué componente almacena las series temporales?

Criterios de finalización¶

La sección se considera superada cuando el alumno puede:

Dibujar la arquitectura de Prometheus.
Explicar la función de cada componente.
Identificar los puertos principales.
Explicar el modelo pull.
Diferenciar job y target.
Consultar el endpoint /metrics.
Consultar la API de objetivos.
Interpretar la métrica up.
Identificar etiquetas de una serie.
Seguir una métrica desde Node Exporter hasta Grafana.
Diagnosticar un objetivo en estado down.
Explicar por qué Grafana necesita acceder a Prometheus.

El recorrido completo que debe comprender el alumno es:

Sistema operativo
        |
        v
Node Exporter expone métricas
        |
        v
Prometheus realiza scraping
        |
        v
Prometheus almacena muestras
        |
        v
PromQL consulta las series
        |
        v
Grafana representa los resultados
        |
        v
El usuario interpreta el estado del sistema

Arquitectura de Prometheus¶

Objetivos¶

Introducción¶

Componentes de la arquitectura¶

Prometheus¶

Flujo interno simplificado¶

Node Exporter¶

Exporters¶

Grafana¶

Modelo de recopilación¶

Modelo pull¶

Modelo push¶

Comparación¶

Jobs y targets¶

Job¶

Target¶

Ejemplo de configuración¶

Scraping¶

Intervalo global e intervalo específico¶

Modelo de datos¶

Series temporales¶

Etiquetas¶

Etiquetas habituales¶

Tipos de métricas¶

Counter¶

Gauge¶

Histogram¶

Summary¶

La métrica up¶

Configuración mínima¶

Elementos de la configuración¶

global¶

scrape_configs¶

job_name¶

static_configs¶

targets¶

Etiquetas externas y personalizadas¶

Service discovery¶

Recorrido completo de una métrica¶

Paso 1: el sistema operativo genera el dato¶

Paso 2: Node Exporter expone la métrica¶

Paso 3: Prometheus realiza el scraping¶

Paso 4: Prometheus añade etiquetas¶

Paso 5: Prometheus almacena la muestra¶

Paso 6: PromQL consulta el dato¶

Paso 7: Grafana representa el resultado¶

Ejemplo completo¶

Arquitectura del laboratorio¶

Configuración¶

Comprobación de Node Exporter¶

Comprobación del objetivo¶

Consulta desde PromQL¶

Consulta filtrada¶

Consulta para Grafana¶

Sesiones prácticas¶

Sesión 1: identificar los componentes¶

Objetivo¶

Actividad¶

Preguntas¶

Sesión 2: consultar el endpoint de Node Exporter¶

Objetivo¶

Comandos¶

Ejemplo de sesión¶

Actividades¶

Sesión 3: inspeccionar los objetivos configurados¶

Objetivo¶

Consultar todos los objetivos¶

Mostrar la información relevante¶

Mostrar solo los objetivos caídos¶

Actividades¶

Sesión 4: experimentar con up¶

Objetivo¶

Consultas¶

Actividades¶

Sesión 5: seguir una métrica¶

Objetivo¶

Paso 1: consultar directamente Node Exporter¶

Paso 2: consultar Prometheus mediante la API¶

Paso 3: mostrar únicamente el valor¶

Ejemplo de respuesta¶

La métrica `up`¶

`global`¶

`scrape_configs`¶

`job_name`¶

`static_configs`¶

`targets`¶

Sesión 4: experimentar con `up`¶

Caso 2: Node Exporter responde, pero Prometheus lo muestra como `down`¶