Déploiements

En savoir plus sur les déploiements et leur cycle de vie - concepts et bonnes pratiques pour une compréhension approfondie.

🗺️ Orchestration

Démarrez de nouveaux serveurs en quelques secondes pour répondre aux demandes de capacité grâce à notre approche cloud native d'edge computing. Nous traitons les serveurs comme du bétail plutôt que comme des animaux de compagnie - en remplaçant complètement les instances défectueuses au lieu de soigner chacune manuellement.

Votre choix d'orchestration impactera votre coût DevOps, le coût des serveurs et la scalabilité.

La plupart des jeux ne rentrent pas parfaitement dans une case. Contactez-nous sur Discord pour en savoir plus sur les options d'orchestration hybrides.

Pour comprendre pleinement tous les avantages et inconvénients, comparons les différentes méthodes d'orchestration.

Lié-au-match

Standard d'or pour les studios modernes offrant la plus simple intégration avec la meilleure efficacité de coût.

👍 Avantages

• Meilleure efficacité de coût - mise à l'échelle en temps réel pour répondre à la demande des joueurs minute par minute.

• Coût DevOps le plus bas grâce à l'hébergement sans région ; Edgegap automatise 99 % des tâches.

• Ping le plus bas grâce à 615+ sites dans l'infrastructure cloud publique d'Edgegap.

• Montée en charge la plus rapide (capacité de débordement) en cas de pic de trafic inattendu.

• Niveau de sécurité et de prévention de triche le plus élevé (autorité serveur).

• Impact minimal d'un crash de serveur inattendu sur les joueurs, n'affectant qu'un seul match.

👎 Inconvénients

• Adopter un nouveau modèle mental d'orchestration nécessite un certain effort d'apprentissage initial.

• Les serveurs fonctionnant plus de 24 heures seront automatiquement terminés.

🧩 Idéal pour

• Jeux sensibles à la latence - lorsque l'optimisation du netcode ne peut pas compenser un ping élevé :

  • Shooters à la première personne, jeux de combat, VR & XR (réalité virtuelle et étendue), …

• Jeux avec une limite supérieure sur la durée des matchs par conception,

  • Battle Royale, PvPvE, Coop Shootters, MOBA, jeux de sport, ARPGs & Dungeon Crawlers, …

🔎 Découvrabilité

• Démarrez de nouvelles parties lorsque suffisamment de joueurs se joignent Matchmaking.

  • Ajoutez des joueurs pour remplacer les départs dans les matchs existants avec du backfill.

• Permettez aux joueurs de parcourir les serveurs et de choisir dans une liste avec Navigateur de serveurs.

• Implémentez un backend de jeu personnalisé ou tiers pour découvrir les serveurs.

Edgegap met automatiquement à l'échelle les 615+ emplacements de serveurs vers le haut/vers le bas en fonction de l'activité des joueurs dans chaque région. Préparez-vous au succès - montez à l'échelle jusqu'à 14 millions d'utilisateurs simultanés en 60 minutes.

Standby régional

Modèle traditionnel pour mondes persistants avec contenu généré par les utilisateurs et jeux MMO sociaux.

👍 Avantages

• Approche familière et facile à comprendre, vieille école pour les vétérans aguerris.

• Niveau de sécurité et de prévention de triche le plus élevé (autorité serveur).

• Coût aisément prévisible basé sur un engagement mensuel.

👎 Inconvénients

• Coût d'hébergement plus élevé - chaque région nécessite un ou plusieurs serveurs en veille inactifs (capacité de débordement).

• Coût DevOps plus élevé - mise à l'échelle, opérations et maintenance dupliquées par région.

• Les régions avec une base de joueurs plus petite subissent un ping élevé en raison de la connexion à des serveurs éloignés.

🧩 Idéal pour

• Mondes persistants avec contenu généré par les utilisateurs stocké sur le serveur même lorsque les joueurs sont hors ligne.

  • MMO, Sandboxes avec construction de bases ou placement d'objets, Extraction Shooters, ...

• jeux tolérants à la latence - lorsque la physique temps réel avec autorité serveur n'est pas requise:

  • jeux mobiles, jeux coopératifs, TCG/CCG, jeux au tour par tour, …

• Multijoueur asynchrone, où les crashs de serveur ont un impact minimal sur l'expérience du joueur :

  • course contre des fantômes, pillage de base ennemie, jeux de construction/agriculture basés sur un minuteur, …

• applications avec un lourd processus d'initialisation - lorsque la préparation des serveurs prend des minutes.

🔎 Découvrabilité

• Permettez aux joueurs de parcourir les serveurs et de choisir dans une liste avec Navigateur de serveurs.

• Implémentez un backend de jeu personnalisé ou tiers pour découvrir les serveurs.

Voir Clusters gérés pour auto-héberger vos microservices et services backend sur Edgegap.

Pair à pair

Redirigez les efforts de développement des serveurs dédiés vers le netcode relais pour les jeux non compétitifs.

Sujets liés : serveurs à l'écoute, autorité hébergée par un joueur, traversée NAT (NAT punch-through).

👍 Avantages

• Coût d'hébergement le plus bas, nécessitant uniquement des serveurs de relais pour résoudre la traversée NAT.

• Coût DevOps le plus bas - maintenance requise uniquement pour les builds client et les canaux de distribution.

• Impact minimal d'un crash de serveur inattendu sur les joueurs, n'affectant qu'un seul match.

• Facile à implémenter et rapide pour prototyper, sans développement backend requis.

👎 Inconvénients

• Augmentation de l'effort de développement du netcode pair-à-pair nécessitant des compétences en programmation concurrente.

• Temps de ping les plus mauvais et très sensible aux conditions réseau défavorables (par ex. Internet mobile).

• Sécurité la plus faible, vulnérable aux attaques de type man-in-the-middle et au détournement de session.

• Risque d'interruption des sessions lorsque l'hôte quitte à moins que vous n'implémentiez une migration d'hôte personnalisée.

🧩 Idéal pour

• Jeux coopératifs & casual - lorsque la triche n'enlève pas le plaisir ou ne casse pas le jeu,

  • Jeux pour enfants, jeux d'exploration, aventures, …

🔎 Découvrabilité

• Implémentez un backend de jeu personnalisé ou tiers pour découvrir les serveurs.

Voir notre Relais distribués pour un service permettant le pair-à-pair avec une latence et une sécurité de premier ordre.

📍 Placement des serveurs

Peu importe la méthode d'orchestration choisie, choisir le bon emplacement de serveur pour un groupe de joueurs est crucial pour garantir le meilleur ping possible et une expérience joueur optimale. Découvrez les différentes stratégies de placement des serveurs et comment elles impactent vos joueurs.

Votre stratégie de placement des serveurs impactera l'expérience de vos joueurs, la rétention, et les critiques de votre jeu.

Edgegap déploie dans le meilleur emplacement possible avec la capacité disponible, pour des matchs rapides et à faible latence.

Voir Déploiements vers analyser le placement des serveurs en temps réel, à grande échelle.

Score du serveur

La stratégie de score serveur utilise la méthodologie brevetée d'Edgegap, qui optimise le placement des serveurs pour chaque match individuellement. Effectue une télémétrie non intrusive pour approximer la proximité réseau de chaque joueur par rapport à nos emplacements de serveurs et choisir le serveur qui offre le meilleur :

• réactivité - fournit le ping le plus bas pour tous les joueurs en moyenne,

• équité - fournit un ping équilibré et équitable pour tous les joueurs.

Notre Matchmaker utilise la stratégie de Score du serveur par défaut, pour assurer la meilleure expérience possible. Pour utiliser cette stratégie avec les API de déploiement, fournissez les IP publiques des joueurs ou les coordonnées géographiques dans votre requête de déploiement.

Placement non réactif - le serveur est loin, ping élevé pour tous les joueurs :

Placement injuste - ping inégal, un joueur est désavantagé :

Exemple de bon placement - ping réactif et équitable pour tous les joueurs :

Cette stratégie est particulièrement efficace pour héberger un groupe de joueurs éloignés les uns des autres (Amérique du Nord vs Europe, ou côte Ouest vs côte Est), cas fréquent avec des lobbys préfabriqués.

Géolocalisation

Alternativement, fournissez les coordonnées de latitude & longitude des joueurs ou les coordonnées d'un emplacement de serveur préféré au lieu d'exploiter la télémétrie automatisée. Cette approche nécessite une implémentation supplémentaire de recherche géographique côté client, reposant entièrement sur la solution du développeur du jeu.

La stratégie de géolocalisation n'est pas recommandée pour Déploiements l'orchestration, sauf pour les applications ayant des exigences réglementaires strictes concernant les transferts inter-régionaux de données, ou lorsque l'IP du joueur est indisponible.

Pour utiliser cette stratégie avec les API de déploiement, listez les IP publiques des joueurs ou les coordonnées géographiques dans votre requête de déploiement.

Verrouillage régional

Les serveurs peuvent être placés en utilisant un paramètre de région grossièrement généralisé, soit :

• choisi automatiquement pour le joueur, en fonction de leurs métadonnées (base de données du compte joueur), ou

• sélectionné par le joueur lors du matchmaking, permettant un placement avec une latence client-serveur élevée.

Utiliser cette stratégie seule n'est pas recommandé car elle peut entraîner de mauvaises performances réseau.

Utiliser la sélection de région comme pré-filtre en combinaison avec une autre stratégie est une meilleure alternative.

🟢 Qualité de connexion

Certains jeux (et certains joueurs) sont plus sensibles à la latence ou au lag que d'autres. Bien que les rapports joueurs soient un excellent indicateur d'incidents ou de régressions à grande échelle, les joueurs peuvent manquer d'une compréhension approfondie des concepts réseau et sont prompts à attribuer la faute aux studios, au netcode ou aux serveurs.

La cause profonde de certains problèmes peut être cachée aux joueurs, donc la coopération entre le studio et le fournisseur d'hébergement peut être cruciale. La priorité d'Edgegap est toujours de fournir le meilleur service possible.

Si vous recevez de nombreux rapports de joueurs, rencontrez des pannes étendues ou des problèmes répétés, veuillez nous contacter immédiatement via un ticket de support sur notre plateforme.

Si vous avez besoin d'aide, veuillez nous contacter via Discord. Pour le support des jeux en direct, consultez notre système de billetterie.

Faible latence

La latence du joueur est une combinaison de latence due au transfert de données entre :

• appareils physiques - le signal physique voyageant à travers la topologie du réseau Internet,

• hôte à hôte - résultant des protocoles, du transport et des mesures de sécurité,

• processus à processus - résultant de l'encapsulation/décapsulation et du traitement des données dans le client/serveur.

Edgegap réduit la latence physique en plaçant des serveurs plus près de vos joueurs pour des réponses plus courtes et un nombre réduit de sauts réseau. Avec des emplacements chez 17 fournisseurs cloud et bare metal, vous obtenez un ping de classe mondiale pour les joueurs partout dans le monde.

La couverture des serveurs et d'Internet au niveau mondial (pas seulement avec Edgegap) est limitée en raison de facteurs tels que :

• disponibilité d'infrastructure - la qualité de la connexion Internet dans une région donnée peut ne pas être suffisante,

• facteurs naturels - les racks de serveurs très complexes nécessitent un environnement principalement stable.

Haute disponibilité

La disponibilité des serveurs dans divers emplacements autour du monde varie au fil du temps, changeant plusieurs fois par jour. Edgegap met automatiquement à l'échelle vers le haut/vers le bas les emplacements à la demande, en tenant compte de :

• trafic par vague - déploiements effectués sur une période de 15 minutes,

• exigences en vCPU - plus de vCPU par déploiement augmente la demande globale pour un emplacement spécifique,

• offre du fournisseur - certains emplacements distants ont moins d'options de fournisseurs disponibles,

• disponibilité des machines - certains emplacements peuvent n'offrir que des machines 4 vCPU ou 8 vCPU,

• demandes du studio pour les tests, l'assurance qualité, l'accès anticipé, les bêtas fermées ou les tournois.

Toutes les requêtes de déploiement des applications sont combinées pour évaluer la demande par emplacement. Toutes les organisations ont une priorité d'allocation égale par défaut, avec la possibilité d'ajouter des pools de serveurs privés pour les clients entreprise nécessitant un matériel ou des emplacements spécifiques.

Veuillez nous contacter pour planifier une sortie, ou si vous avez des demandes concernant la disponibilité des emplacements.

Résolution des problèmes des joueurs

Les problèmes des joueurs peuvent avoir pour origine des bugs serveur ou des incidents chez le fournisseur, mais peuvent aussi provenir de tiers tels que les FAI locaux, services de jeu, bugs dans des bibliothèques bas niveau, fournisseurs d'infrastructure, ou d'autres sources.

Lors du dépannage des rapports joueurs ou des incidents, considérez les facteurs :

• qualité du matchmaking - les joueurs devraient être proches les uns des autres (même région) pour Déploiements donner les meilleurs résultats :

  • voir Matchmaking et Balises de ping pour nos recommandations,

  • voir Analyse approfondie pour apprendre comment trouver les journaux serveur liés aux rapports joueurs,

• problèmes régionaux :

  • les fournisseurs d'accès Internet (FAI) locaux peuvent résoudre momentanément un incident,

  • certaines régions (par ex. Chine, Russie) peuvent être restreintes en raison de sanctions localisées,

• niveau de mise en cache - Edgegap priorisera les déploiements rapides dans les emplacements mis en cache :

  • activez la mise en cache pour déployer vos serveurs en quelques secondes,

• temps maximum de déploiement - les déploiements peuvent échouer en raison d'un processus d'initialisation lent et lourd :

  • voir Applications et versions pour augmenter la période de timeout,

  • retardez les étapes d'initialisation jusqu'à ce qu'elles soient absolument nécessaires,

• problèmes d'image ou d'intégration du serveur.

Afficher les ID de déploiement dans l'interface d'historique des matchs du client pour tracer les rapports joueurs lors du dépannage.

Informez les utilisateurs des bugs répandus, problèmes temporaires et pannes pour atténuer le sentiment négatif.

🔄 Cycle de vie du déploiement

Les déploiements Edgegap traversent plusieurs étapes de cycle de vie, indiquées par le statut du déploiement.

1. Démarrer un déploiement

Un déploiement à des fins de test peut être démarré avec :

• Unreal Engine - Extension Docker ou plugin pour les projets Unreal Engine,

• Unity - plugin pour les projets Unity,

• Interface Web du tableau de bord - interface web facile à utiliser pour tester l'intégration du serveur.

Un déploiement à des fins environnement de production en direct doit être démarré avec :

• Matchmaking - trouver d'autres joueurs et démarrer des serveurs à la demande (Déploiements).

• Navigateur de serveurs - préchauffez les serveurs avec une longue initialisation (Déploiements).

• API de déploiement - intégration serveur à serveur personnalisée (scaling personnalisé).

Enregistrer request_id (ID de déploiement) et taguer les déploiements pour identifier et dépanner les problèmes ultérieurement.

Lors des tests avec API de déploiement, vous pouvez remplacer le Dockerfile par défaut CMD avec une commande personnalisée.

2. Déploiement en cours

Une fois qu'un déploiement est démarré, notre système effectuera un certain nombre d'étapes en rapide succession :

• Télémétrie - nous mesurons la réactivité du réseau depuis les centres de données disponibles vers chaque joueur,

• Déploiement - nous réservons la capacité et préparons le démarrage de votre conteneur serveur,

• Démarrage du conteneur - nous démarrons le conteneur, installons les dépendances et initialisons,

• Post-traitement - nous ajoutons le stockage des logs, la surveillance et finalisons le déploiement.

Activer Mise en cache active dans votre version d'application pour déployer des serveurs en quelques secondes.

Trop de requêtes 429 - pour assurer la stabilité et éviter des factures surprises, nous limitons le débit de votre organisation à 40 req/s. Contactez-nous pour planifier des sorties, estimer le trafic de lancement et préparer le succès.

3. Déploiement prêt

Votre conteneur est entièrement initialisé et votre serveur démarre maintenant. Pendant quelques secondes à une minute, votre serveur peut encore être en phase d'initialisation et ne pas répondre aux requêtes des joueurs jusqu'à ce que votre moteur de jeu (ou runtime personnalisé) soit totalement prêt à accepter les connexions des joueurs.

Une fois que le déploiement est Prêt, réessayez la connexion du joueur jusqu'à réussite, ou jusqu'au timeout client prédéfini.

Un plantage inattendu du serveur entraînera le redémarrage automatique de votre serveur. L’état du serveur peut être perdu.

4. Erreur de déploiement

Votre déploiement peut se retrouver en état d'Erreur à tout moment, pour des raisons inattendues. Cela est plus susceptible de se produire lors des tests de votre intégration ou des nouveaux builds serveur.

Vous n'êtes pas facturé pour les déploiements en Erreur, qui sont automatiquement arrêtés après 24 heures.

Étapes de dépannage :

• Vérifiez le statut du service Edgegap avec notre page de surveillance de disponibilité.

• Essayez de tester votre conteneur serveur localement en utilisant Docker Desktop pour exclure les problèmes Edgegap.

Si vous avez besoin d'aide, veuillez nous contacter via Discord. Pour le support des jeux en direct, consultez notre système de billetterie.

Lorsque vous demandez de l'aide, incluez votre ID de déploiement et tous les détails utiles pour que nous puissions enquêter rapidement !

5. Déploiement arrêté

Nous n'arrêtons jamais vos serveurs sans votre directive, pour éviter d'impacter négativement l'expérience de vos joueurs. Votre déploiement peut être arrêté pour ces raisons :

• Auto-arrêt via DELETE_URL - le déploiement s'est arrêté lui-même après le départ des joueurs et la fin du match,

• Arrêt depuis votre backend - votre backend a arrêté ce déploiement en utilisant l'API des déploiements,

• Durée maximale du jeu - le temps alloué dans votre Applications et versions a expiré,

• Flottes privées L'hôte exécutant votre déploiement a été supprimé via une action planifiée.

Une fois qu'un déploiement est arrêté, nous déclenchons une terminaison en douceur en envoyant SIGTERM signal à votre processus principal, permettant une courte période de terminaison. Une fois expirée, un SIGKILL signal est envoyé pour arrêter le déploiement.

👀 Observabilité

Permettez aux serveurs de jeu d'interagir avec des tiers et obtenez des informations opérationnelles.

Découvrabilité

Une fois Prêt, le déploiement se voit attribuer une URL (fqdn) et un port externe pour chaque port interne.

Utilisez les tags de déploiement pour marquer facilement vos déploiements et Déploiements.

Le trafic sortant (vers les clients ou le backend) depuis vos serveurs de jeu n'est jamais bloqué ou filtré.

Websockets (WS) et Websockets sécurisés (WSS)

Pour utiliser le netcode basé sur websocket avec Edgegap, vous avez deux options :

• certificat géré, configuré en 1 minute sans écrire de code :

  • configurez votre Applications et versions vers utilisez Websocket (WS) et activez la montée en TLS,

  • utilisez l'URL Edgegap pour connecter les clients (par ex. https://5fa53fa00a57.pr.edgegap.net/)

• certificat auto-géré, si vous souhaitez utiliser votre propre domaine personnalisé :

  • configurez votre Applications et versions vers utilisez Secure Websocket (WSS),

  • configurez votre propre flux de certificat TLS avec un enregistrement DNS personnalisé (par ex. sur Cloudflare).

Les exceptions serveur non interceptées provoqueront le redémarrage du conteneur du déploiement et invalideront la sécurité TLS. Dans ce cas, arrêtez votre serveur et remappez les joueurs vers un nouveau déploiement. L'état du serveur peut être perdu.

Variables injectées

Les serveurs de jeu ont souvent besoin d'informations supplémentaires, telles que l'IP du serveur, les valeurs de ports internes, ou autre. L'injection de variables d'environnement en lecture seule est un moyen fiable et agnostique au cloud de transmettre des paramètres.

Obtenez les valeurs des variables en utilisant GetEnvironmentVariable en C# ou GetEnvironmentVariable en C++.

Voir Variables de version de l'application et Variables du matchmaker en plus des Variables de déploiement ci-dessous.

Variables personnalisées

Définissez jusqu'à 20 variables personnalisées pour chaque déploiement, chacune contenant jusqu'à 4 Ko de données de chaîne.

Évitez d'utiliser les noms réservés (ci-dessous), vos variables personnalisées seront écrasées sinon !

Accédez aux informations importantes en lisant les variables injectées dans vos serveurs par Edgegap :

Identifiants

• ARBITRIUM_REQUEST_ID - par ex. f68e011bfb01 .

  • ID de déploiement unique, également appelé ID de requête. Utilisé pour récupérer plus d'informations.

  • Les URL de déploiement ont toujours le format {ARBITRIUM_REQUEST_ID}.pr.edgegap.net.

• ARBITRIUM_HOST_ID - par ex. alpha-north-america-70364ef8 .

  • Identifiant unique de la machine hébergeant votre déploiement, partagé avec d'autres déploiements.

• ARBITRIUM_PUBLIC_IP - par ex. 162.254.141.66 .

  • Adresse IP publique de cet hôte, pouvant être utilisée pour se connecter à la place de l'URL.

• ARBITRIUM_DEPLOYMENT_TAGS - par ex. tag1,tag2 .

  • Tags de déploiement définis par l'utilisateur séparés par des virgules, utiles pour une recherche et un filtrage faciles.

Spécifications des ressources

• ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY - par ex. 2000 , fréquence du processeur en MHz.

• ARBITRIUM_DEPLOYMENT_VCPU_UNITS - par ex. 256, unités vCPU allouées (1024 = 1 vCPU).

• ARBITRIUM_DEPLOYMENT_MEMORY_MB - par ex. 512, RAM allouée en Mo (1024 = 1 Go).

Gestion du cycle de vie

• ARBITRIUM_DELETE_URL - par ex. https://api.edgegap.com/v1/self/stop/9f511e17/660.

  • Appelable depuis le déploiement, le déploiement sera arrêté en douceur.

  • Nécessite un unique jeton à usage unique ARBITRIUM_DELETE_TOKEN dans l'en-tête Authorization

• ARBITRIUM_DELETE_TOKEN - par ex. 7df4cd933df87084b34ae80d8abde293.

• ARBITRIUM_CONTEXT_URL - par ex. https://api.edgegap.com/v1/context/9170f5211e17/17.

  • Appelable uniquement depuis le déploiement, renvoie plus de détails sur le déploiement.

  • Nécessite un unique ARBITRIUM_CONTEXT_TOKEN dans l'en-tête Authorization

• ARBITRIUM_CONTEXT_TOKEN - par ex. dfaf50b9333b9ee07b22ed247e4a17e6.

Découvrabilité

• ARBITRIUM_PORT_GAMEPORT_INTERNAL - par ex. 7777 , port interne pour l'écoute du serveur.

• ARBITRIUM_PORT_GAMEPORT_EXTERNAL - par ex. 31504 , port externe pour les connexions clients.

  • Les valeurs des ports externes sont randomisées pour chaque déploiement pour des raisons de sécurité.

• ARBITRIUM_PORT_GAMEPORT_PROTOCOL - par ex. UDP , protocole de votre transport netcode.

Les exemples supposent que vous avez nommé votre port gameport (par défaut). Chaque port ajoute un ensemble supplémentaire de Applications et versions variables assainies : @Super Port ! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .

• ARBITRIUM_BEACON_ENABLED - par ex. true, si déployé sur une flotte privée exécutant Balises de ping.

• ARBITRIUM_HOST_BEACON_PUBLIC_IP - par ex. 139.177.198.69 , IP publique du beacon le plus proche.

• ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL - par ex. 30199, pour la mesure du ping sur UDP.

• ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL - par ex. 30456, pour la mesure du ping sur TCP.

Informations structurées (JSON en tant que chaîne)

Les variables d'environnement sont stockées comme des JSON sérialisés en chaîne, analysez-les en utilisant un SDK ou une méthode personnalisée.

ARBITRIUM_DEPLOYMENT_LOCATION: - Informations détaillées sur l'emplacement du déploiement.

ARBITRIUM_DEPLOYMENT_LOCATION="{
  "city": "Montréal",
  "country": "Canada",
  "continent": "Amérique du Nord",
  "administrative_division": "Québec",
  "timezone": "Heure de l'Est",
  "latitude": 45.513707,
  "longitude": -73.619073
}"

ARBITRIUM_PORTS_MAPPING: - Informations détaillées sur vos ports internes et externes.

ARBITRIUM_PORTS_MAPPING="{
  "ports": {
    "gameport": {
      "name": "Game Port",
      "internal": 7777,
      "external": 31504,
      "protocol": "UDP"
    },
    "webport": {
      "name": "Port Web",
      "internal": 8888,
      "external": 31553,
      "protocol": "TCP"
    }
  }
}"

Surveillance du tableau de bord

Notre Tableau de bord fournit des outils pour surveiller l'évolutivité de votre serveur et assister les opérations.

Analytique

Trouver tableaux de bord analytiques dans le menu latéral sous la catégorie Hébergement & Orchestration de Serveur.

🌟 Passez au niveau Paiement à l'usage pour débloquer des metrics et des analyses détaillées des performances du serveur :

• Informations générales : surveillez les releases avec le nombre de serveurs en direct par version + aperçu de l'utilisation des ressources,

• Informations CPU: dépannez les serveurs en retard dus à des opérations gourmandes en processeur,

• Informations Mémoire: atténuez les redémarrages de serveurs dus au dépassement de la mémoire allouée,

• Informations Réseau : détectez les schémas réseau inefficaces et optimisez le netcode.

Carte de déploiement

Trouvez la carte de déploiement dans la page des détails de votre déploiement sur le Tableau de bord.

Aperçu de l'emplacement de déploiement, des emplacements disponibles et des emplacements estimés des joueurs sur la carte :

Points d'équilibre de déploiement

Trouvez la heatmap des points d'équilibre de déploiement dans la page des détails de votre application sur le Tableau de bord.

Aperçu de la heatmap des points d'équilibre de déploiement et filtrez par Applications et versions. Les points d'équilibre sont des emplacements approximatifs ayant une proximité réseau égale pour chaque joueur dans un déploiement donné :

Des points d'équilibre concentrés dans des endroits étranges (par ex. le Groenland) indiquent un matchmaking de joueurs éloignés les uns des autres. Découvrez Déploiements et Balises de ping pour optimiser votre matchmaking.

Journaux de déploiement

Trouvez les journaux de déploiement dans la page des détails de votre déploiement sur le Tableau de bord.

Les journaux de déploiement affichent des informations sur Déploiements:

Journaux de conteneur

Trouvez les journaux de conteneur dans la page des détails de votre déploiement sur le Tableau de bord.

Inspectez les journaux de votre serveur de jeu en cas de problèmes, ou lors du débogage :

Une fois le déploiement arrêté, les journaux de conteneur sont supprimés. Configurez un stockage de journaux S3 tiers pour sauvegarder les journaux.

Métriques de conteneur

Trouvez les métriques de conteneur dans la page des détails de votre déploiement sur le Tableau de bord.

Passez en revue les métriques de conteneur (processeur, mémoire, réseau) pour :

• identifier les problèmes de connexion courants lorsque Déploiements,

• détecter des schémas d'implémentation inefficaces causant des pics d'utilisation des ressources,

• localiser une utilisation inefficace des ressources dans des scénarios particuliers,

• vérifier les changements dans l'utilisation des ressources de votre serveur lors d'optimisations,

• évaluer la consommation de ressources et la durée d'initialisation de votre serveur.

Les métriques historiques affichent des moyennes de valeur sur des périodes d'une minute, disponibles dans le niveau Gratuit.

🌟 Passez au niveau Paiement à l'usage pour débloquer des métriques précises avec des intervalles d'une seconde.

Contactez-nous avant votre release pour demander un support d'hébergement en direct pour des releases à grande échelle.

Contexte & Statut

Des informations supplémentaires sur le déploiement peuvent être récupérées au format JSON :

• depuis l'intérieur du déploiement (serveur de jeu), en utilisant API Contexte de Déploiement,

• depuis l'extérieur du déploiement (backend / tiers), en utilisant API Statut de Déploiement.

L'API Contexte (depuis le déploiement) requiert un token de l'API Contexte, tandis que l'API Statut utilise votre token Edgegap.

Trop de requêtes 429 - nous limitons votre organisation à 10 req/s pour les endpoints des API Contexte et Statut. Utilisez Variables injectées et Webhooks pour une solution évolutive.

Filtrer les déploiements

Pour rechercher rapidement parmi tous les déploiements, vous pouvez utiliser notre tableau de bord:

Alternativement, laissez les joueurs choisir un serveur persistant (toujours en ligne) à partir d'une liste avec Navigateur de serveurs.

Lister les déploiements avec l'API et appliquer des filtres avec des intégrations backend :

Attribut de déploiement	Opérateurs	Valeur d'exemple
statut	eq ou neq	"ready" ou "error"
request_id	eq	"7e709a0d8efd"
	dans ou nin	[ "7e709a0d8efd", "4ba353100b4b" ]
tags	eq ou neq	"tagA"
	dans ou nin	[ "tagA", "tagB" ]
created_at	eq ou lte ou gte	2025-05-12T20:03:20Z
application	eq ou neq	"mon-app"
	dans ou nin	[ "mon-app", "mon-autre-app" ]
version	eq ou neq	"1.0.0"
	dans ou nin	[ "1.0.0", "prod" ]
is_joinable_by_session	eq	true ou false
available_session_sockets	eq ou neq ou lt ou lte ou gt ou gte	5

Chaque attribut ne peut avoir au plus qu'un opérateur de filtre dans une seule requête. Voir Référence API pour plus d'informations.

Trie les résultats par plusieurs champs dans l'ordre d'apparition dans la requête :

Attribut de déploiement	Ordre
created_at	asc ou desc
available_session_sockets	asc ou desc

Exemples de requêtes de filtre :

Liste Déploiements en Erreur pour dépanner et supprimer.

URL encodée :

https://api.edgegap.com/v1/deployments?query={"filters":[{"field":"status","operator":"eq","value":"error"},{"field":"application","operator":"eq","value":"my-app"},{"field":"version","operator":"eq","value":"green"}],"order_by":[{"field":"created_at","order":"desc"}]}

Requête JSON formatée :

{
  "filters": [
    {
      "field": "status",
      "operator": "eq",
      "value": "error"
    },
    {
      "field": "application",
      "operator": "eq",
      "value": "my-app"
    },
    {
      "field": "version",
      "operator": "eq",
      "value": "green"
    }
  ],
  "order_by": [
    {
      "field": "created_at",
      "order": "desc"
    }
  ]
}

Liste Déploiements avec version d'application obsolète pour confirmer qu'une release est complète.

URL encodée :

https://api.edgegap.com/v1/deployments?query={"filters":[{"field":"status","operator":"eq","value":"ready"},{"field":"application","operator":"eq","value":"my-app"},{"field":"version","operator":"eq","value":"blue"}],"order_by":[{"field":"created_at","order":"desc"}]}

Requête JSON formatée :

{
  "filters": [
    {
      "field": "status",
      "operator": "eq",
      "value": "ready"
    },
    {
      "field": "application",
      "operator": "eq",
      "value": "my-app"
    },
    {
      "field": "version",
      "operator": "eq",
      "value": "blue"
    }
  ],
  "order_by": [
    {
      "field": "created_at",
      "order": "desc"
    }
  ]
}

Liste Déploiements avec capacité de sockets de session disponible pour rejoindre.

URL encodée :

https://api.edgegap.com/v1/deployments?query={"filters":[{"field":"status","operator":"eq","value":"ready"},{"field":"application","operator":"eq","value":"my-app"},{"field":"version","operator":"eq","value":"prod"},{"field":"is_joinable_by_session","operator":"eq","value":true},{"field":"available_session_sockets","operator":"gte","value":1}],"order_by":[{"field":"available_session_sockets","order":"desc"},{"field":"created_at","order":"asc"}]}

Requête JSON formatée :

{
  "filters": [
    {
      "field": "status",
      "operator": "eq",
      "value": "ready"
    },
    {
      "field": "application",
      "operator": "eq",
      "value": "my-app"
    },
    {
      "field": "version",
      "operator": "eq",
      "value": "prod"
    },
    {
      "field": "is_joinable_by_session",
      "operator": "eq",
      "value": true
    },
    {
      "field": "available_session_sockets",
      "operator": "gte",
      "value": 1
    }
  ],
  "order_by": [
    {
      "field": "available_session_sockets",
      "order": "desc"
    },
    {
      "field": "created_at",
      "order": "asc"
    }
  ]
}

N'oubliez pas d'ajouter l'en-tête l'en-tête avec votre token API Edgegap dans la requête.

Webhooks & Postbacks

Si vous avez besoin de recevoir une simple notification HTTP lorsqu'un déploiement est Prêt ou en Erreur, vous pouvez spécifier une URL de webhook dans votre requête API de déploiement.

Les webhooks ne sont pas réessayés, donc si votre backend ne traite pas la requête en raison d'une limitation de débit ou d'une erreur, le webhook peut être perdu. Utilisez les webhooks uniquement pour cas d'utilisation non critiques ou à des fins de débogage.

Pour des observateurs de déploiement fiables, implémentez un réessai exponentiel avec jitter ou interrogez API Statut de Déploiement.

🚨 Dépannage

Lors du dépannage des déploiements :

1. vérifiez qu'il n'y a pas d'erreurs dans votre Déploiements et Déploiements,

2. exécutez votre serveur localement pour écarter des bugs d'intégration,

3. consultez les étapes de dépannage sur cette page,

4. contactez-nous sur Discord Communautaire et incluez votre ID de déploiement.

Voir Déploiements pour nos recommandations sur la gestion des retours de la communauté de joueurs.

Impossible de connecter les clients au serveur - La requête a expiré., 请求超时 , ConnectionFailed , ou Échec de la vérification du port.

• Tout d'abord, assurez-vous que le déploiement est Prêt, et qu'il n'y a pas d'exceptions d'exécution ou d'erreurs dans votre journal de déploiement. Si votre déploiement s'est arrêté, inspectez les journaux dans notre Tableau de bord.

• Si vous utilisez le netcode Mirror, vous devez avoir "Démarrage automatique du serveur" sélectionné dans votre NetworkManager , reconstruisez, poussez et redéployez votre serveur.

• Si vous utilisez le netcode FishNet, vous devez activer « Démarrer en mode Headless » dans votre ServerManager, reconstruisez, poussez et redéployez votre serveur.

• Si vous utilisez le netcode Photon Fusion 2, veuillez vous assurer que votre serveur transmet l'IP publique du déploiement, le port externe et le roomCode sur le serveur, et le même code de salle dans le client dans le paramètre « NeworkRunner.StartGame » paramètre StartGameArgs. L'ID de déploiement (par ex. b63e6003b19f) est un excellent choix car il est globalement unique et facilement accessible au client via Matchmaker attribution et au Analyse approfondie.

• Ensuite, veuillez vérifier que le paramètre de port dans les réglages netcode de votre build serveur correspond au port interne dans votre Version de l'application. Vous pouvez changer le mapping des ports en éditant le Version de l'application sans reconstruire. Trouvez votre protocole dans votre intégration netcode.

• Veuillez vous assurer que votre client de jeu se connecte au port externe affiché sur la page des détails du déploiement ; cette valeur sera toujours randomisée pour des raisons de sécurité.

• Si vous utilisez le protocole Websocket sécurisé (WSS) dans votre intégration netcode, veuillez vous assurer que la Version de l'application configuration du port pour le port WSS a la mise à niveau TLS activée.

• Êtes-vous situé en Chine et utilisez-vous Flottes Intelligentes ? Votre connexion peut être bloquée par le Grand Firewall. Envisagez d'ajouter un serveur situé en Chine à votre flotte, ou d'utiliser un VPN pour vous connecter.

Mon déploiement s'est arrêté/redémarré et je n'ai plus accès à ses journaux.

• Dans le cas où le processus du serveur plante à cause d'une exception, notre système tentera de redémarrer automatiquement le serveur. Envisagez de tester votre serveur localement pour découvrir la cause première.

• Nous conservons les journaux uniquement pendant la durée du déploiement ; si vous souhaitez inspecter les journaux après l'arrêt du déploiement, veuillez intégrer un stockage de journaux tiers.

• Voir Déploiements pour découvrir toutes les causes de l'arrêt de votre déploiement.

Mon déploiement s'est arrêté automatiquement après X minutes.

• Les déploiements du niveau Gratuit ont une limite de 60 minutes ; envisagez de mettre à niveau votre compte.

• Tous les déploiements seront terminés après 24 heures d'exécution conformément à notre politique de nettoyage des serveurs, pour la maintenance de l'infrastructure et pour éviter des coûts imprévus lorsque le déploiement n'a pas été arrêté correctement. Pour les serveurs de longue durée, envisagez d'utiliser Flottes Intelligentes.

• Voir Déploiements pour découvrir toutes les causes de l'arrêt de votre déploiement.

Mon déploiement est prêt mais je ne peux pas me connecter pendant plusieurs minutes après.

• Une fois qu'un déploiement est Prêt, l'initialisation de votre moteur de jeu commence. Ce processus peut prendre de quelques secondes à plusieurs minutes, et le serveur n'accepte pas les connexions de joueurs pendant cette période.

• Envisagez d'optimiser l'initialisation de votre serveur pour réduire cette période.

• Les clients de jeu doivent retenter la connexion à des intervalles d'une seconde pendant une durée limitée (selon la durée de votre initialisation), après quoi ils retournent au matchmaking.

• Envisagez d'ajouter une scène de chargement afin que le serveur puisse effectuer l'initialisation (et le travel dans le cas d'Unreal Engine) en même temps que les clients, tout en synchronisant l'état des deux.

Mon appareil Meta Quest renvoie HTTP 0 : Impossible de résoudre l'hôte de destination .

• Lors de la construction d'applications Unity pour la cible Android, la permission d'accès à Internet peut être supprimée automatiquement de l'APK client généré.

• Réajoutez les permissions dans (nécessite de reconstruire le client ensuite) :

  • Project Settings / OpenXR / ⚙️ Meta Quest Support / Forcer la suppression des permissions Internet (désélectionner).

  • Player Settings / Internet Access (définir sur require).

Que se passe-t-il si un joueur quitte mon déploiement ?

• Par défaut, les serveurs n'acceptent pas le rejet des connexions de joueurs. L'authentification des joueurs dépend de vos développeurs, car de nombreuses méthodes et fournisseurs d'authentification peuvent être utilisés.

• Les clients de jeu peuvent stocker localement les informations de connexion pour tenter de se reconnecter en cas de plantage inattendu du client.

• Pour permettre aux joueurs de rejoindre des parties en cours, envisagez d'utiliser Analyse approfondie ou Sessions.

Mon serveur affiche 100 % d'utilisation CPU après être devenu prêt.

• Cela peut ne pas être un problème, car les moteurs de jeu ont tendance à effectuer des opérations lourdes en CPU pendant l'initialisation du serveur. Si l'utilisation du CPU ne baisse pas après 2-3 minutes depuis le démarrage du déploiement, vous devrez peut-être optimiser votre serveur ou augmenter les ressources de la version de l'application.

• Réduire le tick rate peut impacter l'utilisation du CPU car le serveur effectue moins d'opérations de messagerie.

• Si vous utilisez le netcode Mirror, vous devez avoir "Démarrage automatique du serveur" sélectionné dans votre NetworkManager , reconstruisez, poussez et redéployez votre serveur.

• Si vous utilisez le netcode FishNet, vous devez activer « Démarrer en mode Headless » dans votre ServerManager, reconstruisez, poussez et redéployez votre serveur.

• Vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM) dans le niveau Gratuit.

• Vous pouvez augmenter les ressources allouées lors de la création d'une nouvelle version d'application. Vous pouvez dupliquer votre version d'application dans notre Tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ou image.

Mon déploiement redémarre en boucle et affiche l'erreur `OOM kill`.

• Ce comportement est causé par le dépassement de la quantité de mémoire allouée. Envisagez d'optimiser l'utilisation de la mémoire avec du pooling d'objets, de la compression ou en supprimant les objets inutiles dans votre scène.

• Assurez-vous que votre projet charge la scène par défaut contenant votre NetworkManager et que la scène est incluse dans les Build Settings de Unity.

• Vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM) dans le niveau Gratuit.

• Vous pouvez augmenter les ressources allouées lors de la création d'une nouvelle version d'application. Vous pouvez dupliquer votre version d'application dans notre Tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ou image.

Parfois, l'utilisation de la mémoire (RAM) de mon serveur monte en pic à une valeur élevée ; est-ce un problème ?

• Tant que vous restez dans la quantité de mémoire allouée à la version d'application, ce n'est pas un problème.

• Dépasser la quantité de mémoire allouée à la version d'application provoquera un `OOM kill` (voir ci-dessus).

Les performances de mon serveur seront-elles impactées par d'autres serveurs s'exécutant sur la même machine ?

• Non, notre plateforme garantit que les ressources allouées ne seront pas utilisées par d'autres studios ou d'autres serveurs sur l'infrastructure partagée. Avec Edgegap, il n'y a pas de voisins bruyants.