Pré-alpha, en développement actif

Reniflez les métriques de n’importe quelle API, sans jamais exploser vos quotas.

Tapyr collecte les données des API REST de vos équipements réseau gérés dans le cloud, les normalise et les exporte en métriques Prometheus ou OTLP propres. Une définition déclarative par API, aucun code à écrire.

Voir le fonctionnement Lire la conception bientôt

Des API constructeurs à votre stack de métriques

VisuelCode

SD-WAN
SD-LAN
Wi-Fi
Routeurs 4G / 5G
Toute API SD-*

tapyrinterroge, pagine, réessaienormalise labels, unitésrespecte le budget quota

Prometheus
OTLP
Autres formats ?

Les logos Prometheus et OpenTelemetry sont des marques de leurs propriétaires respectifs.

Ce que renvoie l’API

API REST constructeur

GET /v1/devices?page=1
{
  "data": [{
    "id": "dev-0142",
    "name": "branch-12-ap",
    "status": "online",
    "signal": { "rssi": -61 }
  }, ...],
  "meta": { "next": 2 }
}

Définition du provider

YAML + CEL

metrics:
  - name: device_up
    value: item.status == "online"
  - name: signal_rssi_dbm
    value: item.signal.rssi
labels:
  device: item.name

Ce que vous obtenez

# every page, every device
tapyr_device_up{
  provider="wifi_cloud",
  device="branch-12-ap"} 1
tapyr_signal_rssi_dbm{
  provider="wifi_cloud",
  device="branch-12-ap"} -61

# OTLP, simplified
resource: provider=wifi_cloud
gauge device_up
  device=branch-12-ap  1
gauge signal_rssi_dbm
  device=branch-12-ap  -61

Illustration. Les noms de champs et de métriques sont des exemples, la syntaxe n’est pas définitive.

Et sans jamais épuiser votre quota

Les API cloud rationnent les appels de multiples façons, souvent plusieurs à la fois. Quand l’un de ces budgets est épuisé, tous vos équipements disparaissent des graphiques jusqu’à la fin de la fenêtre, et la cause se cache dans un en-tête de réponse.

par seconde
par minute
quotidien
hebdomadaire
mensuel
par organisation
concurrence

Tapyr déclare ces limites une fois par provider, planifie chaque appel en conséquence, garde une réserve pour les retries et exporte ses propres métriques de quota pour voir venir les problèmes.

Ce qu’affiche un tableau de bord quand un quota d’API est épuisé avant la fin de sa fenêtre. Illustration.

Fonctionnement

Vous décrivez une API une seule fois : ses endpoints, sa pagination, la façon dont son JSON devient des métriques et chaque limite qu’elle impose. Le moteur de budget planifie chaque appel selon ces limites, le collecteur récupère, le normaliseur transforme, les exporteurs livrent.

DéfinitionYAML + CEL par API
Moteur de budgetplanifie chaque appel selon les limites
Collecteurappelle l’API constructeur ou le simulateur intégré
Normaliseurnoms, labels, unités
ExporteursPrometheus, OTLP

tapyr planestime les appels par quota avant déploiement
Auto-métriques et UI webappels, 429, quota restant, fraîcheur

Les limites font partie de la config

Déclarez ce que le constructeur impose, une fois par provider. Puis demandez à Tapyr ce que vos jobs vont coûter avant de toucher à la vraie API.

Déclarer les limites

Un débit par organisation et un quota quotidien qui se resynchronise sur les en-têtes de l’API.

limits:
  - name: org-rate
    kind: rate
    rate: 10/s
    scope: { by: [account, "var:organizationId"] }
  - name: daily
    kind: quota
    max: auto
    initialMax: 5000
    window: { period: day, resetAt: "00:00", timezone: UTC }
    sync:
      limitHeader: X-RateLimit-Limit-day
      remainingHeader: X-RateLimit-Remaining-day

Planifier avant de déployer

tapyr plan estime ce que chaque fenêtre de quota va consommer, et étire les jobs peu prioritaires pour tenir.

$ tapyr planQUOTA SCOPE       BUDGET/DAY  PROJECTED  RESERVE  STATUSwifi-cloud/daily  4500        4212       450      ok (93.6%)  job wifi-aps      desired 5m   effective 5m                    288 runs x 3 pages  = 864  job wifi-clients  desired 5m   effective 15m                    96 runs x 30 pages  = 2880                    (stretched x3, priority low)

Ce qui arrive dans la v0.1

Tout ce qui suit est en développement. Rien n’est encore publié.

Plusieurs API en entrée, des métriques standard en sortie

Interrogez une ou plusieurs API constructeurs, suivez la pagination, normalisez noms, labels et unités, puis exportez des métriques propres.

Déclaratif

YAML et CEL. Une nouvelle API demande une définition, pas du code Go.

Les limites au premier plan

Toute fenêtre, toute portée, retries compris. Les budgets se resynchronisent sur les en-têtes de quota de l’API.

tapyr plan

Sachez ce qu’une config va consommer sur chaque quota avant de la déployer.

Simulateur intégré

Chaque provider est livré avec un simulateur qui applique les vraies limites. Pas besoin de compte chez le constructeur.

Se surveille lui-même

Appels, retries, 429, quota restant, épuisement projeté et fraîcheur des jobs, en métriques. Plus une UI web en lecture seule dans le binaire.

Open source, auto‑hébergé, conçu en Europe

Tapyr ne rendra pas souveraines les données issues de clouds américains. Il évite simplement d’ajouter un intermédiaire entre votre réseau et vos tableaux de bord.

Open source
Apache-2.0. Lisez-le, forkez-le, écrivez vos propres providers.
Auto-hébergé
Un seul binaire statique sur votre infrastructure. Pas de compte, pas de SaaS.
Sans intermédiaire
Pas de télémétrie, pas de tiers. Vos métriques restent chez vous.