En production, les choses cassent. Les API retournent des erreurs 500. Les requêtes de base de données prennent dix secondes. L'utilisation mémoire grimpe jusqu'au crash du processus. La différence entre un projet jouet et une application de production est de savoir si vous êtes au courant de ces problèmes avant vos utilisateurs.
La plupart des langages délèguent le monitoring à des services externes. Sentry pour le suivi des erreurs. Datadog pour le monitoring de performance. New Relic pour les métriques applicatives. Ces services sont excellents -- et ils coûtent de l'argent, nécessitent de la configuration et ajoutent de la latence à chaque requête. Pour des développeurs à Abidjan construisant leur premier SaaS, un service de monitoring à 29 $/mois est une dépense significative.
La Session 180 a ajouté le suivi des erreurs, le timing de performance et le monitoring mémoire à la bibliothèque standard de FLIN.
Journalisation structurée
flinlog_info("Server started on port 8080")
log_warn("Cache miss rate above 50%")
log_error("Database connection failed: {error}")
log_debug("Query executed in {duration}ms")Chaque fonction de journalisation accepte une chaîne de message avec interpolation. La sortie inclut un horodatage, un niveau de sévérité et le message.
Suivi des erreurs
flintrack_error("payment_failed", {
endpoint: "https://api.payment.com/charge",
timeout: 30,
order_id: order.id,
attempt: retry_count
})track_error fait trois choses : journalise l'erreur au niveau ERROR avec le contexte structuré, incrémente un compteur d'erreurs interne et stocke l'erreur dans un buffer circulaire en mémoire (les 1 000 dernières erreurs).
Timing de performance
flintimer_start("database_query")
users = User.where(role: "admin")
elapsed = timer_end("database_query")
// Affiche : "[TIMER] database_query: 12.45ms"
result = measure("render_dashboard", {
users = User.all
orders = Order.where(status: "active")
stats = compute_stats(orders)
render_template(users, orders, stats)
})
// Affiche : "[MEASURE] render_dashboard: 45.2ms"Monitoring mémoire
flinmem = memory_usage()
// {
// heap_used: 12582912, // 12 Mo
// heap_total: 33554432, // 32 Mo
// stack_used: 8192, // 8 Ko
// objects: 45230, // Nombre d'objets sur le tas
// gc_collections: 7 // Nombre de passages du GC
// }Dix-huit fonctions pour la visibilité en production
L'API de monitoring complète :
- Journalisation :
log_info,log_warn,log_error,log_debug - Suivi des erreurs :
track_error,recent_errors,error_count - Timing :
timer_start,timer_end,measure,measure_latency,latency_stats - Mémoire :
memory_usage,format_bytes - Assertions :
assert,assert_eq,assert_ne - Sortie :
print,debug
Dix-huit fonctions qui donnent à chaque application FLIN une observabilité de niveau production dès le premier jour. Pas de service externe. Pas de configuration. Pas de facture mensuelle.
Ceci est la partie 80 de la série "How We Built FLIN", documentant comment un CEO à Abidjan et un CTO IA ont construit le suivi des erreurs et le monitoring de performance dans un langage de programmation.
Navigation de la série : - [79] Validation and Sanitization Functions - [80] Error Tracking and Performance Monitoring (vous êtes ici) - [81] FlinUI: Zero-Import Component System - [82] From Zero to 70 Components in One Session