Historias de ingeniería,
no solo nombres de proyectos.

La aplicación que programé. La aplicación permite elegir un ejercicio e introducir la fecha, los pesos y las repeticiones de cada serie. Las sesiones guardadas alimentan el historial, el cálculo del volumen y los gráficos de progreso. La página pública de Kraftwerk muestra una vista de solo lectura de ese historial. Cómo nació Kraftwerk →

Datos con contexto. Las métricas de la sesión, el volumen total, los pasos y los controles de rango temporal hacen que los entrenamientos individuales sean significativos dentro de los patrones semanales y mensuales.

Creado para evolucionar. La importación de CSV y datos de salud mantiene la información histórica portátil, mientras que la capa de presentación puede obtener nuevas métricas sin reescribir los registros subyacentes.

KRAFTWERK / MISSION LOG

Del papel al progreso.

Cuatro etapas de una app nacida de mi propio entrenamiento.

01El cuaderno02Digitalización03Mi propia app04Progreso actual

Etapa 1 / 4

Todo empezó en un cuaderno.

No encontraba la app adecuada. Así que anoté fechas y repeticiones a mano. Esta es mi página original de flexiones.

Un entorno pequeño con puntos ciegos crecientes. Al principio solo había unos pocos servidores y scripts de análisis de logs. Con el crecimiento, el enfoque dejó de escalar y de representar la complejidad. Además, era reactivo: mostraba lo que ya había ocurrido.

El jefe y el cliente no son herramientas de monitorización. ¿Por qué descubrir un problema cuando ya ha sucedido? Si un responsable o un cliente es el primero en comunicar una caída, operaciones ya llega tarde. Además del incidente, queda en riesgo la confianza en el trabajo del equipo, dentro y fuera de la organización.

El clásico: un certificado TLS a punto de caducar. En 2000 no existían de la misma forma las opciones actuales de renovación automática. Let’s Encrypt llegó mucho después, en 2015. Necesitábamos vigilar la caducidad antes de descubrirla mediante una conexión fallida. Los requisitos y emisores pueden variar; incluso la renovación automatizada necesita supervisión.

Detectar, avisar y conservar datos. Nuestras primeras opciones fueron Nagios y Zabbix. Hacían falta comprobaciones y avisos que llegaran a alguien capaz de actuar. Los avisos se dirigían especialmente al equipo de guardia 24/7 para atender incidentes a cualquier hora. Por motivos de coste, la web todavía no tenía una arquitectura de alta disponibilidad. La detección fiable y la respuesta rápida eran esenciales para mantener la mejor calidad de servicio posible; la monitorización no eliminaba por sí sola el riesgo de interrupciones. Con los años, los canales incluyeron SMS, WhatsApp y PagerDuty; no significa que todos se utilizaran ya en 2000.

Del incidente a la tendencia. Registrar métricas permitía estudiar cómo evolucionaban carga, latencia y capacidad, más allá de una alarma aislada. Después se añadieron Grafana y Checkmk. El objetivo seguía siendo detectar antes el deterioro y entender hacia dónde se dirigían los sistemas.

El principio que permanece. La monitorización es más que una colección de paneles: debe dar al equipo la oportunidad de actuar antes de que otra persona tenga que señalar el problema.

Fuente histórica: anuncio del primer certificado público de Let’s Encrypt (2015).