Vérifiez vous-même
Une page d’état tenue par l’éditeur est la page la moins fiable du site d’un éditeur, puisqu’elle est mise à jour par ceux qui passent une mauvaise journée. Ici, rien n’est mis à jour à la main : les lignes ci-dessous sont une vérification que votre propre navigateur exécute sur nos endpoints au chargement de la page, et la même vérification tient en une commande si vous préférez ne pas nous croire sur parole.
Les deux endpoints
Les deux répondent sans authentification et peuvent être interrogés par votre propre supervision. Un 200 signifie que le service tourne et joint ce dont il dépend.
- IngestionVérification…
- APIVérification…
Vérifié par votre navigateur au chargement de cette page, sur les deux adresses ci-dessous.
Une ligne « Pas de réponse » signifie que ce navigateur n’a pas pu aboutir. C’est généralement le service — mais un proxy d’entreprise, une extension ou votre propre réseau produisent exactement le même résultat, et c’est pourquoi les commandes ci-dessous sont la vérification qui tranche.
curl -sS -o /dev/null -w "%{http_code}\n" https://ingest.snagspy.com/healthz
curl -sS -o /dev/null -w "%{http_code}\n" https://api.snagspy.com/healthzPointez votre propre moniteur de disponibilité vers ces adresses. Une page d’état qu’il faut aller consulter est une notification que vous ne recevrez pas ; une vérification à l’intérieur de vos propres alertes en est une que vous recevrez.
Ce qui casse quand quoi tombe
| Si ceci est indisponible | Ce qui vous arrive |
|---|---|
| L’ingestion | La nouvelle télémétrie n’est plus acceptée. Votre SDK et votre collecteur tamponnent et réessaient : une courte panne coûte de la latence plutôt que des données ; une longue coûte ce que la file de votre exporter n’a pas pu retenir. |
| L’API | Le tableau de bord ne se charge pas et l’API REST ne répond pas. L’ingestion est un service distinct et continue d’accepter la télémétrie. |
| Le site public | Ces pages sont des fichiers statiques en périphérie. Elles peuvent fonctionner pendant que la plateforme est en panne — c’est pourquoi cette page vous dit d’interroger les endpoints plutôt que de vous fier au fait que vous la lisez. |
Comment un incident vous parvient
Par e-mail, à l’adresse du compte, depuis un domaine d’expédition vérifié. La vérification en haut de cette page est en direct, mais c’est une vérification et non un historique : il n’y a pas encore d’archive des incidents ni d’abonnement, et votre propre moniteur pointé sur ces deux adresses vous préviendra toujours plus tôt que nous.
Si quelque chose semble anormal alors que les endpoints répondent, écrivez à [email protected] avec l’heure et le projet. Un signalement de client pendant un incident vaut mieux que n’importe quel tableau de bord que nous avons.
Ce qui est protégé, et comment
- Tout le trafic entrant atteint la plateforme par un tunnel chiffré ; la machine n’expose aucun port directement sur Internet.
- Les sauvegardes sont prises et rangées hors du disque qu’elles protègent, seul arrangement dans lequel une sauvegarde en est une.
- Les plafonds de conservation sont tenus par une tâche planifiée et vérifiés de nouveau à la lecture : une tâche en retard ne peut pas ressusciter des données au-delà de leur fenêtre.
- Une télémétrie au-delà d’une offre est signalée plutôt que refusée : un incident qui provoque un pic ne vous fait pas aussi perdre les preuves de ce pic.
Lisez ensuite la page sécurité
Cette page parle de disponibilité. Le chiffrement, les accès, la conservation et la liste complète des tiers qui voient vos données sont documentés à part, et plus en détail.