Introducción
Si tenés un cluster de Kubernetes con Prometheus scrapeando métricas de latencia del API server, sabés exactamente cuál es el problema: cada componente emite una familia de series temporales (_bucket, _count, _sum) con etiquetas le fijas, y para calcular un P99 tenés que interpolar entre buckets que quizás no cubren el rango donde realmente cae tu distribución. En Kubernetes v1.37, SIG Instrumentation resolvió esto de raíz al habilitar por default el feature gate NativeHistograms, heredado de la fase Alpha introducida en v1.36 bajo KEP-5808. No es un cambio cosmético: altera cómo se almacena, se transmite y se consulta la información de duración y latencia en todo el control plane y en los nodos.
La transición está diseñada para no romper tu stack de observabilidad existente, pero eso no significa que puedas ignorarla. Si tu Prometheus no negocia el formato Protobuf con los endpoints de Kubernetes, vas a seguir scrapeando buckets clásicos y te vas a perder la mejora. Y si migrás mal, perdés alertas.
Qué ocurrió
El 11 de septiembre de 2026, Kubernetes publicó la release v1.37 con NativeHistograms en estado Beta y activado por default. Esto significa que cualquier componente que utilice el paquete k8s.io/component-base/metrics —el subsistema compartido de métricas— ahora expone histogramas en dos formatos simultáneamente: el clásico (buckets acumulativos con etiquetas le) y el nativo (spans exponenciales dentro de una única serie temporal).
La decisión de SIG Instrumentation responde a tres limitaciones concretas de los histogramas clásicos. Primero, la cardinalidad: un histograma con 11 buckets genera 12 series temporales por cada combinación de labels, y en clusters con múltiples namespaces y verbos HTTP eso escala de forma incontrolable. Segundo, la pérdida de precisión: si tu P99 cae entre los buckets 0.5 y 1, Prometheus interpola linealmente y el error puede superar el 30%. Tercero, la rigidez: los límites los define el autor del métrico en tiempo de compilación, no el operador en tiempo de consulta.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos que operan clusters a escala, el impacto se mide en tres frentes. En almacenamiento de series temporales, una métrica como apiserver_request_duration_seconds que antes generaba 12 series por label set ahora produce una sola serie con estructura interna. En clusters grandes con cientos de label combinations, esto reduce el footprint de TSDB entre un 60% y un 80% según mediciones del propio equipo de Prometheus con benchmarks de carga similar.
En scraping, el cambio de formato de texto plano a Protobuf reduce el volumen de bytes transferidos por scrape, lo que alivia la red entre Prometheus y los endpoints de /metrics. Para infraestructuras donde el scraping cruza zonas o VPCs, esto se traduce en menor ancho de banda consumido.
En consultas, histogram_quantile() sobre nativos elimina la interpolación entre buckets discretos. Los quantiles se calculan directamente sobre los spans exponenciales, lo que produce valores más cercanos a la distribución real de latencias. Para equipos de SRE que definen SLOs basados en P95 y P99, esto significa alertas con menos falsos positivos por error de interpolación.
El riesgo operativo principal es la migración. Si desactivás la exposición clásica antes de migrar dashboards y alertas, todo lo que use histogram_quantile(…_bucket…) deja de funcionar.
Detalles técnicos
La implementación vive en k8s.io/component-base/metrics y se propaga automáticamente a kube-apiserver, kube-scheduler, kube-controller-manager, kubelet y kube-proxy. No requiere configuración por componente: activar el feature gate basta.
El esquema nativo de un histograma contiene campos como schema (factor de escala exponencial), zero_threshold, zero_count, positive_span y negative_span. Cada span representa una secuencia de buckets contiguos con conteos, eliminando la necesidad de emitir un le por cada límite.
La dualidad de exposición funciona así: el endpoint /metrics responde en formato texto clásico cuando el scraper pide Accept: application/openmetrics-text o text/plain. Si el scraper negocia Accept: application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited, el componente devuelve la estructura Protobuf con ambos formatos dentro del mismo MetricFamily.
Podés verificar que un componente exporta nativos con:
curl -s -H «Accept: application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited» \
http://kube-apiserver:6443/metrics | \
protoc –decode=io.prometheus.client.MetricFamily \
<(find / -name "io.prometheus.client.MetricFamily" 2>/dev/null) | \
grep -A 20 «apiserver_request_duration_seconds»
En la salida, además de las entradas bucket, vas a ver campos schema, positive_span y zero_count poblados.
En Prometheus 3.0+, la configuración de scraping se hace por job (la flag global –enable-feature=native-histograms está deprecada desde 3.9):
scrape_configs:
– job_name: kubernetes-apiserver
metrics_path: /metrics
scheme: https
scrape_native_histograms: true
always_scrape_classic_histograms: true
static_configs:
– targets: [‘kube-apiserver:6443’]
En Prometheus 2.40 a 2.x, la habilitación es global con la flag –enable-feature=native-histograms al arrancar el binario, y aplica a todos los targets sin excepción.
Qué deberían hacer los administradores y equipos técnicos
Paso 1 — Verificá tu versión de Prometheus. Si estás en 2.40 o superior, podés consumir nativos. Si estás por debajo, actualizá primero. Para Prometheus 3.0+, confirmá que no dependés de la flag global deprecada y migrá a scrape_native_histograms: true por job.
Paso 2 — Seteá always_scrape_classic_histograms: true en cada job. Esto garantiza que Prometheus ingiera ambos formatos durante la transición. Sin esta línea, en cuanto el scraper negocie Protobuf, deja de recibir las series _bucket, _count y _sum, y todo dashboard con histogram_quantile() sobre sufijo _bucket muestra datos vacíos.
Paso 3 — Auditá dashboards y alertas. Buscá en tu repo de dashboards (JSON de Grafana, reglas de alerting) cualquier expresión que contenga _bucket, le=», o histogram_quantile aplicado sobre series con sufijo clásico. Anotá cuáles necesitás migrar a la sintaxis nativa, donde histogram_quantile() opera directamente sobre la serie sin le.
Paso 4 — Migrá consultas de forma gradual. PromQL sobre nativos no requiere sufijos ni etiquetas le. Una consulta tipo:
histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le, verb))
se simplifica a:
histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds[5m])) by (verb))
Probá ambas en paralelo durante un sprint completo. Compará resultados y confirmá que no hay regresión en las alertas antes de retirar la consulta clásica.
Paso 5 — Monitoreá el cardinality de tu TSDB. Después de activar scraping nativo, compará prometheus_tsdb_head_series antes y después. Si no ves reducción, verificá que el formato Protobuf se está negociando correctamente y que no estás cayendo silenciosamente al texto plano.
Conclusión
Native Histograms en Beta no es un feature opcional que podés posponer indefinidamente. Al estar habilitado por default en v1.37, tus componentes ya están emitiendo datos en el nuevo esquema. Lo que falta del lado tuyo es que Prometheus sepa consumirlo y que tus dashboards aprovechen la mayor precisión sin depender de buckets fijos. La ventana de dualidad existe, pero SIG Instrumentation ya anticipó que, una vez que la adopción nativa sea ubicua en el ecosistema, los buckets estáticos clásicos van a entrar en camino de deprecación. Equipos que planifiquen la migración ahora evitan una ruptura forzada en releases posteriores.