VT2018 Zipkin - Revision history

Thomas.Ozenda: /* Fonctionnement */

2018-12-17T09:59:53Z

Fonctionnement

← Older revision		Revision as of 09:59, 17 December 2018
Line 53:		Line 53:

	Une fois que l'on a accédé à ce front (qui est sur le port 8081), des requetes vont être envoyés aux backend. On va ainsi pouvoir observer ces requêtes sur le ZipkinUI, en http://localhost:9411/		Une fois que l'on a accédé à ce front (qui est sur le port 8081), des requetes vont être envoyés aux backend. On va ainsi pouvoir observer ces requêtes sur le ZipkinUI, en http://localhost:9411/

			[[File:Zipkin-trace.png]]

	Ce système ne contient que 2 microservices, mais il permet d'imaginer ce que cela pourrait donner sur une architecture plus développée.		Ce système ne contient que 2 microservices, mais il permet d'imaginer ce que cela pourrait donner sur une architecture plus développée.

Thomas.Ozenda: /* Introduction */

2018-12-17T09:58:20Z

Introduction

← Older revision		Revision as of 09:58, 17 December 2018
Line 17:		Line 17:
	Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices. Ceci peut être trés utile dans le sens où nous allons pouvoir voir où les requetes se perdent, dans quel microservices.		Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices. Ceci peut être trés utile dans le sens où nous allons pouvoir voir où les requetes se perdent, dans quel microservices.

	Zipkin-fonctionnement.png		[[File:Zipkin-fonctionnement.png]]

	==Fonctionnement==		==Fonctionnement==

Thomas.Ozenda: /* Introduction */

2018-12-17T09:58:12Z

Introduction

← Older revision		Revision as of 09:58, 17 December 2018
Line 16:		Line 16:

	Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices. Ceci peut être trés utile dans le sens où nous allons pouvoir voir où les requetes se perdent, dans quel microservices.		Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices. Ceci peut être trés utile dans le sens où nous allons pouvoir voir où les requetes se perdent, dans quel microservices.

			Zipkin-fonctionnement.png

	==Fonctionnement==		==Fonctionnement==

Thomas.Ozenda: /* Synthèse */

2018-12-17T09:57:12Z

Synthèse

← Older revision		Revision as of 09:57, 17 December 2018
Line 13:		Line 13:
	=Synthèse=		=Synthèse=

			==Introduction==
⚫	Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices.

		⚫	Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices. Ceci peut être trés utile dans le sens où nous allons pouvoir voir où les requetes se perdent, dans quel microservices.

			==Fonctionnement==

			La première étape est de récupérer, puis lancer le serveur zipkin, qui va servir à collecter les mesures.
	==Références==

			<source lang="bash" line start="1">
			curl -sSL https://zipkin.io/quickstart.sh \| bash -s
			java -jar zipkin.jar
			</source>

			On utilise ici, la version "java" du serveur.

			Le serveur se lance par défaut sur le port 9411.

			L'idée est ensuite de lancer les microservices. En ce qui concerne JHipster, on peut lancer le système grâce à Maven et au profil "Zipkin" comme suit :

			<source lang="bash" line start="1">
			mvn -Pzipkin
			</source>

			En ce qui me concerne, j'ai choisi d'utiliser une démo préparée par Zipkin, trouvable à ce lien : https://github.com/openzipkin/brave-webmvc-example

			Elle se lance facilement avec 2 commandes :

			<source lang="bash" line start="1">
			mvn jetty:run -Pfrontend
			</source>

			et

			<source lang="bash" line start="1">
			mvn jetty:run -Pbackend
			</source>

			Une fois que l'on a accédé à ce front (qui est sur le port 8081), des requetes vont être envoyés aux backend. On va ainsi pouvoir observer ces requêtes sur le ZipkinUI, en http://localhost:9411/

			Ce système ne contient que 2 microservices, mais il permet d'imaginer ce que cela pourrait donner sur une architecture plus développée.

Thomas.Ozenda: /* Synthèse */

2018-12-17T09:43:44Z

Synthèse

← Older revision		Revision as of 09:43, 17 December 2018
Line 12:		Line 12:

	=Synthèse=		=Synthèse=

			Les problématiques rencontrées dans les architectures microservices nécessitent de pouvoir mesurer les latences au sein de celles ci. Zipkin, basé sur Dapper (issu d'un article académique de Google) répond à cette problématique en fournissant un serveur qui va servir à collecter les paquets émis par les microservice à chaque entrée et sortie de paquet. Ces paquets vont permettre plusieurs choses à Zipkin : pouvoir tracer une timeline pour chaque requete, et aussi de pouvoir tracer un "plan" des microservices.

Thomas.Ozenda: /* Abstract */

2018-12-11T14:21:41Z

Abstract

← Older revision		Revision as of 14:21, 11 December 2018
Line 9:		Line 9:
	=Abstract=		=Abstract=

			In micro-service architectures, obtaining metrics on latency, possible packet loss or other things is essential. However, a problem quickly arises: How to easily use log data to learn from it. It is the Zipkin principle, a "distributed tracing system", that supports this data extraction work to provide concrete metrics.


	=Synthèse=		=Synthèse=

Thomas.Ozenda: /* Résumé */

2018-12-10T16:28:39Z

Résumé

← Older revision		Revision as of 16:28, 10 December 2018
Line 5:		Line 5:
	=Résumé=		=Résumé=

			Dans les architectures en microservices, obtenir des métriques sur la latence, la perte éventuelle de paquets ou encore d'autres choses, est primordial. Toutefois, une problématique se pose rapidement : Comment pouvoir exploiter facilement les données de logs pour en tirer des leçons. C'est le principe de Zipkin, un "distributed tracing system", qui prends en charge ce travail d'extraction de données pour fournir des métriques concrètes.


	=Abstract=		=Abstract=

Thomas.Ozenda: Created page with "=Auteur= Nom : OZENDA Thomas Sujet : Dapper & Zipkin =Résumé= =Abstract= =Synthèse= ==Références=="

2018-12-10T16:18:12Z

Created page with "=Auteur= *Nom : OZENDA Thomas *Sujet : Dapper & Zipkin =Résumé= =Abstract= =Synthèse= ==Références=="

New page

=Auteur=
*Nom : OZENDA Thomas
*Sujet : Dapper & Zipkin

=Résumé=

=Abstract=

=Synthèse=

==Références==

VT2018 Zipkin - Revision history

Thomas.Ozenda: /* Fonctionnement */

Thomas.Ozenda: /* Introduction */

Thomas.Ozenda: /* Introduction */

Thomas.Ozenda: /* Synthèse */

Thomas.Ozenda: /* Synthèse */

Thomas.Ozenda: /* Abstract */

Thomas.Ozenda: /* Résumé */

Thomas.Ozenda: Created page with "=Auteur= *Nom : OZENDA Thomas *Sujet : Dapper & Zipkin =Résumé= =Abstract= =Synthèse= ==Références=="

Thomas.Ozenda: Created page with "=Auteur= Nom : OZENDA Thomas Sujet : Dapper & Zipkin =Résumé= =Abstract= =Synthèse= ==Références=="