La collecte de métriques sur les serveurs, les applications et le trafic est une partie importante d'un projet de développement d'applications. De nombreux problèmes peuvent survenir dans les systèmes de production, et la collecte et l'organisation des données peuvent aider à identifier les goulots d'étranglement et les problèmes d'infrastructure.
Dans cet article, nous aborderons Graphite et StatsD, et comment ils peuvent aider à former la base de votre infrastructure de surveillance. Réservez la démo gratuite de MetricFire (https://www.metricfire.com/demo/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Monitoring%20your%20infrastructure%20with%20StatsD%20and%20Graphite) pour voir vos besoins Alors inscrivez-vous pour un essai gratuit de Hosted Graphite, un service Graphite géré.
Graphite est une bibliothèque composée de plusieurs composants. Voici une brève description de chaque composant.
L'application Web Graphite est l'endroit où vous pouvez créer des graphiques et tracer des données. Les applications Web peuvent enregistrer les propriétés et les mises en page des graphiques.
Carbon Carbon est le backend de stockage de Graphite. Carbon est essentiellement un démon qui peut être configuré pour s'exécuter sur des ports TCP / UDP. Pour gérer la charge croissante et configurer la réplication et le partitionnement, vous pouvez exécuter plusieurs démons Carbon sur le même ou plusieurs hôtes et équilibrer la charge à l'aide de relais Carbon.
Whisper Whisper est le format de base de données utilisé par Graphite pour stocker les données.
Whisper réduit les dernières données haute résolution (secondes par seconde) à des résolutions inférieures, ce qui permet de conserver les données historiques pendant de longues périodes.
Maintenant que nous avons parlé de Graphite, parlons de StatsD.
StatsD StatsD est une application node.js. Il a été créé pour envoyer des points de données sur les réseaux, les serveurs et les applications et peut être rendu sous forme de graphiques.
https://hub.docker.com/r/graphiteapp/docker-graphite-statsd/ Utilisez l'image du docker située à
Ceci est un docker-compose.yml très simple:
version: "3"
services:
graphite-statsd:
image: graphiteapp/docker-graphite-statsd
ports:
- 2003-2004:2003-2004
- 2023-2024:2023-2024
- 8125:8125/udp
- 8126:8126
- 80:80
Après avoir exécuté cette image Docker, lorsque vous accédez à http: // localhost, le navigateur charge l'application Web Graphite comme suit:
À ce stade, la métrique Graphite doit être vide. Testons le déploiement. Envoyez une métrique simple au démon StatsD à l'aide de la commande suivante:
echo "deploys.test.myservice:1|c" | nc -w 1 -u localhost 8125
La syntaxe ici est:
bucket:value|type
Le bucket est l'identifiant de la métrique. Les datagrammes métriques du même compartiment et du même type sont considérés par le serveur comme ayant le même événement. Dans l'exemple ci-dessus, nous avons utilisé "deploys.test.myservice" comme compartiment.
La valeur est le nombre associé à la métrique. La signification de la valeur dépend du type de métrique.
Le type détermine le type de métrique. Il existe différents types de métriques tels que les minuteries, les compteurs, les jauges et les histogrammes.
Les minuteries sont différentes des compteurs car elles mesurent des intervalles de temps. Par exemple, si vous souhaitez mesurer le temps nécessaire à l'API REST pour répondre, utilisez un minuteur. Une seule métrique pour la minuterie, par exemple 100 ms, n'est pas très utile. Il est plus pratique de combiner à des intervalles de temps tels que 6 heures. Diverses sous-mesures telles que la moyenne, l'écart type, le 50e centile, le 90e centile, le 95e centile, etc. sont automatiquement calculées pour chaque métrique.
echo "deploys.test.myservice.time:55|ms" | nc -w 1 -u localhost 8125
Les jauges sont utilisées pour les valeurs fixes qui peuvent être augmentées ou diminuées. Par exemple, les jauges peuvent être utilisées pour représenter le nombre de threads dans une application ou le nombre de travaux dans une file d'attente.
Il s'agit d'une application Web carbone qui affiche à la fois les valeurs du compteur et du minuteur dans un graphique.
Nous venons de voir comment envoyer des métriques via la ligne de commande. En réalité, certaines applications, telles que Node.js et les applications exécutant des serveurs Java, génèrent des métriques, de sorte que ces exemples ne s'appliquent pas.
Voyons maintenant comment une application écrite en node.js envoie des métriques. Considérez un serveur rapide fonctionnant sur le port 3000, comme illustré ci-dessous.
const express = require("express");
const app = express();
app.get("/", (req, res) => {
res.send("Response from a simple GET API");
});
app.listen(3000, () => {
console.log("Node server started on port 3000");
});
Tout d'abord, vous devez installer node-statsd en utilisant npm.
npm i node-statsd --save
Créez ensuite une instance du client StatsD comme suit:
const StatsD = require("node-statsd"), client = new StatsD();
Le constructeur StatsD prend plusieurs arguments facultatifs, tels que l'hôte et le port de la machine exécutant le serveur StatsD. La documentation complète https://github.com/sivy/node-statsd C'est dedans.
Dans mon cas, j'utilisais StatsD avec les options par défaut [http: // localhost](http: // localhost) et port8125.
Après avoir créé une instance du client, vous pouvez appeler différentes méthodes pour envoyer des métriques à votre application. Par exemple, vous pouvez suivre le nombre et le moment des appels d'API comme suit:
app.get("/", (req, res) => {
res.send("Response from a simple GET API");
client.increment("api_counter");
client.timing("api_response_time", 110);
});
Dès que vous tapez [http: // localhost: 3000](http: // localhost: 3000) dans votre navigateur, l'API est appelée et le client StatsD s'exécute. Vous pouvez voir les métriques mises à jour dans l'application Web Graphite.
Consultez la documentation sur [https: //github.com/sivy/node-statsd](https: //github.com/sivy/node-statsd) pour toutes les méthodes disponibles pour les instances client.
L'intégration avec les clients Java est très similaire à Node.js. Si vous utilisez un système de construction (fortement recommandé) tel que Maven ou Gradle, un fichier utilitaire (https://mvnrepository.com/artifact/com.timgroup/java-statsd-) pour faciliter cette intégration. client / 3.1.0) est disponible. Ajoutez ce qui suit à votre configuration de build pour l'inclure automatiquement.
<dependency>
<groupId>com.timgroup</groupId>
<artifactId>java-statsd-client</artifactId>
<version>3.1.0</version>
</dependency>
compile group: 'com.timgroup', name: 'java-statsd-client', version: '3.1.0'
Une fois la bibliothèque cliente importée, créez une instance de l'interface StatsDClient à l'aide de la classe d'implémentation NonBlockingStatsDclient, qui fournit le préfixe, le nom d'hôte et le port souhaités sur lesquels le serveur StatsD s'exécute.
Comme indiqué ci-dessous, cette interface vous permet d'utiliser des méthodes simples telles que time () et incrementCounter () pour envoyer du graphite au serveur StatsD. Pour une documentation complète, voir [https: //github.com/tim-group/java-statsd-client](https: //github.com/tim-group/java-statsd-client).
package example.statsd;
import com.timgroup.statsd.NonBlockingStatsDClient;
import com.timgroup.statsd.StatsDClient;
public class App {
private static final StatsDClient statsd = new NonBlockingStatsDClient("java.statsd.example.prefix", "localhost", 8125);
public static void main(String[] args) {
statsd.incrementCounter("java_main_method_counter");
statsd.time("java_method_time", 125L);
statsd.stop();
}
}
En ce qui concerne l'infrastructure, un seul serveur StatsD ne peut pas gérer toute la charge et nécessite finalement une mise à l'échelle horizontale. La mise à l'échelle horizontale avec StatsD n'est pas un simple équilibrage de charge circulaire, car vous pouvez également effectuer des agrégations avec StatsD. Si une métrique avec la même clé est distribuée sur plusieurs nœuds, un seul StatsD ne peut pas agréger avec précision la métrique entière.
Par conséquent, l'auteur de SatsD a publié un proxy de cluster StatsD qui utilise des hachages cohérents pour garantir que les mêmes métriques sont toujours envoyées à la même instance.
Vous trouverez ci-dessous une configuration très simple du proxy de cluster StatsD.
{
nodes: [
{host: 'host1', port: 8125, adminport: 8128},
{host: 'host2', port: 8125, adminport: 8130},
{host: 'host3', port: 8125, adminport: 8132}
],
server: './servers/udp',
host: '0.0.0.0',
port: 8125,
mgmt_port: 8126,
forkCount: 4,
checkInterval: 1000,
cacheSize: 10000
}
Une fois le fichier de configuration configuré, exécutez simplement:
node proxy.js proxyConfig.js
Proxy.js se trouve à la racine du répertoire d'installation de StatsD.
Certaines des clés de configuration méritent d'être expliquées:
StatsD et Graphite sont parfaits pour surveiller votre infrastructure. Tout le code et la configuration ci-dessus sont disponibles dans le référentiel github.
Les principaux avantages sont:
** Faible empreinte mémoire **: StatsD est un serveur basé sur node.js très simple, ce qui entraîne une très faible empreinte mémoire. Cela signifie que votre infrastructure peut facilement démarrer avec cette configuration.
** Réseau efficace **: StatsD peut fonctionner sur UDP, un protocole à faible connexion, permettant de transférer de grandes quantités de données en très peu de temps.
Si vous souhaitez essayer ces processus, veuillez réserver une démonstration de MetricFire en japonais (https://www.metricfire.com/demo/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Monitoring%20your%20infrastructure%20with] % 20StatsD% 20and% 20Graphite) S'il vous plaît. Vous pouvez également parler de la meilleure solution de surveillance.
Rendez-vous dans un autre article!