games / fivem

Debug, profiling & déploiement en production

Leçon 181 exercice

Explication

Ce que vous allez apprendre

Utiliser resmon pour identifier la ressource qui consomme trop de temps de calcul
Structurer ses logs avec horodatage et niveau de gravité plutôt que des print() isolés
Mesurer le temps d'exécution d'une fonction critique avec un profiling léger
Protéger un thread avec pcall pour éviter qu'une exception ne le coupe silencieusement
Configurer un server.cfg de production (réseau, sécurité, ordre des ressources)

Dans quel contexte ?

Un serveur RP vient d'ouvrir au public et les joueurs signalent des ralentissements intermittents difficiles à reproduire en test. Sans outils de diagnostic (resmon, logs structurés, profiling), l'équipe ne peut que deviner la cause. Cette dernière leçon du tronc commun donne les outils concrets pour transformer une supposition en diagnostic précis, condition indispensable pour faire tourner un serveur public dans la durée.

Outil	Rôle
`resmon`	Consommation CPU en temps réel, par ressource
Logs structurés (horodatage + niveau)	Investigation a posteriori d'un incident
`pcall`	Empêche une exception de couper silencieusement un thread
txAdmin	Monitoring, logs et redémarrages centralisés

Bonne pratique

Adopte un format de log cohérent ([date] [niveau] message) dès le début d'un projet, plutôt que des print() isolés. Le jour où un incident réel doit être investigué, parfois plusieurs jours après qu'il s'est produit, ce choix fait toute la différence.

Écrire du code ne suffit pas à faire tourner un serveur

Toutes les leçons précédentes ont porté sur l'écriture de fonctionnalités. Faire réellement tourner un serveur public, avec de vrais joueurs, ajoute une dimension différente : savoir observer ce qui se passe, diagnostiquer un problème sans devoir deviner, et configurer correctement l'environnement dans lequel tout ce code s'exécute.

resmon : voir ce qu'on ne peut pas deviner

Sans outil dédié, il est impossible de savoir "à l'œil" quelle ressource, parmi des dizaines installées, consomme trop de temps de calcul et ralentit le serveur pour tout le monde. resmon affiche en temps réel la consommation de chaque ressource individuellement, transformant une supposition en une observation précise et objective — la première étape indispensable avant d'optimiser quoi que ce soit.

Pourquoi structurer ses logs

Éparpiller de simples print() dans le code fonctionne pour un test rapide, mais devient vite inexploitable en production : impossible de savoir quand un message est apparu, ni de filtrer par gravité. Adopter un format cohérent (horodatage, niveau de gravité) dès le début rend les journaux du serveur réellement utiles au moment où un incident réel doit être investigué, parfois plusieurs jours après qu'il s'est produit.

pcall : contenir l'imprévisible

Une erreur non gérée dans un thread peut, selon le contexte, interrompre silencieusement toute une chaîne de traitement sans que personne ne s'en aperçoive immédiatement. pcall ("protected call") exécute une fonction en capturant toute erreur qu'elle pourrait déclencher, permettant de la logger proprement et de continuer à faire fonctionner le reste du serveur normalement, plutôt que de laisser une erreur isolée dégrader silencieusement l'expérience de tous les joueurs.

txAdmin, le tableau de bord qui centralise tout

Plutôt que de jongler entre plusieurs outils séparés, txAdmin regroupe en une seule interface web le monitoring de performance, la consultation des logs, la gestion de la base de données et les redémarrages planifiés — un outil quasiment indispensable dès qu'un serveur dépasse le stade du simple test personnel.

Commandes & code

Debug, profiling & déploiement (niveau expert)

Faire tourner un serveur FiveM en production demande des outils de diagnostic et une configuration réseau/sécurité solide.

-- Commandes utiles en console serveur
resmon                  -- moniteur de ressources en temps réel (aussi accessible en jeu via F8)
refresh                 -- recharge la liste des ressources depuis resources.cfg
restart mon_script      -- redémarre une ressource sans redémarrer le serveur entier
ensure mon_script       -- démarre/assure qu'une ressource tourne, avec ses dépendances
stop mon_script
start mon_script

-- Logging structuré pour la production (préférable à des print() dispersés)
local function Log(level, message, ...)
    local formatted = string.format(message, ...)
    print(('[%s] [%s] %s'):format(os.date('%Y-%m-%d %H:%M:%S'), level, formatted))
end

Log('INFO', 'Ressource technologik démarrée (v%s)', '1.0.0')
Log('ERROR', 'Échec de connexion DB pour identifiant %s', identifier)

-- Mesurer le temps d'exécution d'une fonction critique (profiling manuel léger)
local function ProfileFunction(name, fn, ...)
    local start = GetGameTimer()
    local result = { fn(...) }
    local elapsed = GetGameTimer() - start

    if elapsed > 5 then -- log seulement si ça dépasse un seuil (ici 5ms)
        print(('[PERF] %s a pris %dms'):format(name, elapsed))
    end

    return table.unpack(result)
end

ProfileFunction('GetPlayerInventory', GetPlayerInventory, source)

; server.cfg (extraits production)
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

sv_maxclients 64
sv_hostname "Technologik RP | technologik.fr"

set mysql_connection_string "mysql://user:password@127.0.0.1/technologik_db?charset=utf8mb4"

# Sécurité réseau et anti-triche de base
sv_enforceGameBuild 2802
sv_scriptHookAllowed 0          # bloque ScriptHookV côté client
set sv_authMaxVariance 1
set sv_authMinTrust 5

# txAdmin : interface de gestion/monitoring (recon, resmon web, logs, database viewer)
ensure txadmin

# Ressources : l'ordre compte, les dépendances doivent être chargées avant leurs consommateurs
ensure ox_lib
ensure oxmysql
ensure ox_target
ensure technologik_core
ensure technologik_shop

-- Gestion propre des erreurs pour éviter qu'une exception ne coupe tout un thread silencieusement
local function SafeCall(fn, ...)
    local ok, err = pcall(fn, ...)
    if not ok then
        Log('ERROR', 'Exception non gérée: %s', tostring(err))
    end
end

RegisterNetEvent('technologik:riskyOperation', function(...)
    SafeCall(function(...)
        -- logique potentiellement instable (parsing externe, calculs complexes...)
    end, ...)
end)

Résumé

resmon reste l'outil numéro un pour repérer une ressource qui consomme trop de CPU.
txAdmin centralise monitoring, logs, base de données et redémarrages planifiés en production.
pcall protège un thread d'une exception qui, sinon, se propagerait silencieusement.
La configuration réseau (sv_maxclients, sv_enforceGameBuild) fait partie intégrante de la sécurité du serveur.

Exercices pratiques

1 disponible

Mission : élucider un ralentissement fantôme

Objectif : Utiliser les bons outils de diagnostic pour transformer une supposition en cause précise, puis blinder un thread risqué avec pcall et des logs structurés.

Contexte

Le serveur technologik_rp vient d'ouvrir au public. Depuis deux jours, plusieurs joueurs signalent des ralentissements intermittents, impossibles à reproduire quand un admin teste seul en interne. La console ne contient que des print() isolés, sans horodatage, et personne n'a encore ouvert resmon.

Résoudre l’exercice →