BLOG | NGINX

OpenTracing pour NGINX et NGINX Plus

NGINX-Partie-de-F5-horiz-black-type-RGB
Mohamed Gougam Miniature
Mohamed Gougam
Publié le 17 juin 2019

Malgré tous ses avantages, une architecture de microservices introduit également de nouvelles complexités. L’un des défis est de suivre les demandes au fur et à mesure de leur traitement, les données circulant entre tous les microservices qui composent l’application. Une nouvelle méthodologie appelée traçage distribué (requête) a été inventée à cette fin, et OpenTracing est un ensemble de spécifications et de normes d'API destinées à guider la conception et la mise en œuvre d'outils de traçage distribués.

Dans NGINX Plus Release 18 (R18) , nous avons ajouté le module NGINX OpenTracing à notre référentiel de modules dynamiques (il est disponible en tant que module tiers sur GitHub depuis quelques années maintenant). L’un des principaux avantages du module NGINX OpenTracing est qu’en instrumentant NGINX et NGINX Plus pour le traçage distribué, vous obtenez des données de traçage pour chaque application proxy, sans avoir à instrumenter les applications individuellement.

Dans ce blog, nous montrons comment activer le traçage distribué des requêtes pour NGINX ou NGINX Plus (pour plus de concision, nous ferons désormais simplement référence à NGINX Plus ). Nous fournissons des instructions pour deux services de traçage distribués ( traceurs , dans la terminologie OpenTracing), Jaeger et Zipkin . (Pour une liste d'autres traceurs, consultez la documentation OpenTracing .) Pour illustrer le type d’informations fournies par les traceurs, nous comparons le traitement des requêtes avant et après l’activation de la mise en cache NGINX Plus.

Un traceur comporte deux composants de base :

  • Un agent qui collecte les données de traçage des applications exécutées sur l'hôte sur lequel il s'exécute. Dans notre cas, l’« application » est NGINX Plus et l’agent est implémenté en tant que plug-in.
  • Un serveur (également appelé collecteur ) qui accepte les données de traçage d'un ou plusieurs agents et les affiche dans une interface utilisateur centrale. Vous pouvez exécuter le serveur sur l'hôte NGINX Plus ou sur un autre hôte, selon votre choix.

Installation d'un serveur Tracer

La première étape consiste à installer et configurer le serveur pour le traceur de votre choix. Nous fournissons des instructions pour Jaeger et Zipkin ; adaptez-les si nécessaire pour d'autres traceurs.

Installation du serveur Jaeger

Nous recommandons la méthode suivante pour installer le serveur Jaeger. Vous pouvez également télécharger des images Docker à l’URL spécifiée à l’étape 1.

  1. Accédez à la page de téléchargement de Jaeger et téléchargez le binaire Linux (au moment de la rédaction, jaeger-1.12.0-linux-amd64.tar ).

  2. Déplacez le binaire vers /usr/bin/jaeger (en créant d'abord le répertoire si nécessaire) et exécutez-le.

    $ mkdir /usr/bin/jaeger $ mv jaeger-1.12.0-linux-amd64.tar /usr/bin/jaeger $ cd /usr/bin/jaeger $ tar xvzf jaeger-1.12.0-linux-amd64.tar.gz $ sudo rm -rf jaeger-1.12.0-linux-amd64.tar.gz $ cd jaeger-1.12.0-linux-amd64 $ ./jaeger-all-in-one

  3. Vérifiez que vous pouvez accéder à l'interface utilisateur Jaeger dans votre navigateur, à l' adresse http:// Jaeger-server-IP-address :16686/ (16686 est le port par défaut du serveur Jaeger).

Installation du serveur Zipkin

  1. Téléchargez et exécutez une image Docker de Zipkin (nous utilisons le port 9411, la valeur par défaut).

    $ docker run -d -p 9411:9411 openzipkin/zipkin

  2. Vérifiez que vous pouvez accéder à l'interface utilisateur Zipkin dans votre navigateur, à l' adresse http:// Zipkin-server-IP-address :9411/ .

Installation et configuration d'un plug-in Tracer

Exécutez ces commandes sur l’hôte NGINX Plus pour installer le plug-in pour Jaeger ou Zipkin.

Installation du plug-in Jaeger

  1. Installez le plug-in Jaeger. La commande wget suivante est destinée aux systèmes Linux x86-64 :

    $ cd /usr/local/lib $ wget https://github.com/jaegertracing/jaeger-client-cpp/releases/download/v0.4.2/libjaegertracing_plugin.linux_amd64.so -O /usr/local/lib/libjaegertracing_plugin.so

    Les instructions pour créer le plug-in à partir de la source sont disponibles sur GitHub .

  2. Créez un fichier de configuration au format JSON pour le plug-in, nommé /etc/jaeger/jaeger-config.json , avec le contenu suivant. Nous utilisons le port par défaut pour le serveur Jaeger, 6831 :

    { "service_name": "nginx", "sampler": { "type": "const", "param": 1 }, "reporter": { "localAgentHostPort": " Adresse IP du serveur Jaeger : 6831 " } }

    Pour plus de détails sur l'objet échantillonneur , consultez la documentation Jaeger .

Installation du plug-in Zipkin

  1. Installez le plug-in Zipkin. La commande wget suivante est destinée aux systèmes Linux x86-64 :

    $ cd /usr/local/lib $ wget -O - https://github.com/rnburn/zipkin-cpp-opentracing/releases/download/v0.5.2/linux-amd64-libzipkin_opentracing_plugin.so.gz | gunzip -c > /usr/local/lib/libzipkin_opentracing_plugin.so

  2. Créez un fichier de configuration au format JSON pour le plug-in, nommé /etc/zipkin/zipkin-config.json , avec le contenu suivant. Nous utilisons le port par défaut pour le serveur Zipkin, 9411 :

    { "nom_service": "nginx", "hôte_collecteur": " Adresse IP du serveur Zipkin ", " port_collecteur " : 9411 }

    Pour plus de détails sur les objets de configuration, consultez le schéma JSON sur GitHub .

Configuration de NGINX Plus

Exécutez ces instructions sur l’hôte NGINX Plus.

  1. Installez le module NGINX OpenTracing conformément aux instructions du Guide d'administration NGINX Plus .

  2. Ajoutez la directive load_module suivante dans le contexte principal (de niveau supérieur) du fichier de configuration principal de NGINX Plus ( /etc/nginx/nginx.conf ) :

    charger_module modules/ngx_http_opentracing_module.so;

  3. Ajoutez les directives suivantes à la configuration NGINX Plus.

    Si vous utilisez le schéma de configuration conventionnel , placez les directives dans un nouveau fichier appelé /etc/nginx/conf.d/opentracing.conf . Vérifiez également que la directive d'inclusion suivante apparaît dans le contexte http dans /etc/nginx/nginx.conf :

    http {
include /etc/nginx/conf.d/*.conf;
}
    • La directive opentracing_load_tracer active le plug-in tracer. Décommentez la directive pour Jaeger ou Zipkin selon le cas.
    • Les directives opentracing_tag rendent les variables NGINX Plus disponibles sous forme de balises OpenTracing qui apparaissent dans l'interface utilisateur du traceur.
    • Pour déboguer l'activité OpenTracing, décommentez les directives log_format et access_log . Si vous souhaitez remplacer le journal d'accès et le format de journal NGINX par défaut par celui-ci, décommentez les directives, puis remplacez les trois instances de « opentracing » par « main ». Une autre option consiste à enregistrer l’activité OpenTracing uniquement pour le trafic sur le port 9001 – supprimez le commentaire des directives log_format et access_log et déplacez-les dans le bloc serveur .
    • Le bloc serveur configure OpenTracing pour l'exemple d'application Ruby décrit dans la section suivante .
    # Charger un traceur de fournisseur#opentracing_load_tracer /usr/local/libjaegertracing_plugin.so 
# /etc/jaeger/jaeger-config.json;
#opentracing_load_tracer /usr/local/lib/libzipkin_opentracing_plugin.so
# /etc/zipkin/zipkin-config.json;

# Activer le traçage pour toutes les requêtes
opentracing on;

# Définir des balises supplémentaires qui capturent la valeur des variables NGINX Plus
opentracing_tag bytes_sent $bytes_sent;
opentracing_tag http_user_agent $http_user_agent;
opentracing_tag request_time $request_time;
opentracing_tag upstream_addr $upstream_addr;
opentracing_tag upstream_bytes_received $upstream_bytes_received;
opentracing_tag statut_cache_amont $upstream_cache_status;
opentracing_tag heure_connexion_amont $upstream_connect_time;
opentracing_tag heure_en-tête_amont $upstream_header_time;
opentracing_tag heure_file_amont $upstream_queue_time;
opentracing_tag heure_réponse_amont $upstream_response_time;

#décommenter pour le débogage
# log_format opentracing '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for" '
# '"$host" sn="$server_name" '
# 'rt=$request_time '
# 'ua="$upstream_addr" us="$upstream_status" '
# 'ut="$upstream_response_time" ul="$upstream_response_length" '
# 'cs=$upstream_cache_status';
#access_log /var/log/nginx/opentracing.log opentracing;

serveur {
écouter 9001;

location / {
# Le nom de l'opération utilisé pour OpenTracing Spans est par défaut le nom du
# bloc 'location', mais supprimez le commentaire de cette directive pour la personnaliser.
#opentracing_operation_name $uri;

# Propager le contexte Span actif en amont, afin que la trace puisse être 
# continuée par le backend.
opentracing_propagate_context;

# Assurez-vous que votre application Ruby écoute sur le port 4567
proxy_pass http://127.0.0.1:4567;
}
}

  4. Valider et recharger la configuration NGINX Plus :

    $ nginx -t $ nginx -s recharger

Configuration de l'exemple d'application Ruby

Avec le traceur et la configuration NGINX Plus en place, nous créons un exemple d'application Ruby qui montre à quoi ressemblent les données OpenTracing. L'application nous permet de mesurer dans quelle mesure la mise en cache NGINX Plus améliore le temps de réponse. Lorsque l'application reçoit une requête telle que la requête HTTP GET suivante pour / , elle attend un laps de temps aléatoire (entre 2 et 5 secondes) avant de répondre. 

$ curl http:// Adresse IP NGINX Plus : 9001/

  1. Installez et configurez Ruby et Sinatra (une bibliothèque d’applications Web logicielles open source et un langage spécifique au domaine écrit en Ruby comme alternative aux autres frameworks d’applications Web Ruby).

  2. Créez un fichier appelé app.rb avec le contenu suivant :

    #!/usr/bin/ruby

require 'sinatra'

get '/*' do
out = "<h1>Application simple Ruby</h1>" + "\n"

#Dormir un temps aléatoire entre 2 s et 5 s
sleeping_time = rand(4)+2
sleep(sleeping_time)
puts "slept for: #{sleeping_time}s."
out += '<p>some output text</p>' + "\n"

return out
end

  3. Rendez app.rb exécutable et exécutez-le :

    $ chmod +x app.rb $ ./app.rb

Suivi des temps de réponse sans mise en cache

Nous utilisons Jaeger et Zipkin pour montrer combien de temps il faut à NGINX Plus pour répondre à une demande lorsque la mise en cache n'est pas activée. Pour chaque traceur, nous envoyons cinq requêtes.

Sortie de Jaeger sans mise en cache

Voici les cinq demandes affichées dans l'interface utilisateur de Jaeger (la plus récente en premier) :

Voici les mêmes informations sur la console de l’application Ruby :

- -> /dormi pendant : 3s. 
127.0.0.1 - - [07/06/2019 : 10:50:46 +0000] "GET / HTTP/1.1" 200 49 3.0028
127.0.0.1 - - [07/06/2019 : [10:50:43 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 2s. 
127.0.0.1 - - [07/06/2019 : 10:50:56 +0000] "GET / HTTP/1.1" 200 49 2.0018 
127.0.0.1 - - [07/06/2019 : [10:50:54 UTC] "GET / HTTP/1.0"1 200 49
- -> /
a dormi pendant : 3s. 
127.0.0.1 - - [07/06/2019 : 10:53:16 +0000] "GET / HTTP/1.1" 200 49 3.0029 
127.0.0.1 - - [07/06/2019 : [10:53:13 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 4s.
127.0.0.1 - - [07/06/2019 : 10:54:03 +0000] "GET / HTTP/1.1" 200 49 4.0030 
127.0.0.1 - - [07/06/2019 : [10:53:59 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 3s.
127.0.0.1 - - [07/06/2019 : 10:54:11 +0000] "GET / HTTP/1.1" 200 49 3.0012
127.0.0.1 - - [07/06/2019 : [10:54:08 UTC] "GET / HTTP/1.0" 200 49

Dans l'interface utilisateur Jaeger, nous cliquons sur la première demande (la plus récente) pour afficher les détails la concernant, y compris les valeurs des variables NGINX Plus que nous avons ajoutées en tant que balises :

Sortie de Zipkin sans mise en cache

Voici cinq autres requêtes dans l'interface utilisateur Zipkin :

Les mêmes informations sur la console de l'application Ruby :

- -> /dormi pendant : 2s.
127.0.0.1 - - [07/06/2019 : 10:31:18 +0000] "GET / HTTP/1.1" 200 49 2.0021 
127.0.0.1 - - [07/06/2019 : [10:31:16 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 3s.
127.0.0.1 - - [07/06/2019 : 10:31:50 +0000] "GET / HTTP/1.1" 200 49 3.0029 
127.0.0.1 - - [07/06/2019 : [10:31:47 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 3s.
127.0.0.1 - - [07/06/2019 : 10:32:08 +0000] "GET / HTTP/1.1" 200 49 3.0026 
127.0.0.1 - - [07/06/2019 : [10:32:05 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 3s.
127.0.0.1 - - [07/06/2019 : 10:32:32 +0000] "GET / HTTP/1.1" 200 49 3.0015 
127.0.0.1 - - [07/06/2019 : [10:32:29 UTC] "GET / HTTP/1.0" 200 49
- -> /
a dormi pendant : 5s.
127.0.0.1 - - [07/06/2019 : 10:32:52 +0000] "GET / HTTP/1.1" 200 49 5.0030 
127.0.0.1 - - [07/06/2019 : [10:32:47 UTC] "GET / HTTP/1.0" 200 49

Dans l'interface utilisateur Zipkin, nous cliquons sur la première demande pour afficher les détails la concernant, y compris les valeurs des variables NGINX Plus que nous avons ajoutées en tant que balises :

Suivi des temps de réponse avec la mise en cache

Configuration de la mise en cache de NGINX Plus

Nous activons la mise en cache en ajoutant des directives dans le fichier opentracing.conf que nous avons créé dans Configuration de NGINX Plus .

  1. Dans le contexte http , ajoutez cette directive proxy_cache_path :

    chemin_cache_proxy /data/nginx/cache keys_zone=one:10m;

  2. Dans le bloc serveur , ajoutez les directives proxy_cache et proxy_cache_valid suivantes :

    proxy_cache un ;
proxy_cache_valid tout 1m ;

  3. Valider et recharger la configuration :

    $ nginx -t $ nginx -s recharger

Sortie de Jaeger avec mise en cache

Voici l’interface utilisateur de Jaeger après deux requêtes.

La première réponse (étiquetée 13f69db ) a pris 4 secondes. NGINX Plus a mis en cache la réponse et lorsque la demande a été répétée environ 15 secondes plus tard, la réponse a pris moins de 2 millisecondes (ms) car elle provenait du cache NGINX Plus.

Un examen détaillé des deux demandes explique la différence de temps de réponse. Pour la première requête, upstream_cache_status est MISS , ce qui signifie que les données demandées n'étaient pas dans le cache. L'application Ruby a ajouté un délai de 4 secondes.

Pour la deuxième requête, upstream_cache_status est HIT . Étant donné que les données proviennent du cache, l’application Ruby ne peut pas ajouter de délai et le temps de réponse est inférieur à 2 ms. Les valeurs upstream_* vides indiquent également que le serveur en amont n'a pas été impliqué dans cette réponse.

Sortie de Zipkin avec mise en cache

L'affichage dans l'interface utilisateur Zipkin pour deux requêtes avec mise en cache activée donne une image similaire :

Et encore une fois, regarder les deux demandes en détail explique la différence de temps de réponse. La réponse n'est pas mise en cache pour la première requête ( upstream_cache_status est MISS ) et l'application Ruby (par coïncidence) ajoute le même délai de 4 secondes que dans l'exemple Jaeger.

La réponse a été mise en cache avant que nous fassions la deuxième requête, donc upstream_cache_status est HIT .

Conclusion

Le module NGINX OpenTracing permet de tracer les requêtes et réponses NGINX Plus et donne accès aux variables NGINX Plus à l'aide de balises OpenTracing. Différents traceurs peuvent également être utilisés avec ce module.

Pour plus de détails sur le module NGINX OpenTracing, visitez le référentiel du module NGINX OpenTracing sur GitHub.

Pour essayer OpenTracing avec NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .

Lire plus d'articles de blog sur F5 NGINX ›

« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."