Un petit travail de scraping fonctionne ou ne fonctionne pas, et vous le découvrez rapidement. Un travail à grande échelle n’est jamais dans l’un ou l’autre état. À tout moment, une fraction de votre trafic échoue, et la question opérationnellement utile n’est pas « le proxy fonctionne-t-il » mais « quelle tranche de ceci s’est dégradée, et est-ce nous, le fournisseur, ou la cible. »
Obtenir une réponse utile signifie instrumenter selon les dimensions qui peuvent échouer indépendamment, ce qui n’est pas la même chose qu’ajouter plus de métriques. Voici ce qu’il faut mesurer, comment sonder sans gaspiller de bande passante, et comment distinguer les trois sources de défaillance.
La santé est par route, pas par proxy
La première correction : sur une passerelle mutualisée, vous n’avez pas de proxies à surveiller. Vous n’avez jamais choisi les adresses de sortie, vous ne les conservez pas, et une adresse ayant échoué une fois n’est pas une entité que vous pouvez suivre dans le temps. Ce que vous pouvez suivre, c’est une route, c’est-à-dire une combinaison des éléments que vous contrôlez : la cible, le pays, et le cas échéant la ville ou l’ASN.
L’unité de santé est donc la route. amazon-de, serp-us-chicago, marketplace-jp. Chacune a son propre taux de réussite, son profil de latence et son mix d’échecs, et chacune peut se dégrader tandis que les autres restent parfaites. Un seul chiffre global de « santé du proxy » moyenne exactement le signal dont vous avez besoin : quatre-vingt-quinze pour cent au global peut représenter vingt routes à quatre-vingt-dix-neuf pour cent et une route à zéro, et seule la seconde lecture vous indique qu’il faut agir.
Ajoutez la santé de session comme deuxième unité, plus éphémère. Une session persistante qui commence à recevoir des challenges devrait être retirée et remplacée plutôt que réutilisée, et cette décision revient au même composant qui distribue les sessions, comme décrit dans construire un gestionnaire de proxy.
Le passif d’abord : chaque requête réelle est un contrôle de santé
La surveillance la moins coûteuse est le trafic que vous envoyez déjà. Chaque requête en production produit un résultat, et si vous l’enregistrez par rapport à sa route, vous obtenez des données de santé continues sans coût de bande passante supplémentaire.
Le détail critique est ce qui compte comme un succès. Pas un 200. Une page de challenge, un résultat générique ou vide, une liste tronquée, ou une redirection vers une page d’atterrissage renvoient tous un 200 et signifient tous que votre collecte a échoué, donc un moniteur qui compte les codes de statut signalera une bonne santé tandis que le jeu de données se dégrade. Validez le corps par rapport à une attente spécifique à la cible avant d’enregistrer le résultat, ce qui est la discipline décrite dans détecter le contenu bloqué ou factice. Ce seul changement est ce qui distingue un tableau de bord de santé qui détecte les problèmes de celui qui confirme votre biais.
Enregistrez au minimum, par requête : la route, le résultat validé, la latence, les octets, et une classe d’échec si elle a échoué. Cela suffit pour calculer tout ce qui suit.
Classifiez les échecs, car la classe est le diagnostic
Compter les échecs vous indique que quelque chose ne va pas. Les classifier vous indique quoi. Cinq classes couvrent presque tout, et chacune pointe vers quelque chose de différent.
Les échecs d’authentification signifient des identifiants incorrects ou un indicateur de cible malformé, ce qui est un problème de configuration de votre côté et ne se résoudra pas au nouvel essai, selon corriger les erreurs 407 et d’identifiants. Les échecs d’absence de correspondance, où la passerelle n’a aucune adresse correspondant à votre filtre à ce moment, signifient que votre ciblage est trop restreint plutôt que quelque chose de cassé ; élargissez de la ville au pays et cela se résorbe. Les signaux de limitation, c’est-à-dire les 429 et apparentés, signifient que votre cadence est trop agressive pour cette cible, ce qui est un problème de throttling. Les signaux de blocage, c’est-à-dire les challenges et les 403 persistants, signifient que la cible a rejeté l’identité, donc retirez la session et demandez-vous si vos en-têtes ou votre empreinte sont la véritable cause. Les échecs de transport, c’est-à-dire les timeouts et les réinitialisations de connexion, sont la classe ambiguë et méritent leur propre enquête, car les raisons pour lesquelles les requêtes expirent incluent la lenteur de la cible, une route défaillante, et votre propre concurrence trop élevée.
Le mix compte plus que le total. Une route à quatre-vingts pour cent de réussite composée de signaux de limitation a besoin d’une cadence plus lente ; la même route à quatre-vingts pour cent composée de signaux de blocage a besoin d’une stratégie d’identité différente ; composée d’erreurs d’absence de correspondance, elle a besoin d’un ciblage plus large. Même chiffre, trois corrections différentes.
Des sondes actives, utilisées avec parcimonie
La surveillance passive a un angle mort : elle ne couvre que les routes que vous utilisez actuellement, donc une route programmée pour s’exécuter à 03h00 ne vous donne aucun avertissement à 22h00 qu’elle est cassée. Un petit ensemble de sondes actives combre cette lacune, mais elles coûtent de la bande passante, donc gardez-les peu coûteuses et ciblées.
Deux types valent la peine d’être exécutés. Une sonde de connectivité et de géolocalisation par pays, atteignant un petit point de terminaison qui renvoie l’adresse et sa localisation, confirme que la passerelle est accessible et que le pays que vous demandez est le pays que vous obtenez. Gardez-la légère, car c’est la sonde que vous exécutez le plus souvent. Un canari de cible par cible importante, récupérant une page connue comme stable et la validant, vous indique si cette cible spécifique répond normalement, ce qui est le contrôle qui distingue un problème de cible d’un problème de proxy.
import requests
def geo_probe(country):
proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
try:
r = requests.get("https://ipinfo.io/json",
proxies={"http": proxy, "https": proxy}, timeout=15)
d = r.json()
return {"ok": d.get("country","").lower() == country,
"got": d.get("country"), "org": d.get("org")}
except Exception as e:
return {"ok": False, "error": type(e).__name__}Exécutez les sondes de géolocalisation à une cadence lente sur les pays que vous utilisez réellement, et les canaris à une cadence adaptée au coût qu’aurait un échec silencieux. Alertez sur une sonde qui échoue à plusieurs reprises plutôt qu’une seule fois, car un échec unique sur un pool rotatif est un bruit normal.
Distinguer les trois sources de défaillance
C’est la question qui se pose réellement pendant un incident, et la réponse vient de la comparaison des signaux plutôt que d’une métrique unique.
Votre côté se manifeste par des échecs sur de nombreuses cibles sans rapport en même temps, commençant généralement exactement au moment où quelque chose a été déployé. Des échecs d’authentification partout, un pic d’erreurs de transport provenant d’un pool de workers, ou une hausse des erreurs d’absence de correspondance après que quelqu’un a resserré un filtre, tout cela pointe vers l’intérieur. L’indice est l’étendue : vos propres bugs respectent rarement les frontières des cibles.
Le fournisseur se manifeste par des échecs sur de nombreuses cibles mais confinés à la couche réseau : des sondes de connectivité qui échouent, des sondes de géolocalisation renvoyant le mauvais pays, des erreurs de transport en augmentation tandis que les canaris de cible qui passent bien renvoient toujours des pages valides. C’est aussi là qu’une page de statut publique trouve sa place, car corréler votre propre baisse avec l’historique des incidents du fournisseur répond immédiatement à la question, et le système de paliers qui régit ce qui vous est dû se trouve dans SLA et garanties de disponibilité des proxies.
La cible se manifeste par des échecs confinés à une seule cible tandis que toutes les autres routes restent saines, et le canari de cette cible échoue tandis que ses sondes de géolocalisation réussissent. Si elle échoue depuis toutes les régions simultanément, le site a probablement ses propres problèmes ; si elle échoue depuis une seule région, vous êtes face à un blocage spécifique à une géolocalisation ou à un problème d’edge régional.
Instrumentez de manière à ce que ces comparaisons ne prennent qu’une seule requête plutôt qu’un après-midi : les mêmes classes d’échec et résultats, marqués avec route, région et worker, suffisent.
Sur quoi alerter
Les tableaux de bord servent à enquêter, les alertes servent à réveiller quelqu’un. Gardez l’ensemble d’alertes restreint et rendez chacune actionnable.
Alertez sur le taux de réussite validé d’une route tombant sous sa propre référence glissante, pas un seuil global, car une route qui tourne normalement à soixante-dix pour cent contre une cible hostile est saine à soixante-dix pour cent et cassée à quarante pour cent. Alertez sur un changement dans le mix d’échecs, car une route maintenant son taux de réussite tandis que les signaux de blocage remplacent les signaux de limitation a changé de caractère d’une manière qui prédit des problèmes. Alertez sur l’augmentation du ratio de nouvelles tentatives, qui augmente avant que le taux de réussite ne baisse et constitue donc l’avertissement le plus précoce que vous obtenez. Alertez sur la couverture, c’est-à-dire une route programmée produisant sensiblement moins d’enregistrements que son historique récent, ce qui détecte une réduction silencieuse que le taux de réussite ne peut pas voir. Et alertez sur une sonde échouant à plusieurs reprises pour une région dont vous dépendez.
Exigez une déviation soutenue plutôt qu’un seul intervalle, et comparez par rapport à une référence glissante. Les définitions des métriques derrière tout cela se trouvent dans KPI des proxies résidentiels, et l’instrumentation au niveau du pipeline se trouve dans surveiller un pipeline de web scraping.
Faire en sorte que le système agisse en fonction de cela
Une surveillance qui ne produit que des graphiques laisse un humain dans la boucle pour des problèmes qu’une machine devrait gérer. Les mêmes signaux devraient piloter un comportement automatique : retirer une session qui accumule des signaux de blocage, ouvrir un disjoncteur sur une route dont le taux de réussite s’effondre afin d’arrêter d’alimenter une cible qui ne répond pas, déplacer le travail vers une autre région lorsqu’une se dégrade, selon basculement dans les pipelines multi-régions, et ralentir automatiquement lorsque des signaux de limitation apparaissent. Les humains devraient être alertés pour des choses qui nécessitent du jugement, pas pour des choses qui nécessitent une règle.
L’essentiel
À grande échelle, la santé n’est pas une propriété du proxy, c’est une propriété de chaque route que vous exécutez, donc instrumentez par cible et par région et laissez la santé de session être son propre signal éphémère. Jugez chaque résultat sur un corps validé plutôt que sur un code de statut, car c’est la différence entre surveiller et se mentir à soi-même. Classifiez les échecs, car le mix vous indique s’il faut ralentir, changer d’identité, élargir le ciblage, ou corriger votre propre configuration. Ajoutez une fine couche de sondes de géolocalisation et de canaris de cible pour couvrir les routes qui ne s’exécutent pas actuellement et pour distinguer les problèmes de fournisseur des problèmes de cible. Alertez ensuite sur une déviation soutenue par rapport à la référence propre de chaque route, sur les changements de mix d’échecs, et sur le ratio de nouvelles tentatives, et connectez les mêmes signaux à un retrait automatique, à un ralentissement et à un basculement afin que le système corrige ce qu’il peut avant que quiconque ne soit réveillé.
La couche sous-jacente est constituée des proxies résidentiels, où le ciblage par pays et ville et le contrôle des sessions sont exprimés par requête, ce qui fait de la santé au niveau de la route une question de marquage de vos propres requêtes plutôt qu’un projet d’intégration, avec une tarification par GB telle qu’une stratégie de sondage légère ne coûte presque rien face à la collecte elle-même.