Surveillance
Santé des serveurs
Comme un moniteur d'activité pour vos serveurs. @blipit/node 0.2 et plus envoie les signes vitaux de chaque serveur toutes les 30 secondes, et la page Santé des serveurs les affiche en direct, une ligne par serveur, avec des graphiques sur la dernière heure, 24 heures ou 7 jours.
1L'activer
Rien à ajouter : il démarre avec Blipit.init. Donnez à chaque app un serverName pour regrouper ses serveurs sous un même nom.
Blipit.init({
key: process.env.BLIPIT_SECRET_KEY,
serverName: "api",
});2Ce que chaque serveur envoie
- Le CPU utilisé par le processus, 100 % correspondant à un cœur entier.
- La mémoire utilisée par le processus, et le remplissage de la mémoire de la machine.
- Le tas JavaScript utilisé et total.
- Le retard de la boucle d'événements au 99e centile : combien de temps les requêtes attendent pendant que le serveur est occupé.
- Les handles ouverts, comme les sockets et les minuteurs.
- Les connexions à la base de données des pools pg : utilisées, libres et en attente. En attente signifie que des requêtes font la queue pour une connexion.
3Lire la page
En direct signifie que le serveur envoie des données ; Ne répond plus signifie qu'il s'est tu. Choisissez un serveur pour voir ses graphiques. La page se rafraîchit toutes les 30 secondes tant qu'elle est ouverte.
4Être alerté
Dans Alertes, section Alertes dépendances et serveurs, fixez votre propre limite pour chaque alerte ou désactivez-la.
- CPU élevé : le CPU d'un serveur reste au-dessus de votre limite.
- Mémoire presque pleine : l'utilisation mémoire d'un serveur reste au-dessus de votre limite.
- Réponses lentes : la boucle d'événements d'un serveur est bloquée plus longtemps que votre limite, et les requêtes attendent.
- Ne donne plus de nouvelles : tous les serveurs d'un service cessent d'envoyer des données, par exemple après un crash.
5Autres technologies
Envoyez des métriques OpenTelemetry en OTLP JSON à https://in.blipit.io/v1/metrics avec l'en-tête X-Blipit-Key. Blipit lit process.cpu.utilization, process.memory.usage, system.memory.utilization, system.cpu.load_average.1m, db.client.connections.usage et les métriques de boucle d'événements de Node.js ; service.instance.id nomme le serveur.
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://in.blipit.io/v1/metrics
OTEL_EXPORTER_OTLP_METRICS_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_HEADERS=X-Blipit-Key=blipit_sk_your_secret_key6Fonctions serverless
Les applications sur Vercel, AWS Lambda, Netlify ou Azure Functions tournent sous forme de nombreuses instances de courte durée, en pause entre deux requêtes. Santé du serveur les regroupe en une ligne par plateforme, par exemple Fonctions Vercel, avec le nombre d'instances vues et leur mémoire, au lieu de lister chaque instance comme un serveur. Le CPU et Ne remonte plus sont omis car une instance en pause ne remonte ni l'un ni l'autre de façon utile, et les instances serverless ne déclenchent jamais d'alerte de CPU élevé, de réponse lente ou d'arrêt des remontées.
Bon à savoir
- metrics: false le désactive ; metricsIntervalMs change l'intervalle de 30 secondes, jusqu'à 10 secondes minimum.
- Gardé aussi longtemps que les spans : 7 jours sur Free et Solo, 14 jours sur Team et Scale. Les données serveur ne comptent dans aucun quota.
- Le pourcentage de mémoire utilise la mémoire totale de la machine. Dans un conteneur dont la limite de mémoire est inférieure à celle de l'hôte, regardez plutôt Mémoire utilisée.
Bloqué ? Écrivez à support@blipit.io. Les clés et l'identifiant de chaque projet sont sous Clés API dans app.blipit.io.