Observabilidad en Grafana para la Infraestructura Core

¿Te suena eso de “tenemos Grafana pero no lo usamos”? Pues conmigo eso no pasa. En esta entrada te cuento cómo montamos un sistema de monitorización centralizada para una legiónde servicios web detrás de Apache y Nginx, todo orquestado desde Grafana con InfluxDB de fondo. Olvídate de rezar para que llegue el ping por email.

Contexto y estrategia general

Inicialmente, nuestro stack Grafana + InfluxDB estaba dedicado a equipos de red. Tras mover esa parte a PandoraFMS, nos encontramos con un motor infrautilizado. La propuesta fue:

• Resignificar los buckets y métricas, que en esta descripción propongo como ejemplo core_metrics_* para evitar confusiones.
• Etiquetas maestras en Telegraf: env=prod, role=dc/file/nas/cluster, site=es, layer=network/app/db.
• Dashboards temáticos: uno para cada capa (DCs, NAS, clusters, aplicaciones web) y un “master overview” que lo combina todo.

Arquitectura de aplicaciones web

Nuestras aplicaciones web corren sobre Apache (tanto httpd como apache2) escuchando puertos internos. Detrás, un Nginx expone TLS y balancea tráfico. Para cada subdominio:

• Medimos las peticiones que resuelve Nginx directamente (inputs.http_response apuntando a cada Host header).
• Medimos las peticiones que pasan a Apache via /server-status?auto con inputs.http_response y inputs.nginx.
• Añadimos métricas de consultas pesadas en MySQL y tiempos de respuesta para detectar cuellos de botella.

Ejemplo real de panel en Grafana

Este es uno de los panels que usamos para la aplicación de planificación de equipos. Fíjate en cómo combinamos texto, métricas de Loki y de InfluxDB:

{
  "id": 57,
  "title": "sub.dom.example.com",
  "panels": [
    {
      "id": 16,
      "type": "text",
      "title": "Servidor",
      "options": {
        "mode": "markdown",
        "content": "### WEB-SERVER-01\n#### 10.0.2.20"
      }
    },
    {
      "id": 14,
      "type": "gauge",
      "title": "200 OK",
      "targets": [
        {
          "expr": "sum(count_over_time({role=\"httpd\",service=\"plan-pro\",status=\"200\"}[5m]))",
          "datasource": "Loki"
        }
      ],
      "options": { "reduceOptions": { "calcs": ["lastNotNull"] } }
    },
    {
      "id": 17,
      "type": "timeseries",
      "title": "Evolución Peticiones",
      "targets": [
        {
          "expr": "count_over_time({role=\"httpd\",service=\"plan-pro\",log_type=\"access\"}[5m])",
          "datasource": "Loki",
          "legendFormat": "{{method}} {{status}}"
        }
      ]
    },
    {
      "id": 7,
      "type": "timeseries",
      "title": "Latencia",
      "targets": [
        {
          "query": "from(bucket:\"core_metrics_web\") |> range(start: -6h) |> filter(fn: (r) => r._measurement == \"http_response\" and r.service == \"plan-pro\" and r.role == \"httpd\" and r.host == \"web-server-01\") |> filter(fn: (r) => r._field == \"response_time\")",
          "datasource": "InfluxDB"
        }
      ]
    }
  ]
}

Con ese JSON puedes importar el panel y ver cómo:

1. El texto muestra el nombre y IP del host.
2. Un gauge refleja las respuestas 200 OK en los últimos 5 minutos.
3. Una serie temporal muestra la evolución de métodos y códigos de estado.
4. Otro timeseries consulta la latencia real desde InfluxDB.

Telegraf y naming: ejemplos de configuración

# OUTPUT web vs db
[[outputs.influxdb_v2]]
  bucket = "core_metrics_web"
  tagdrop = { role = ["db"] }

[[outputs.influxdb_v2]]
  bucket = "core_metrics_db"
  tagpass = { role = ["db"] }

# inputs/http_response.conf
[[inputs.http_response]]
  urls = ["https://sub.dom.example.com"]
  [inputs.http_response.tags]
    host = "web-proxy-01"
    service = "sub-dom"
    role = "http"

# inputs/mysql_heavy.conf
[[inputs.mysql]]
  servers = ["user:pass@tcp(10.0.2.20:3306)/appdb"]
  [inputs.mysql.tags]
    host = "db-01"
    service = "app-db-heavy"
    role = "db"

Pruebas de carga con k6

import http from 'k6/http';
import { check } from 'k6';
export let options = {
  vus: 50,
  duration: '2m',
  thresholds: { 'http_req_duration': ['p(95)<500'] } }; export default () => {
  let res = http.get('https://sub.dom.example.com');
  check(res, { '200 OK': (r) => r.status === 200 });
};

Resultados: p(95) ~ 350 ms, < 0.5% errores, CPU < 40%.

Debate: Centreon vs Grafana

Centreon sigue al tanto de hardware y SO con SNMP. Grafana se ocupa de la capa app y web a nivel de observabilidad. Cada herramienta saca su mejor baza:

• Centreon: uptime, CPU, memoria, disco.
• Grafana: latencias, códigos HTTP, queries lentas.

Enlace: https://saulot.net/informatica/sistemas/monitorizacion-avanzada-con-centreon/

Futuras integraciones

Planeamos un bridge SNMP→InfluxDB para unificar todo en un único repositorio de series temporales y tener comparativas cruzadas sin entrar en mil sistemas.

Resumen y movidas aprendidas

• Naming consistente: la clave para consultas rápidas.
• Telegraf modular: cada servicio en su propio fichero.
• Dashboards específicos + master overview para visión global.
• Pruebas de carga válidas: calibrar umbrales con datos reales.
• Debate activo: usar Centreon y Grafana para lo que mejor hacen.

¿Listo para llevar tu monitorización al siguiente nivel? ¡Hablemos!