Qué muestran
Un dashboard, renderizado una vez por almacén. Diecisiete secciones, ciento cincuenta y dos paneles, en los mismos sitios y con los mismos títulos sea cual sea la base de datos elegida. Abajo hay una captura por sección, en el orden en que el dashboard las coloca.
Todas las secciones salvo Overview se abren plegadas. Abiertas, las siete primeras eran veintitrés pantallas de teléfono antes de que el lector supiera que había diez más; plegadas, la segunda pantalla de un teléfono es el índice de las dieciséis, cada una a un toque, y Grafana conserva en la URL lo que se abrió. En un escritorio cuesta un clic por sección, y la primera carga pide los paneles de Overview y no todos.
Overview
Sección titulada «Overview»Una cabecera y no un panel: la marca, grande y centrada, el nombre debajo, y bajo el nombre un botón a esta documentación y otro al código, sobre la propia página y sin caja alrededor. Después cuatro grupos de cifras: Repositories (repositorios, estrellas, forks), Traffic in range (visitas, visitantes únicos, clones), Community (seguidores, seguidos, patrocinadores, patrocinados) y Account (contribuciones del último año, edad de la cuenta, vigilados, estrellas dadas, gists, paquetes). Un grupo es un panel de estadística con varios valores y no una tarjeta por cifra: en un escritorio se lee como la fila de tarjetas a la que sustituye, y en un teléfono, donde cada panel es una columna, dieciséis tarjetas eran cuatro pantallas de cifras sueltas y cuatro grupos son una. La variable de repositorio que hay al lado filtra todas las secciones a la vez. Estrellas y forks suman la fila más reciente de cada repositorio y no todas las del rango, porque ambas son estado actual y una suma sobre el rango contaría cada pasada.
Lee gh_account, gh_repo, gh_traffic y gh_contributions_total.
Lifetime
Sección titulada «Lifetime»Seis cifras que son ciertas desde que existe la cuenta, en un solo panel, y una fila por repositorio con su vida entera: pull requests fusionadas y revisadas alguna vez, commits totales, issues abiertas, lo fusionado en repositorios ajenos y lo comentado allí.
Todas las demás secciones cuentan filas dentro del rango del dashboard. Estas no: las cuenta GitHub, en una búsqueda o un campo de GraphQL cada una, y el colector guarda la respuesta como una sola fila. Por eso son instantáneas y por eso ya son correctas en la primera pasada de una instalación nueva, cosa que un contador acumulado por esta herramienta no sería. Es además la forma que un almacén puede responder sin leer todo lo que guarda: InfluxDB 3 Core rechaza una consulta que abra más ficheros que su tope, cuarenta mil donde esto se midió, y “cuántas en total” a partir de una fila por hecho es exactamente esa consulta.
Lee gh_account_total y gh_repo_total.
Audience
Sección titulada «Audience»Visitas, visitantes únicos y clones en el tiempo, los referrers y las rutas principales. GitHub sirve catorce días y reescribe la ventana entera en cada pasada, así que las series se extienden tan atrás como lleve corriendo el colector y no catorce días. Los referrers y las rutas no llevan fecha propia, de modo que son la instantánea más reciente de esa ventana y no una serie.
Lee gh_traffic, gh_traffic_referrer y gh_traffic_path.
Stars and forks
Sección titulada «Stars and forks»Estrellas ganadas en el tiempo, la curva acumulada, estrellas por repositorio,
las cincuenta estrellas más recientes con el usuario y el momento, y forks en el
tiempo. Se nombran los ocho repositorios que más ganaron en el rango y el resto
van a other: de los diecisiete que ganaron alguna estrella en dos años, nueve
ganaron entre una y tres, y diecisiete entradas de leyenda escondían un tercio
del trazado. La curva acumulada se remonta a la primera estrella porque el recorrido
de stargazers recogió cada una con su propio starred_at, no porque el colector
lleve corriendo tanto tiempo. Los forks en el tiempo se dibujan igual desde
gh_fork, cada fork con la fecha en que se hizo, así que también se remontan
más allá del día en que arrancó el colector en vez de empezar en la primera
instantánea. Las dos curvas se dibujan hasta los dos bordes del rango: un
recuento acumulado sobre filas fechadas solo tiene punto donde hay fila, así
que una curva de forks sobre un mes tranquilo era una línea del primer fork al
último y nada a los lados, lo que se lee como que la recogida se paró. Cada
extremo lleva un bucket de cero, así que la línea mantiene su valor hasta el
final del rango.
Lee gh_star y gh_repo.
Contributions
Sección titulada «Contributions»El calendario de contribuciones como serie y después como la rejilla que dibuja GitHub, una columna por semana y una fila por día de la semana, con el tono de cada celda en función del recuento de ese mismo día; commits por semana, los totales del último año y la mezcla que forman esos totales, los cuatro tipos de contribución como partes de su suma, que es el radar que dibuja el perfil, al lado de la rejilla como lo pone el perfil; commits por hora del día y por día de la semana, commits por repositorio y una fila por cada año pasado. La rejilla es un panel de historial de estado sobre un campo por día de la semana, porque Grafana no tiene panel de calendario y ese es el único panel del núcleo que dibuja una rejilla de celdas coloreadas por valor. Es la rejilla de GitHub medida en la página del perfil el 2026-09-14 y copiada: diez unidades de ancho por cinco dibujan la celda del propio perfil, diez píxeles en cuadro en una ventana de 1920, con una separación de tres a cuatro píxeles a lo ancho y de cinco a seis a lo alto, donde la del perfil son tres en ambos ejes; los cuatro verdes son los del tema oscuro de GitHub leídos de esa misma página ese mismo día, sobre el gris de un día vacío; tres filas llevan nombre, lunes, miércoles y viernes, como las nombra el perfil; y el tono son los quintos del día más activo del año, la regla que reprodujo los 366 cuadrados del perfil al aplicarla a los recuentos del propio GitHub. El panel mantiene ese año sea cual sea el rango del dashboard, igual que la rejilla del perfil es siempre de un año: a cinco años esas mismas 53 columnas serían 262 de seis píxeles, y a una semana, dos barras. Tres cosas que un panel del núcleo de Grafana no puede copiar. El nombre del mes sobre la primera semana de cada mes: un historial de estado construye sus propias marcas del eje x, una cada varias columnas, así que una marca siempre cae en una semana y el paso depende del ancho en píxeles del panel, que a tres semanas escribe el mismo mes dos veces; en su lugar las marcas nombran el domingo en que empieza cada columna, que no se repite en ninguna otra. El cuadrado a cualquier tamaño: la celda es una fracción de la banda que recibe su fila, así que el cuadrado aguanta a 1920 y otra vez a 768, donde el panel ocupa todo el ancho de un teléfono, y entre medias se mantienen los diez píxeles de alto mientras el ancho se estrecha, ocho a 1600, siete a 1280, cinco a 430; y donde el panel está en el dashboard se estira hasta una barra alta al maximizarlo, 27 por 67 píxeles en una ventana de 1920 por 900 y 27 por 84 en una más alta. Y un tooltip que diga el día y el recuento, porque la celda se colorea por el valor que lleva, así que ese valor tiene que ser el tono y una columna es una semana. Los dos punch cards son estado actual y no historia: cada pasada reescribe la rejilla entera, así que una suma sobre un rango cuenta todas las pasadas y lo que se lee en esos paneles es la forma.
Lee gh_contribution_day, gh_commits_week, gh_contributions_total,
gh_commit_punchcard, gh_contribution_repo y gh_contribution_year.
Pull requests and issues
Sección titulada «Pull requests and issues»Catorce paneles, y la sección donde la recolección por elemento se paga sola. Fusionados, tiempo hasta fusionar, tiempo hasta la primera revisión, issues cerrados, tiempo hasta cerrar y líneas cambiadas como un grupo de seis valores; luego el mismo reparto por estado en el tiempo, las pull requests fusionadas más grandes y los desgloses por autor, por repositorio y por revisor. Un elemento que sigue abierto se escribe una vez al día mientras lo esté, y esas filas se quedan cuando se cierra, así que los paneles fechados cuentan los abiertos como números distintos bajo “Open that day” y los dibujan como una línea junto a la pila de lo que se cerró, y las tablas de “open the longest” leen cada elemento de su fila más reciente.
Lee gh_pull_request, gh_pull_request_review y gh_issue.
Continuous integration
Sección titulada «Continuous integration»Catorce paneles: número de ejecuciones, tasa de éxito sobre las ejecuciones que acabaron bien o mal, las canceladas y omitidas al lado, duración, espera en cola, almacenamiento de artefactos y tamaño de la caché, las siete como un solo grupo; luego las mismas cifras en el tiempo, los workflows, los jobs y los pasos más lentos, y luego los seis que dicen qué hacer al respecto: minutos gastados en ejecuciones que fallaron, los workflows que fallan siempre, el paso que falla en vez del job, los workflows declarados que nunca se han ejecutado, los artefactos creados en el tiempo y cuánto del almacenamiento de artefactos se llegó a contar.
La espera en cola es una cifra de job. La de la ejecución mete la espera dentro de la duración, así que una ejecución que tardó veinte minutos porque un job esperó dieciocho por un runner es idéntica a una que pasó dieciocho ejecutando.
Dos de ellos son los primeros que hay que mirar. “Workflows that keep failing”
no va de flakiness: medido, dos workflows habían fallado en todas y cada una de
sus ejecuciones, decenas de ejecuciones cada uno, y nadie los había apagado.
“Workflows that never ran” es la otra cara de lo mismo, y necesita
gh_workflow y gh_workflow_run a la vez, que es por lo que es el único panel
aquí que solo pueden responder los dos almacenes SQL.
“Artifact storage counted” existe porque el total es un suelo. GitHub dice cuántos artefactos tiene un repositorio, el colector anota cuántos recorrió de verdad, y cuando el segundo es menor el tamaño vivo se queda corto: en un repositorio de aquí, por un factor de cincuenta y seis.
Lee gh_workflow_run, gh_workflow_job, gh_workflow_step, gh_workflow,
gh_artifact, gh_artifact_total y gh_actions_cache.
Commits, líneas añadidas y eliminadas, la proporción de commits firmados, líneas cambiadas en el tiempo, actividad del repositorio por tipo, commits por autor y por firma, y los force push con quién los hizo y en qué rama.
signature distingue unsigned, que significa que no había firma en absoluto,
de una firma que no se pudo verificar. Son hechos distintos y el gráfico de
barras los mantiene separados.
Los tres últimos paneles van de la puerta, no del código. “Commits by
gate state” no dice lo mismo que una ejecución fallida: una ejecución dice que
falló un job, el rollup dice que el commit salió en rojo, y en la cuenta medida
veintisiete de cincuenta commits de la rama principal salieron así. “Checks that
are not Actions” guarda lo que las dos secciones anteriores no ven, el servicio
de calidad de código y el bot de dependencias. Y “Commits behind a red branch”
une los dos por el hash del commit, que es el único panel que
justifica guardar oid y head_sha.
Lee gh_commit, gh_commit_check, gh_workflow_run y gh_repo_activity.
Planning and community
Sección titulada «Planning and community»Las etiquetas con cuánto se usa cada una, los hitos con su progreso, los forks ganados en el tiempo, la lista de forks, las discusiones por categoría y según estén respondidas o no, y junto a ese recuento las discusiones mismas: las cincuenta más recientes una a una, con su categoría, cuántos comentarios tienen, si están respondidas y un enlace a cada una, sea cual sea el rango, porque una cuenta tiene un puñado y un rango de un mes las escondía todas menos una bajo una fila que decía “Ideas”.
La lista de forks lleva advanced, que es lo que separa una derivación real de
un marcador. La mayoría de los forks son marcadores.
Otros tres paneles van de la conversación y no del plan. Las transiciones por día son cuándo se etiquetó, se cerró, se reabrió o se renombró algo, que el estado de una issue no registra: una reapertura no existe en ninguna otra medida. Las dos tablas de comentarios cuentan lo escrito en cualquier sitio, incluidos los repositorios que la cuenta no posee, que es donde ocurre casi todo: cuando se midió, los comentarios dejados en repositorios ajenos superaban en más de un orden de magnitud a las discusiones de dentro de la cuenta. Junto al recuento por repositorio de comentarios en discusiones, los comentarios mismos: cada uno dejado en una discusión de un repositorio ajeno, del más reciente al más antiguo, con si el mantenedor lo aceptó como respuesta y un enlace al comentario en su hilo.
Lee gh_label, gh_milestone, gh_fork, gh_discussion, gh_issue_event,
gh_issue_comment y gh_discussion_comment.
Delivery and access
Sección titulada «Delivery and access»La tasa de fallo de los webhooks, las entregas por código de estado, los endpoints ordenados por fallos, los rulesets y las claves de despliegue con cuánto tiempo llevan sin usarse.
Los webhooks fallan en silencio. Medido, un hook llevaba respondiendo 403 en setenta y ocho de sus últimas cien entregas y no había nada en ninguna parte que lo dijera. Solo se guarda el host de la URL del webhook, porque la ruta suele llevar un secreto.
Un panel es texto en los ficheros exportados, “Where failure output went”,
porque la salida de un job fallido es texto y su sitio es un almacén de logs, y
quien importa el dashboard puede no tener ninguno: un dashboard atado a un solo
datasource no puede consultar dos. Publicado en un Grafana que sí tiene un
datasource de Loki, con cmd/publish_dashboard -loki <datasource-uid>, el mismo
panel dibuja las últimas líneas de cada job fallido leídas de Loki, las más
recientes primero, con el workflow, el job y la ejecución de cada línea en su
cola logfmt. La variable de repositorio se aplica en los dashboards de InfluxDB,
PostgreSQL y Prometheus; las variables de Graphite y Elasticsearch usan el
asterisco de glob como valor de “All”, que no es una expresión regular, así que
allí el panel muestra todos los repositorios y lo dice.
Los dos últimos son inventarios y no tráfico. “Webhooks configured” existe porque la tabla de endpoints se construye desde las entregas, así que un hook que nunca ha entregado nada no aparece en ella, y un hook activo sin tráfico es justo la fila interesante. “Environments” le hace la pregunta de las claves de despliegue a los destinos de despliegue: un entorno de aquí llevaba mil ciento setenta y siete días sin tocarse.
Lee gh_webhook_delivery, gh_webhook, gh_ruleset, gh_deploy_key y
gh_environment.
Releases
Sección titulada «Releases»Descargas totales, descargas por release y cada asset con su tamaño y su propio recuento de descargas.
Los tres primeros son estado actual. GitHub da un total acumulado por asset y nunca una historia, así que la serie que necesitaría un panel de descargas por día no existe para recogerla. El cuarto panel es lo que sí se puede recuperar de ahí: la diferencia entre el primer y el último valor dentro del rango, que es lo que cada asset ganó de verdad. Un día de eso en la cuenta medida mostró que el noventa y siete por ciento de las descargas van a un único binario de Linux y a su fichero de checksums, que es un instalador y no una persona.
Lee gh_release y gh_release_asset.
Security
Sección titulada «Security»Alertas abiertas de Dependabot y de code scanning, los desgloses por severidad y por ecosistema, las alertas abiertas en el tiempo, la tabla de funciones y el tiempo que se tarda en resolver una alerta según su severidad.
La tabla de funciones es lo que distingue “no hay alertas” de “la función está
apagada”. Sin gh_security_feature, un repositorio con Dependabot desactivado
es indistinguible de uno que no tiene nada que arreglar.
Los recuentos de alertas son estado actual, reescritos en cada pasada, así que todos los paneles de aquí toman la fila más reciente de cada serie y suman esas, no el rango. Sumar el rango cuenta cada alerta una vez por pasada: antes de arreglarlo la tarjeta marcaba 3,61 mil donde la cuenta tiene unas pocas decenas.
Los dos últimos paneles son información nueva, no otra vista. El tiempo hasta resolver una alerta de code scanning sale de unas fechas que se descargaban y se tiraban, así que hasta ahora solo existía el recuento de abiertas; de treinta y cuatro alertas de un repositorio, treinta estaban arregladas y tres descartadas, y las treinta y tres eran invisibles. “Scan results by tool” dice qué encontró un análisis en vez de que se ejecutó, que es lo que explica un salto en el número de alertas.
Lee gh_dependabot_alert, gh_dependabot_alert_item,
gh_code_scanning_alert, gh_code_scanning_alert_item,
gh_code_scanning_analysis y gh_security_feature.
Bruto, la parte cubierta por el plan, lo que de verdad se facturó, los minutos de Actions, el coste en el tiempo por producto, los minutos en el tiempo por SKU y el uso por repositorio.
Bruto, descuento y neto se guardan los tres en vez de derivar uno de los otros, porque el neto no siempre es cero y el descuento es donde aparece el crédito mensual. El precio por unidad está en la tabla por el mismo motivo: es lo que explica que treinta mil minutos de macOS cuesten más que doscientos cuarenta mil de Linux. Un repositorio puede salir en esa tabla y en ningún otro panel, porque la lista que factura y la que se recorre no son la misma.
Los dos paneles de caché van del techo. GitHub limita cada repositorio a diez gigabytes y expulsa la entrada menos usada al pasarlo, así que la barra es cada repositorio contra ese tope y el panel se lee por lo que queda de margen; la tabla de entradas dice qué clave se está tirando y cuál lleva una semana sin tocarse.
Lee gh_billing_usage, gh_actions_cache y gh_actions_cache_entry.
Activity
Sección titulada «Activity»Eventos a lo largo del tiempo, eventos por tipo y por repositorio, notificaciones por motivo y por tipo, notificaciones a lo largo del tiempo y el trabajo hecho en repositorios de otras personas. Los dos paneles fechados agrupan según el rango, no en una hora ni en un día fijos.
Los eventos y las notificaciones son ventanas, no historias. GitHub guarda los últimos trescientos eventos sean de cuando sean y descarta rápido las notificaciones leídas, así que lo que queda guardado es lo que había cuando pasó la pasada.
El donut lleva la parte de cada tipo en su leyenda y no escribe nada sobre los sectores, porque Grafana omite la etiqueta del sector en el que no cabe y los sectores finos nunca tenían la suya. La leyenda es una lista debajo del gráfico y no una columna a su lado, por medida y no por gusto: por debajo de 992 píxeles Grafana pone toda leyenda debajo del gráfico y la limita al 35 por ciento del panel, pida lo que pida el panel, y una leyenda colocada al lado se dibuja allí como columna, una entrada por línea, que en un teléfono se cortaba tras siete entradas; una lista colocada debajo se ajusta en varias líneas, y con la altura que tiene el pastel los once tipos de un mes caben enteros a 360 píxeles.
Los dos últimos paneles son el espejo de la sección de estrellas: las estrellas que dio esta cuenta, no las que recibió, por lenguaje y por proyecto, fechadas cuando dio cada una. Si los proyectos son pequeños o famosos es otra pregunta distinta de cuántos son, así que la segunda tabla lleva sus propias estrellas.
Lee gh_event, gh_notification, gh_external_contribution y
gh_star_given.
Inventory
Sección titulada «Inventory»Código por lenguaje, la puntuación del perfil de comunidad de cada repositorio, la tabla de repositorios, los temas, los paquetes, los gists y las etiquetas de contenedor con el momento en que se publicó cada una.
open_issues en la tabla de repositorios es el campo propio de GitHub, y GitHub
cuenta las pull requests dentro. gh_issue es con lo que se cuentan las issues.
El perfil de comunidad enseña las casillas que hay detrás de la nota además de
la nota, porque el porcentaje esconde cuál falta: en la cuenta medida ocho de
treinta y cinco repositorios no tienen licencia. La casilla de plantilla de
issue no es la de GitHub: la bandera issue_template de la API solo informa
del fichero único heredado ISSUE_TEMPLATE.md, no de un directorio de
plantillas, mientras que la página de comunidad y health_percentage sí cuentan
el directorio, así que la bandera decía “no” en todos los repositorios de una
cuenta cuyos repositorios puntúan 100 con cuatro formularios cada uno (el hueco
está reportado en community/community#207706). La columna es el número de
plantillas que el repositorio tiene de verdad, formularios y Markdown, de
gh_repo_policy.issue_templates, unido a la fila del perfil por repositorio en
los dashboards de InfluxDB, PostgreSQL y Prometheus; Graphite y Elasticsearch no
pueden unir dos medidas en un panel y conservan la bandera de la API,
diciéndolo. La tabla de ajustes es la misma idea para lo que permite un repositorio, y
codeowners_errors es la entrada que falla en silencio, porque un fichero
CODEOWNERS roto deja de pedir revisiones y no dice nada. La tabla de claves de la
cuenta es donde aparece una clave SSH que no se ha usado nunca, y donde queda
apuntada la caducidad de la que firma todos los commits.
El último panel está vacío casi siempre, y esa es la gracia: una fila en
“Configuration changes” significa que un repositorio se
renombró, se archivó, se hizo privado, cambió de licencia o movió su rama por
defecto. La columna de identidad cuenta valores distintos de repo_id, que es la
única forma de distinguir un renombrado de un repositorio nuevo, porque GitHub no
publica ningún historial de renombrados.
Lee gh_repo, gh_repo_language, gh_repo_community, gh_repo_topic,
gh_repo_policy, gh_package, gh_package_version, gh_gist, gh_key,
gh_social_account y gh_dependency_license.
Profile and sponsorship
Sección titulada «Profile and sponsorship»Lo que anuncia el perfil y lo que mueve Sponsors: el dinero que entra y sale, los patrocinios en ambos sentidos, los niveles ofrecidos, los ítems fijados, las banderas del perfil, las listas de estrellas y las insignias de logros con la distancia de cada una a su siguiente escalón.
Las cuatro cifras son la lectura más reciente de una instantánea que se reescribe en cada pasada, no una suma sobre el rango, que informaría del total de por vida una vez por pasada. El total de por vida es el que conserva la historia: la estimación mensual se va a cero en cuanto caduca el último patrocinio, y el dinero que sí llegó deja de verse en ningún otro sitio. Lo gastado patrocinando no es el gasto de la sección Cost, que es lo que GitHub cobra por Actions, paquetes y almacenamiento; esto es dinero que se va al trabajo de otra persona.
Las tablas de debajo son inventarios y no historias, y lo dicen nombrando su
propia ventana: un patrocinio hecho en 2021 aparece con los treinta días por
defecto, donde un panel al rango del dashboard dibujaría un eje vacío sobre un
puñado de filas repartidas por años. Un patrocinio se fecha el día en que
empezó y no el día de ningún pago, ambas conexiones se leen con activeOnly
desactivado para recuperar uno caducado, y el patrocinable es la palabra
literal private cuando la otra parte queda oculta, sin adivinar ningún enlace.
Los niveles se anclan al comienzo del día UTC por la misma razón: fechados en
su creación caerían todos fuera de cualquier rango y se leerían como que no hay
ninguno.
Los ítems fijados llevan la posición como campo y no como etiqueta, porque un repositorio que pasa del hueco dos al tres es el mismo fijado, y como etiqueta cada recolocación bifurcaría la serie. El filtro de repositorio de la cabecera del dashboard no llega a ese panel: un fijado se llama owner/name, o es un gist, y la variable no guarda ninguna de las dos cosas.
Los logros se leen una vez al día de la página pública del perfil, porque ninguna API los lista. “Next tier at” es el umbral observado por la comunidad (Schweinepriester/github-profile-achievements) y no un número que GitHub publique, así que la última columna dice si la página del perfil coincide con el escalón que implica el recuento; una fila que no coincide es una regla que la página contradice, y no lleva objetivo ni barra. Los dos paneles de logros están vacíos hasta que esa familia haya corrido una vez.
Lee gh_sponsors_listing, gh_sponsorship, gh_sponsors_tier,
gh_pinned_item, gh_profile_flag, gh_star_list, gh_achievement y
gh_achievement_progress.
The collector itself
Sección titulada «The collector itself»Lo que le queda al colector por gastar: el presupuesto de cada uno de los quince límites de GitHub en el tiempo, y una tabla con todos ellos ordenada por cuánto se ha gastado de cada uno.
El gráfico muestra solo los cubos con más de treinta peticiones, porque el de
búsqueda tiene treinta por minuto y aplastaría el eje. Leer todo esto no cuesta
nada: GET /rate_limit es el único endpoint que GitHub no cobra. Sin él, una
familia saltada por falta de presupuesto es indistinguible de una que no tenía
nada que contar.
Lee gh_rate_limit.
La columna Link
Sección titulada «La columna Link»Toda tabla cuyas filas son ítems de GitHub selecciona una columna llamada Link,
la url de la fila, y la oculta: el enlace cuelga de la primera columna de la
tabla, el nombre de la cosa, y abre la página de la propia fila en una pestaña
nueva. En un teléfono la columna del extremo derecho se alcanzaba en dos tablas
de veintiocho, y la primera columna siempre está en pantalla; por la misma
razón la columna por la que se ordena una tabla es la segunda, y una fecha se
muestra al minuto y no al segundo. Unas pocas tablas enlazan desde otra url que
lleva la fila: Recent
stars abre a la persona que dio la estrella, Top referrers el host que envió
las visitas, Deployments by environment tiene una segunda columna, Live, con la
dirección del propio entorno. Release assets conserva su fichero bajo Download,
que descarga el binario, y añade la página de la release como su Link; un clic
en una barra de Downloads by release también abre la release. Cuando la página
es una que GitHub solo muestra al propietario, los ajustes de un repositorio,
su gráfico de tráfico, una alerta, el título al pasar el ratón por el enlace lo
dice.
La columna llega a un almacén solo donde su consulta la devuelve: los dos
almacenes SQL la seleccionan por nombre y Elasticsearch agrupa por
url.keyword, así que un documento sin ella cae en una celda vacía y no fuera
de la tabla. Prometheus no lleva url y Graphite no guarda cadenas, y cada una
de sus tablas dice en su descripción que la columna Link del dashboard de
InfluxDB está ausente allí. cmd/check_dashboards somete cada columna de
enlace de un dashboard renderizado a esa regla: la columna tiene que volver, y
no contener más que urls absolutas y celdas vacías, un nulo de los almacenes
SQL o la cadena vacía de ese bucket.
Cuando un almacén no puede responder
Sección titulada «Cuando un almacén no puede responder»Los almacenes no pueden responder las mismas preguntas, y los paneles lo dicen en vez de fingir.
- InfluxDB y PostgreSQL guardan una fila por hecho, fechada cuando ocurrió, así que dibujan el tráfico de un martes concreto, la curva de estrellas desde 2018 y el tiempo de fusión de una pull request cerrada en julio. El juego de PostgreSQL es el SQL de InfluxDB traducido, porque el destino SQL escribe los mismos hechos como tablas.
- Prometheus sella cada muestra en el momento del scrape, así que el
exportador reduce las filas por elemento a valores actuales más, para las
medidas que se cuentan, un
_totalmonótono de elementos distintos vistos desde que arrancó.increase()sobre eso es como se responden los paneles “por día” y “sobre el rango”. - Graphite conserva los puntos fechados pero no tiene filas: una tabla ahí es un número por serie reducido sobre el rango, así que una tabla que necesita varios campos de una fila se queda con la columna por la que ordena y dice cuál ha soltado, y un booleano allí ni siquiera es una métrica.
- Elasticsearch conserva los documentos fechados, así que una tabla por
elemento son los documentos más recientes y todo lo demás es una agregación
por buckets, sobre el subcampo
.keywordde cada etiqueta.
Cada panel cuyo gemelo en otro almacén es más rico lo dice en una frase de su descripción.
Veinticuatro paneles no tienen respuesta en Prometheus
Sección titulada «Veinticuatro paneles no tienen respuesta en Prometheus»Top paths, el calendario de contribuciones, los dos punch cards de commits y los dos repartos por repositorio del calendario, las pull requests más grandes, pull requests por autor, las issues abiertas más tiempo, la deuda de revisión, los pasos más lentos, los pasos que fallan, los workflows que nunca se ejecutaron, los artefactos creados a lo largo del tiempo, los commits que dejaron la rama en rojo, las últimas discusiones y las respuestas dejadas fuera, los assets de release, lo que ganó cada asset, las alertas abiertas más antiguas, los eventos por repositorio, las últimas notificaciones, las etiquetas de contenedor y la configuración que cambió. El exportador o se salta la medida, o descarta la identidad de la que trata el panel, o el panel es un cruce entre dos medidas.
Adónde fue la salida de los fallos es un panel de texto en todos los almacenes, este incluido: es una nota sobre dónde mirar, no una consulta.
Tres de esos son cruces o diferencias de conjuntos y tampoco tienen respuesta en Graphite ni en Elasticsearch, por lo mismo: una agregación corre dentro de un índice o de un árbol, y estos necesitan dos. El calendario no la tiene en ninguno de los dos por otra razón: la rejilla necesita la semana en un eje y el día de la semana en el otro, y un histograma de fechas o un summarize agrupan por un solo intervalo. Cada uno de los dos pierde algo más por su cuenta: Graphite las alertas abiertas más antiguas y las últimas notificaciones, porque guarda números y no las cadenas de las que están hechas esas tablas, y Elasticsearch lo que ganó cada asset, que es la diferencia entre el primer y el último valor del rango.
Se emiten igualmente, como paneles de texto con el mismo título que dicen qué mostrarían y por qué el almacén no puede, para que los diseños sigan siendo idénticos.
Esa captura no es de ninguna cuenta. Es el dashboard de Prometheus de la suite
end-to-end en contenedores (test/e2e/docker), donde el colector recorre el
GitHub falso de test/e2e/fakegh, cuya cuenta es octocat con un solo
repositorio, y Prometheus hace scrape del exportador cada cinco segundos. El
rango son los diez minutos que llevaba recolectando cuando se tomó la captura,
que es lo que hace que merezca la pena enseñarla: cada número del Overview, y
las dos tablas de la sección Audience, es un valor actual, porque un valor
actual es todo lo que el exportador puede servir; Rate budget used es una
línea plana, porque un gauge repetido en cada scrape es una línea plana; Top paths es el panel de texto descrito arriba; y Views, Unique visitors y
Clones over time dicen “No data” porque su bucket tiene un suelo de un día y
este Prometheus lleva minutos. En un servidor que lleve meses haciendo scrape
esos tres dibujan, empezando el día en que arrancó el exportador.