Meilleures pratiques pour la configuration des limites de débit d’API

Une approche pilotée par les données des limites de débit d’API protège votre instance GitHub Enterprise Server contre une utilisation excessive sans perturber les intégrations critiques.

Qui peut utiliser cette fonctionnalité ?

Site administrators can configure rate limits for a GitHub Enterprise Server instance.

Dans cet article

À propos d’une approche pilotée par les données des limites de débit

Sans limites de débit, une intégration CI unique effectuant des dizaines de milliers de requêtes par heure peut ralentir l'ensemble de votre instance pour chaque utilisateur. Toutefois, la définition de limites trop agressives peut interrompre les intégrations sur lesquelles vos équipes s’appuient. Une approche pilotée par les données vous aide à trouver le bon équilibre, commencez par observer des modèles d’utilisation réels, puis appliquez progressivement des limites en fonction des données que vous collectez.

L’approche suit ces phases :

  1.        **Remarque** : activez le transfert de journal et analysez les modèles de trafic d’API.

  2.        **Base de référence** : activez les limites de débit avec une valeur initiale élevée pour commencer à collecter des données de limite de débit.

  3.        **Affiner** : ajustez les limites en fonction de l’utilisation observée et communiquez avec les équipes concernées.

  4.        **Maintenir** : surveillez et ajustez en continu les limites au fil du temps.

Pour plus d’informations sur l’activation des limites de débit via le Console de gestion, consultez Configuration des limites de débit.

Prerequisites

Avant de commencer, assurez-vous d’avoir :

  • Accès administrateur à la Console de gestion
  • Accès à la configuration du transfert de journalisation
  • Possibilité d’analyser les journaux centralisés
  • Compréhension des modèles d’utilisation des API de votre organisation et des intégrations critiques

Étape 1 : Activer le transfert de journal

Utilisez le transfert de journal pour centraliser les journaux des demandes d’API pour la surveillance et l’analyse. Pour plus d’informations, consultez « Transfert de journaux ».

Lors de l’analyse des journaux transférés, concentrez-vous sur ces champs clés :

TerrainDescription
TimestampEffectue le suivi du moment où les demandes sont effectuées
user / gh.actor.loginIdentifie l’utilisateur ou l’intégration qui effectue des demandes
path_info / gh.request.api.routeItinéraire d’API accessible
statusCode de réponse HTTP (par exemple, 200 pour réussir ou 429 quand le taux est limité)
user_agentIdentifie le client ou l’intégration envoyant la requête

Avant d’activer les limites de débit, analysez vos tendances d’utilisation globales pour établir une base de référence :

  •         **Identifiez les principaux consommateurs.** Recherchez des utilisateurs ou des intégrations faisant le plus grand nombre de requêtes.

  •         **Passez en revue les points de terminaison à forte demande.** Mettez en surbrillance les itinéraires d’API (`path_info`) qui reçoivent le plus de trafic et peuvent tirer parti de l’optimisation.

  •         **Détecter des modèles inefficaces.** Recherchez des signes d’utilisation inefficace ou lourde, comme l’interrogation fréquente sans mise en cache ou les demandes redondantes.

Ces données de base vous aideront à définir des limites de débit qui sont informées par l’utilisation réelle plutôt que par des estimations.

Étape 3 : Activer les limites de débit avec une valeur initiale élevée

Lorsque vous êtes prêt à activer les limites de débit, commencez par un seuil élevé afin de collecter des données supplémentaires sans perturber les flux de travail existants.

  1. Dans le Console de gestion, définissez la limite de débit d’API principale sur une valeur élevée, par exemple 25 000 requêtes par heure. Pour plus d’informations, consultez « Configuration des limites de débit ».

  2. Après avoir activé les limites de débit, surveillez les gh.rate_limit champs qui apparaissent dans vos journaux transférés :

    TerrainDescription
    gh.rate_limit.primary.maxNombre maximal de demandes autorisées
    gh.rate_limit.primary.remainingDemandes restantes dans la période actuelle
    gh.rate_limit.primary.usedDemandes déjà effectuées au cours de la période
    gh.rate_limit.primary.resetHorodatage Unix lorsque la période de limite de débit est réinitialisée

Étape 4 : Affiner les limites et traiter l’utilisation intensive

Utilisez les données des gh.rate_limit champs pour prendre des décisions éclairées :

  •         **Identifiez les utilisateurs proches de la limite.** Recherchez les utilisateurs ou les intégrations qui approchent fréquemment ou dépassent le seuil.

  •         **Déterminez les limites appropriées.** Définissez des limites de débit en fonction des tendances d’utilisation observées plutôt que des valeurs arbitraires.

  •         **Communiquez avec les équipes concernées.** Collaborez avec les équipes pour optimiser leur utilisation de l’API par le biais de techniques telles que le traitement par lots de requêtes, la mise en cache des réponses et les demandes conditionnelles.

Étape 5 : Réduire les limites et maintenir au fil du temps

Une fois que vous avez une image claire de l’utilisation de votre API, réduisez progressivement la limite de débit pour s’aligner sur la capacité de votre instance et les modèles d’utilisation réels. Surveillez les perturbations involontaires après chaque ajustement.

À mesure que vous affinez les limites, collaborez avec les équipes dont les intégrations sont affectées. Les techniques telles que le traitement par lots de requêtes, la mise en cache des réponses et les demandes conditionnelles peuvent aider les équipes à réduire leur utilisation de l’API. Vous pouvez également exempter des utilisateurs spécifiques des limites de débit à l’aide de l’utilitaire ghe-config . Pour plus d’informations, consultez « Utilitaires de ligne de commande ».

Passez en revue régulièrement vos données de limite de débit, car les modèles d’utilisation changent à mesure que de nouvelles intégrations sont ajoutées et que les flux de travail évoluent.

Considérations supplémentaires

  •         **Limites de l’API GraphQL.** L’API GraphQL a une limite de débit distincte (valeur par défaut : 5 000 points par heure) qui ne peut pas être contournée par le biais de la liste d’exemption. Pour plus d’informations, consultez « [AUTOTITLE](/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api) ».

  •         **Limites de taux secondaires.** Vous pouvez également activer les limites de débit secondaire pour protéger le niveau global de service. Pour plus d’informations, consultez « [AUTOTITLE](/admin/configuring-settings/configuring-user-applications-for-your-enterprise/configuring-rate-limits#enabling-secondary-rate-limits) ».

Lectures complémentaires

  •         [AUTOTITLE](/rest/overview/rate-limits-for-the-rest-api)