air - User contributions [en]

Projets 2019-2020

2020-01-28T14:20:06Z

Damien.Wykland: /* Affectations S10 */

<<[[Projets 2018-2019]] | [[Projets]] | [[Projets 2020-2021]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 20 Janvier 2020 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2019_2020. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets===
* 1. [[ThingSat]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)
* 2. [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et l'[[Institut polaire Paul Emile Victor]]
* Agriculture connectée en partenariat avec les projets collectifs IESE/MAT
** 3. à [[ASAC/AP|Polytech]] : Nicolas Palix
** 4. à [[ASAC/SJC|St Cassien]] : Nicolas Palix
* 5. [[Dataviz de la qualité de l'air et de la pollution sonore]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)
* 6. [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&M) (Tech Ionic à confirmer)
* 7. Intégration d'Intel [[Movidius]] ou [[MAix BiT]] à [[RobAIR]], Olivier Richard
* 8. [[Application mobile de secours du PGHM]] : Didier Donsez, Olivier Fabre (PGHM)
* 9. [[Application mobile pour la capture de marmottes]] : Didier Donsez, Franck Delbard
* 10. [[Supports pédagogiques open-source pour l'initiation à l’Internet des Objets pour l’enseignement de SNT (Sciences Numériques et Technologie) au lycée]] : Olivier Richard et Didier Donsez
* 11. [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]] : Didier DONSEZ, Franck ROUDET (Orange Labs Meylan)
* DatViz pour l'IoT
** 12. [[Amélioration de greffons Grafana]] : Didier Donsez
** 13. [[Tableau de bord et kit de mesure du confort dans les bâtiments de l'UGA]] : Didier Donsez, Fabien Hornebeck (DG DAPAL), Laurence Deligny (DG DAPAL)
** 14. [[Tableau de bord des capteurs LoRaWAN de la Ville de La Mure]] : Didier Donsez, Virginie Gondrand (Ville de La Mure)
** 15. [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]] : Didier Donsez, Jean-François Knoepfli (MoonshotLab), Joris Brémond (MoonshotLab)
* 16. [[Contributions open source au projet EdCampus]] : Didier Donsez, Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* 17. [[VisuGPX : Application mobile pour ski rando]], Didier Donsez, Ye.Ti (M)
* 18. [[Projet d'Auscultation Partagée]] avec IESE4 et TIS5, Olivier Richard, Didier Donsez, Julie Fontecave-Jallon
* 19. [[FPGA et Deep Learnning]] : Olivier Richard
* 20. [[Source Héritage et NIX]] : Olivier Richard
* 21. [[Proxy Cache HTTPS]] : Olivier Richard
* 22. [[Reverse Proxy pour gestionnaire de taches]] : Olivier Richard
* 23. [[Portail pour gestionnaire de taches]] : Olivier Richard
* 24. [[Paquets NIX pour Polytech]] : Olivier Richard
Non prioritaire
* [[Application mobile de calcul de son empreinte carbone]] : Didier Donsez, Anne Delaballe (Disrupt Campus), XX (Café Collapse)
* [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&M)
* [[Benchmark de MCU pour l'IoT]] : Didier Donsez
* [[Connecteur InfluxDB pour Cube.js]] : Didier Donsez
* [[SimCity]] avec [[ThreeJS]]
* [[WhereIsMyCar]] : application mobile pour se souvenir de l'endroit où sa voiture est garée. : Didier Donsez
* [[CannonBall de voitures autonomes 2018]]
* [[Covoiturage Solidaire]], Didier Donsez
* [[Intégration d'OpenAM à la génération de JHipster]] : Didier Donsez
* [[Comptage anonymisé de personnes]] : Didier Donsez et Franck Delbart
* Carte de service étudiant avec [[Eclipse Keyple]] : Didier Donsez
* [[Tableau de bord et kit de mesure du confort dans les bâtiments du CROUS]] : Didier Donsez (SOUS RESERVE)

==== Affectation ====
{|class="wikitable alternance"
|+ Affectation des projets INFO4 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 3
| [[ASAC/AP|Agriculture connectée Polytech]]
| VERNET MAXIME, SAJIDE IDRISS
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/3/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 4
| [[ASAC/ACJC|Agriculture connectée St Cassien]]
| LABBE NICOLAS,RUZAFA REMY
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/4/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]
| CROCIATI MORGAN,GRAUGNARD TOM
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/6/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 7
| [[Intégration d'Intel Movidius ou MAix BiT à RobAIR]]
| PALOMO REMY, BOLEAT BAPTISTE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/7/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[Application mobile de secours du PGHM]]
| CHATON ALEXANDRA,FRION THOMAS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/8/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 9
| [[ Application mobile pour la capture de marmottes ]]
| EL JRAIDI RIM, NELSON WILLIAM
| Didier DONSEZ, Franck DELBARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/9/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| CHAIX MANON,NGUENA ZEMAO GLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]]
| ARTAUD Adrien,FOUGERE SEBASTIAN
| Didier DONSEZ, Franck ROUDET
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 12
| [[Amélioration de greffons Grafana]]
| MURPHY MICA,VELUT CLAIRE
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/12/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| HO NHAT QUANG,MANISSADJIAN GABRIEL
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BILOUNGA-BI-NDONG ALECK,LOMBARD MYRIAM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]]
| GUIVARCH ALAN, PAREILLEUX KILLIAN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 16
| [[Contribution au logiciel EDCampus]]
| BEAUGRAND ELISA,DE GAUDENZI LOUIS
| Didier Donsez, Anthony Geourjon
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/16/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[VisuGPX : Application mobile pour ski rando]]
| ZERAMDINI OTBA, EL MUFTI ALI, DELBOS ROBIN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[FPGA et Deep Learnning]]
| COURTHIAL SAMUEL, LUIS FILIPE VELASCO DA SILVA
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| [[Source Héritage et NIX]]
| PASDELOUP ROMAIN,SALMON ALEXANDRE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[Proxy Cache HTTPS]]
| AUDIN RAPHAEL,RIVAL GAETAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[Reverse Proxy pour gestionnaire de taches]]
| GUYOT SACHA,EL AJI HOUDA,ASSI DIMA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/22/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 23
| [[Portail_pour_gestionnaire_de_taches|Portail pour gestionnaire de tâches]]
| ROLLIN ALEXIS,SAGET ANTOINE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/23/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2019.

===Projet Semestre S10===

Enseignants responsables : [[user:Donsez | Didier Donsez]]

Calendrier: 28/01 (13H30) à Fin Mars 2020.

Séances de Management de projets innovants: 29/01, 06/02, 13/02, 17/02, 18/03.

Réunion de présentation : 28/01 (13H30) . Faire couler le café.

Démarrage : 28/01 (13H30) . Faire couler le café.

Soutenance à mi-parcours : Début Mars, 9H00-11H30 (15 minutes par équipe).

Soutenance (puis Pot de la fin) : A définir : Semaine 16-20 Mars (probablement Jeudi ou Vendredi).

14/02: [https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2020 Eclipse IoT Day Grenoble]

====Propositions de projets S10====
* [[Contributions à Software Heritage]] : : Didier Donsez, Roberto Di Cosmo
* [[Contribution au projet open-souce ChirpStack]] (aka LoRaServer) : Didier Donsez
* [[Contributions open-source au projet JHipster]] : Didier Donsez
* [[Ecrire en gestes]] : Olivier Richard
* [[Kine 2.0]] (suite de [[Rééducation Kiné connecté]] 2019): Sylvain Toru
* [[Contributions open source au projet EdCampus]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Contributions open source au projet SmartRecruiting]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Secours Montagne avec LoRa]] : Bernard Tourancheau ??? avec le PGHM Isère
* [[Monnaies locales et blockchains]] avec Hyperledger, Didier Donsez, XXX (Cairn Grenoble). A CONFIRMER.
* [[IoTChain]] : Didier Donsez
* [[Projet STAPS]] : Didier Donsez

Reporté
* [[Analyse du pédalage cycliste sur home trainer via vidéo]] (Anthony Geourjon) en relation avec STAPS et TIS
* Projet IA/Edge: Databox : Olivier Richard

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-

!scope="row"| 1
| [[Projet STAPS]]
| ANCRENAZ Ariane, SAUTON Tanguy, SIBUE Quentin, VINCENT Mathieu (CP)
| Didier Donsez
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 2
| [[Contributions à Software Heritage]]
| Nathan Dalaine, Joachim Fontfreyde (CP), Léni Gauffier, Yann Gautier
| Didier Donsez, Roberto Di Cosmo
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Sauvetage en montagne]]
| WYKLAND Damien(SM), BADAT Leya, CUAU Victor, MASSON Jeremy, ZARCOS Paul
| Bernard Tourancheau
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 4
| [[Projet EDCampus]]
| RIVOIRE Antoine, VINCENT Maxence, BONASPETTI Giulia, DECAMPS Marceau
| Anthony GEOURJON - Gérard POLLIER
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 5
| [[Projet SmartRecruting]]
| SOUCHON Loic, THOMAS Antoine, VANDAL Jade, TRESTOUR Gregory, ZHENG jian
| Anthony GEOURJON - Gérard POLLIER
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 6
| [[Projet Kine 2.0]]
| BARDOU Eva, DEVOS Xavier, HOUBRON Adrian, JAN Léo, PELISSON Antoine
| Sylvain Toru
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 7
| [[Blockchain (Cairn - IOT)]]
| REYGROBELLET Lucas, BRES Maxence, BETEND Baptiste, DUMENIL Antoine
| 💪🏼💣 Didier DONSEZ 🔥❤️
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 8
| [[Contribution Jhipster]]
| SALA Ergi, ARNOUX Thibaut, SOLVERY Tom, LORDEY Maxime, CHASSEGUET Corentin, LATTARD Alexis(CP)
| Didier DONSEZ
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 9
| [[Contribution ChirpStack]]
| RAKOTOARIMALALA Mandresy
| Didier DONSEZ
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]

|}

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2019/TP|PM2M]]==

Projets 2019-2020

2020-01-28T13:59:05Z

Damien.Wykland: /* Affectations S10 */

<<[[Projets 2018-2019]] | [[Projets]] | [[Projets 2020-2021]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 20 Janvier 2020 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2019_2020. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets===
* 1. [[ThingSat]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)
* 2. [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et l'[[Institut polaire Paul Emile Victor]]
* Agriculture connectée en partenariat avec les projets collectifs IESE/MAT
** 3. à [[ASAC/AP|Polytech]] : Nicolas Palix
** 4. à [[ASAC/SJC|St Cassien]] : Nicolas Palix
* 5. [[Dataviz de la qualité de l'air et de la pollution sonore]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)
* 6. [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&M) (Tech Ionic à confirmer)
* 7. Intégration d'Intel [[Movidius]] ou [[MAix BiT]] à [[RobAIR]], Olivier Richard
* 8. [[Application mobile de secours du PGHM]] : Didier Donsez, Olivier Fabre (PGHM)
* 9. [[Application mobile pour la capture de marmottes]] : Didier Donsez, Franck Delbard
* 10. [[Supports pédagogiques open-source pour l'initiation à l’Internet des Objets pour l’enseignement de SNT (Sciences Numériques et Technologie) au lycée]] : Olivier Richard et Didier Donsez
* 11. [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]] : Didier DONSEZ, Franck ROUDET (Orange Labs Meylan)
* DatViz pour l'IoT
** 12. [[Amélioration de greffons Grafana]] : Didier Donsez
** 13. [[Tableau de bord et kit de mesure du confort dans les bâtiments de l'UGA]] : Didier Donsez, Fabien Hornebeck (DG DAPAL), Laurence Deligny (DG DAPAL)
** 14. [[Tableau de bord des capteurs LoRaWAN de la Ville de La Mure]] : Didier Donsez, Virginie Gondrand (Ville de La Mure)
** 15. [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]] : Didier Donsez, Jean-François Knoepfli (MoonshotLab), Joris Brémond (MoonshotLab)
* 16. [[Contributions open source au projet EdCampus]] : Didier Donsez, Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* 17. [[VisuGPX : Application mobile pour ski rando]], Didier Donsez, Ye.Ti (M)
* 18. [[Projet d'Auscultation Partagée]] avec IESE4 et TIS5, Olivier Richard, Didier Donsez, Julie Fontecave-Jallon
* 19. [[FPGA et Deep Learnning]] : Olivier Richard
* 20. [[Source Héritage et NIX]] : Olivier Richard
* 21. [[Proxy Cache HTTPS]] : Olivier Richard
* 22. [[Reverse Proxy pour gestionnaire de taches]] : Olivier Richard
* 23. [[Portail pour gestionnaire de taches]] : Olivier Richard
* 24. [[Paquets NIX pour Polytech]] : Olivier Richard
Non prioritaire
* [[Application mobile de calcul de son empreinte carbone]] : Didier Donsez, Anne Delaballe (Disrupt Campus), XX (Café Collapse)
* [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&M)
* [[Benchmark de MCU pour l'IoT]] : Didier Donsez
* [[Connecteur InfluxDB pour Cube.js]] : Didier Donsez
* [[SimCity]] avec [[ThreeJS]]
* [[WhereIsMyCar]] : application mobile pour se souvenir de l'endroit où sa voiture est garée. : Didier Donsez
* [[CannonBall de voitures autonomes 2018]]
* [[Covoiturage Solidaire]], Didier Donsez
* [[Intégration d'OpenAM à la génération de JHipster]] : Didier Donsez
* [[Comptage anonymisé de personnes]] : Didier Donsez et Franck Delbart
* Carte de service étudiant avec [[Eclipse Keyple]] : Didier Donsez
* [[Tableau de bord et kit de mesure du confort dans les bâtiments du CROUS]] : Didier Donsez (SOUS RESERVE)

==== Affectation ====
{|class="wikitable alternance"
|+ Affectation des projets INFO4 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 3
| [[ASAC/AP|Agriculture connectée Polytech]]
| VERNET MAXIME, SAJIDE IDRISS
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/3/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 4
| [[ASAC/ACJC|Agriculture connectée St Cassien]]
| LABBE NICOLAS,RUZAFA REMY
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/4/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]
| CROCIATI MORGAN,GRAUGNARD TOM
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/6/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 7
| [[Intégration d'Intel Movidius ou MAix BiT à RobAIR]]
| PALOMO REMY, BOLEAT BAPTISTE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/7/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[Application mobile de secours du PGHM]]
| CHATON ALEXANDRA,FRION THOMAS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/8/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 9
| [[ Application mobile pour la capture de marmottes ]]
| EL JRAIDI RIM, NELSON WILLIAM
| Didier DONSEZ, Franck DELBARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/9/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| CHAIX MANON,NGUENA ZEMAO GLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]]
| ARTAUD Adrien,FOUGERE SEBASTIAN
| Didier DONSEZ, Franck ROUDET
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 12
| [[Amélioration de greffons Grafana]]
| MURPHY MICA,VELUT CLAIRE
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/12/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| HO NHAT QUANG,MANISSADJIAN GABRIEL
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BILOUNGA-BI-NDONG ALECK,LOMBARD MYRIAM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]]
| GUIVARCH ALAN, PAREILLEUX KILLIAN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 16
| [[Contribution au logiciel EDCampus]]
| BEAUGRAND ELISA,DE GAUDENZI LOUIS
| Didier Donsez, Anthony Geourjon
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/16/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[VisuGPX : Application mobile pour ski rando]]
| ZERAMDINI OTBA, EL MUFTI ALI, DELBOS ROBIN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[FPGA et Deep Learnning]]
| COURTHIAL SAMUEL, LUIS FILIPE VELASCO DA SILVA
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| [[Source Héritage et NIX]]
| PASDELOUP ROMAIN,SALMON ALEXANDRE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[Proxy Cache HTTPS]]
| AUDIN RAPHAEL,RIVAL GAETAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[Reverse Proxy pour gestionnaire de taches]]
| GUYOT SACHA,EL AJI HOUDA,ASSI DIMA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/22/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 23
| [[Portail_pour_gestionnaire_de_taches|Portail pour gestionnaire de tâches]]
| ROLLIN ALEXIS,SAGET ANTOINE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/23/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2019.

===Projet Semestre S10===

Enseignants responsables : [[user:Donsez | Didier Donsez]]

Calendrier: 28/01 (13H30) à Fin Mars 2020.

Séances de Management de projets innovants: 29/01, 06/02, 13/02, 17/02, 18/03.

Réunion de présentation : 28/01 (13H30) . Faire couler le café.

Démarrage : 28/01 (13H30) . Faire couler le café.

Soutenance à mi-parcours : Début Mars, 9H00-11H30 (15 minutes par équipe).

Soutenance (puis Pot de la fin) : A définir : Semaine 16-20 Mars (probablement Jeudi ou Vendredi).

14/02: [https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2020 Eclipse IoT Day Grenoble]

====Propositions de projets S10====
* [[Contributions à Software Heritage]] : : Didier Donsez, Roberto Di Cosmo
* [[Contribution au projet open-souce ChirpStack]] (aka LoRaServer) : Didier Donsez
* [[Contributions open-source au projet JHipster]] : Didier Donsez
* [[Ecrire en gestes]] : Olivier Richard
* [[Kine 2.0]] (suite de [[Rééducation Kiné connecté]] 2019): Sylvain Toru
* [[Contributions open source au projet EdCampus]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Contributions open source au projet SmartRecruiting]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Secours Montagne avec LoRa]] : Bernard Tourancheau ??? avec le PGHM Isère
* [[Monnaies locales et blockchains]] avec Hyperledger, Didier Donsez, XXX (Cairn Grenoble). A CONFIRMER.
* [[IoTChain]] : Didier Donsez
* [[Projet STAPS]] : Didier Donsez

Reporté
* [[Analyse du pédalage cycliste sur home trainer via vidéo]] (Anthony Geourjon) en relation avec STAPS et TIS
* Projet IA/Edge: Databox : Olivier Richard

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-

!scope="row"| 1
| [[Projet STAPS]]
| ANCRENAZ Ariane, SAUTON Tanguy, SIBUE Quentin, VINCENT Mathieu (CP)
| Didier Donsez
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 2
| [[Contributions à Software Heritage]]
| Nathan Dalaine, Joachim Fontfreyde, Léni Gauffier, Yann Gautier
| Didier Donsez, Roberto Di Cosmo
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Sauvetage en montagne]]
| WYKLAND Damien, BADAT Leya, CUAU Victor, MASSON Jeremy, ZARCOS Paul
| Bernard Tourancheau
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 4
| [[Projet EDCampus]]
| RIVOIRE Antoine, VINCENT Maxence, BONASPETTI Giulia, DESCAMPS Marceau, MASTOURA Iheb, Kadir Alacalı Uraz
| Anthony GEOURJEON - Gérard POLLIER
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 5
| [[Projet SmartRecruting]]
| SOUCHON Loic, THOMAS Antoine, VANDAL Jade, TRESTOUR Gregory, ZHENG jian
| Anthony GEOURJEON
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]

|}

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2019/TP|PM2M]]==

Projets 2019-2020

2020-01-28T13:37:17Z

Damien.Wykland: /* Affectations S10 */

<<[[Projets 2018-2019]] | [[Projets]] | [[Projets 2020-2021]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 20 Janvier 2020 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2019_2020. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets===
* 1. [[ThingSat]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)
* 2. [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et l'[[Institut polaire Paul Emile Victor]]
* Agriculture connectée en partenariat avec les projets collectifs IESE/MAT
** 3. à [[ASAC/AP|Polytech]] : Nicolas Palix
** 4. à [[ASAC/SJC|St Cassien]] : Nicolas Palix
* 5. [[Dataviz de la qualité de l'air et de la pollution sonore]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)
* 6. [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&M) (Tech Ionic à confirmer)
* 7. Intégration d'Intel [[Movidius]] ou [[MAix BiT]] à [[RobAIR]], Olivier Richard
* 8. [[Application mobile de secours du PGHM]] : Didier Donsez, Olivier Fabre (PGHM)
* 9. [[Application mobile pour la capture de marmottes]] : Didier Donsez, Franck Delbard
* 10. [[Supports pédagogiques open-source pour l'initiation à l’Internet des Objets pour l’enseignement de SNT (Sciences Numériques et Technologie) au lycée]] : Olivier Richard et Didier Donsez
* 11. [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]] : Didier DONSEZ, Franck ROUDET (Orange Labs Meylan)
* DatViz pour l'IoT
** 12. [[Amélioration de greffons Grafana]] : Didier Donsez
** 13. [[Tableau de bord et kit de mesure du confort dans les bâtiments de l'UGA]] : Didier Donsez, Fabien Hornebeck (DG DAPAL), Laurence Deligny (DG DAPAL)
** 14. [[Tableau de bord des capteurs LoRaWAN de la Ville de La Mure]] : Didier Donsez, Virginie Gondrand (Ville de La Mure)
** 15. [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]] : Didier Donsez, Jean-François Knoepfli (MoonshotLab), Joris Brémond (MoonshotLab)
* 16. [[Contributions open source au projet EdCampus]] : Didier Donsez, Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* 17. [[VisuGPX : Application mobile pour ski rando]], Didier Donsez, Ye.Ti (M)
* 18. [[Projet d'Auscultation Partagée]] avec IESE4 et TIS5, Olivier Richard, Didier Donsez, Julie Fontecave-Jallon
* 19. [[FPGA et Deep Learnning]] : Olivier Richard
* 20. [[Source Héritage et NIX]] : Olivier Richard
* 21. [[Proxy Cache HTTPS]] : Olivier Richard
* 22. [[Reverse Proxy pour gestionnaire de taches]] : Olivier Richard
* 23. [[Portail pour gestionnaire de taches]] : Olivier Richard
* 24. [[Paquets NIX pour Polytech]] : Olivier Richard
Non prioritaire
* [[Application mobile de calcul de son empreinte carbone]] : Didier Donsez, Anne Delaballe (Disrupt Campus), XX (Café Collapse)
* [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&M)
* [[Benchmark de MCU pour l'IoT]] : Didier Donsez
* [[Connecteur InfluxDB pour Cube.js]] : Didier Donsez
* [[SimCity]] avec [[ThreeJS]]
* [[WhereIsMyCar]] : application mobile pour se souvenir de l'endroit où sa voiture est garée. : Didier Donsez
* [[CannonBall de voitures autonomes 2018]]
* [[Covoiturage Solidaire]], Didier Donsez
* [[Intégration d'OpenAM à la génération de JHipster]] : Didier Donsez
* [[Comptage anonymisé de personnes]] : Didier Donsez et Franck Delbart
* Carte de service étudiant avec [[Eclipse Keyple]] : Didier Donsez
* [[Tableau de bord et kit de mesure du confort dans les bâtiments du CROUS]] : Didier Donsez (SOUS RESERVE)

==== Affectation ====
{|class="wikitable alternance"
|+ Affectation des projets INFO4 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 3
| [[ASAC/AP|Agriculture connectée Polytech]]
| VERNET MAXIME, SAJIDE IDRISS
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/3/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 4
| [[ASAC/ACJC|Agriculture connectée St Cassien]]
| LABBE NICOLAS,RUZAFA REMY
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/4/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]
| CROCIATI MORGAN,GRAUGNARD TOM
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/6/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 7
| [[Intégration d'Intel Movidius ou MAix BiT à RobAIR]]
| PALOMO REMY, BOLEAT BAPTISTE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/7/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[Application mobile de secours du PGHM]]
| CHATON ALEXANDRA,FRION THOMAS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/8/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 9
| [[ Application mobile pour la capture de marmottes ]]
| EL JRAIDI RIM, NELSON WILLIAM
| Didier DONSEZ, Franck DELBARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/9/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| CHAIX MANON,NGUENA ZEMAO GLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]]
| ARTAUD Adrien,FOUGERE SEBASTIAN
| Didier DONSEZ, Franck ROUDET
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 12
| [[Amélioration de greffons Grafana]]
| MURPHY MICA,VELUT CLAIRE
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/12/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| HO NHAT QUANG,MANISSADJIAN GABRIEL
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BILOUNGA-BI-NDONG ALECK,LOMBARD MYRIAM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]]
| GUIVARCH ALAN, PAREILLEUX KILLIAN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 16
| [[Contribution au logiciel EDCampus]]
| BEAUGRAND ELISA,DE GAUDENZI LOUIS
| Didier Donsez, Anthony Geourjon
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/16/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[VisuGPX : Application mobile pour ski rando]]
| ZERAMDINI OTBA, EL MUFTI ALI, DELBOS ROBIN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[FPGA et Deep Learnning]]
| COURTHIAL SAMUEL, LUIS FILIPE VELASCO DA SILVA
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| [[Source Héritage et NIX]]
| PASDELOUP ROMAIN,SALMON ALEXANDRE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[Proxy Cache HTTPS]]
| AUDIN RAPHAEL,RIVAL GAETAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[Reverse Proxy pour gestionnaire de taches]]
| GUYOT SACHA,EL AJI HOUDA,ASSI DIMA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/22/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 23
| [[Portail_pour_gestionnaire_de_taches|Portail pour gestionnaire de tâches]]
| ROLLIN ALEXIS,SAGET ANTOINE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/23/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2019.

===Projet Semestre S10===

Enseignants responsables : [[user:Donsez | Didier Donsez]]

Calendrier: 28/01 (13H30) à Fin Mars 2020.

Séances de Management de projets innovants: 29/01, 06/02, 13/02, 17/02, 18/03.

Réunion de présentation : 28/01 (13H30) . Faire couler le café.

Démarrage : 28/01 (13H30) . Faire couler le café.

Soutenance à mi-parcours : Début Mars, 9H00-11H30 (15 minutes par équipe).

Soutenance (puis Pot de la fin) : A définir : Semaine 16-20 Mars (probablement Jeudi ou Vendredi).

14/02: [https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2020 Eclipse IoT Day Grenoble]

====Propositions de projets S10====
* [[Contributions à Software Heritage]] : : Didier Donsez, Roberto Di Cosmo
* [[Contribution au projet open-souce ChirpStack]] (aka LoRaServer) : Didier Donsez
* [[Contributions open-source au projet JHipster]] : Didier Donsez
* [[Ecrire en gestes]] : Olivier Richard
* [[Kine 2.0]] (suite de [[Rééducation Kiné connecté]] 2019): Sylvain Toru
* [[Contributions open source au projet EdCampus]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Contributions open source au projet SmartRecruiting]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Secours Montagne avec LoRa]] : Bernard Tourancheau ??? avec le PGHM Isère
* [[Monnaies locales et blockchains]] avec Hyperledger, Didier Donsez, XXX (Cairn Grenoble). A CONFIRMER.
* [[IoTChain]] : Didier Donsez
* [[Projet STAPS]] : Didier Donsez

Reporté
* [[Analyse du pédalage cycliste sur home trainer via vidéo]] (Anthony Geourjon) en relation avec STAPS et TIS
* Projet IA/Edge: Databox : Olivier Richard

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-

!scope="row"| 1
| [[Projet STAPS]]
| ANCRENAZ Ariane, SAUTON Tanguy, SIBUE Quentin, VINCENT Mathieu (CP)
| Didier Donsez
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 2
| [[Contributions à Software Heritage]]
| Nathan Dalaine, Joachim Fontfreyde, Léni Gauffier, Yann Gautier
| Didier Donsez, Roberto Di Cosmo
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Sauvetage en montagne]]
| WYKLAND Damien, BADAT Leya, CUAU Victor, MASSON Jeremy, ZARCOS Paul
| Bernard Tourancheau
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 4
| [[Projet Ecrire en gestes]]
| CHABRE Manon, COSCIA Daniel, DENIS Guillaume, DEARAUJO Bastien
| Olivier RICHARD
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-

|}

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2019/TP|PM2M]]==

Projets 2019-2020

2020-01-28T13:34:54Z

Damien.Wykland: /* Affectations S10 */

<<[[Projets 2018-2019]] | [[Projets]] | [[Projets 2020-2021]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 20 Janvier 2020 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2019_2020. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets===
* 1. [[ThingSat]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)
* 2. [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et l'[[Institut polaire Paul Emile Victor]]
* Agriculture connectée en partenariat avec les projets collectifs IESE/MAT
** 3. à [[ASAC/AP|Polytech]] : Nicolas Palix
** 4. à [[ASAC/SJC|St Cassien]] : Nicolas Palix
* 5. [[Dataviz de la qualité de l'air et de la pollution sonore]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)
* 6. [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&M) (Tech Ionic à confirmer)
* 7. Intégration d'Intel [[Movidius]] ou [[MAix BiT]] à [[RobAIR]], Olivier Richard
* 8. [[Application mobile de secours du PGHM]] : Didier Donsez, Olivier Fabre (PGHM)
* 9. [[Application mobile pour la capture de marmottes]] : Didier Donsez, Franck Delbard
* 10. [[Supports pédagogiques open-source pour l'initiation à l’Internet des Objets pour l’enseignement de SNT (Sciences Numériques et Technologie) au lycée]] : Olivier Richard et Didier Donsez
* 11. [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]] : Didier DONSEZ, Franck ROUDET (Orange Labs Meylan)
* DatViz pour l'IoT
** 12. [[Amélioration de greffons Grafana]] : Didier Donsez
** 13. [[Tableau de bord et kit de mesure du confort dans les bâtiments de l'UGA]] : Didier Donsez, Fabien Hornebeck (DG DAPAL), Laurence Deligny (DG DAPAL)
** 14. [[Tableau de bord des capteurs LoRaWAN de la Ville de La Mure]] : Didier Donsez, Virginie Gondrand (Ville de La Mure)
** 15. [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]] : Didier Donsez, Jean-François Knoepfli (MoonshotLab), Joris Brémond (MoonshotLab)
* 16. [[Contributions open source au projet EdCampus]] : Didier Donsez, Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* 17. [[VisuGPX : Application mobile pour ski rando]], Didier Donsez, Ye.Ti (M)
* 18. [[Projet d'Auscultation Partagée]] avec IESE4 et TIS5, Olivier Richard, Didier Donsez, Julie Fontecave-Jallon
* 19. [[FPGA et Deep Learnning]] : Olivier Richard
* 20. [[Source Héritage et NIX]] : Olivier Richard
* 21. [[Proxy Cache HTTPS]] : Olivier Richard
* 22. [[Reverse Proxy pour gestionnaire de taches]] : Olivier Richard
* 23. [[Portail pour gestionnaire de taches]] : Olivier Richard
* 24. [[Paquets NIX pour Polytech]] : Olivier Richard
Non prioritaire
* [[Application mobile de calcul de son empreinte carbone]] : Didier Donsez, Anne Delaballe (Disrupt Campus), XX (Café Collapse)
* [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&M)
* [[Benchmark de MCU pour l'IoT]] : Didier Donsez
* [[Connecteur InfluxDB pour Cube.js]] : Didier Donsez
* [[SimCity]] avec [[ThreeJS]]
* [[WhereIsMyCar]] : application mobile pour se souvenir de l'endroit où sa voiture est garée. : Didier Donsez
* [[CannonBall de voitures autonomes 2018]]
* [[Covoiturage Solidaire]], Didier Donsez
* [[Intégration d'OpenAM à la génération de JHipster]] : Didier Donsez
* [[Comptage anonymisé de personnes]] : Didier Donsez et Franck Delbart
* Carte de service étudiant avec [[Eclipse Keyple]] : Didier Donsez
* [[Tableau de bord et kit de mesure du confort dans les bâtiments du CROUS]] : Didier Donsez (SOUS RESERVE)

==== Affectation ====
{|class="wikitable alternance"
|+ Affectation des projets INFO4 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 3
| [[ASAC/AP|Agriculture connectée Polytech]]
| VERNET MAXIME, SAJIDE IDRISS
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/3/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 4
| [[ASAC/ACJC|Agriculture connectée St Cassien]]
| LABBE NICOLAS,RUZAFA REMY
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/4/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]
| CROCIATI MORGAN,GRAUGNARD TOM
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/6/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 7
| [[Intégration d'Intel Movidius ou MAix BiT à RobAIR]]
| PALOMO REMY, BOLEAT BAPTISTE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/7/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[Application mobile de secours du PGHM]]
| CHATON ALEXANDRA,FRION THOMAS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/8/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 9
| [[ Application mobile pour la capture de marmottes ]]
| EL JRAIDI RIM, NELSON WILLIAM
| Didier DONSEZ, Franck DELBARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/9/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| CHAIX MANON,NGUENA ZEMAO GLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]]
| ARTAUD Adrien,FOUGERE SEBASTIAN
| Didier DONSEZ, Franck ROUDET
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 12
| [[Amélioration de greffons Grafana]]
| MURPHY MICA,VELUT CLAIRE
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/12/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| HO NHAT QUANG,MANISSADJIAN GABRIEL
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BILOUNGA-BI-NDONG ALECK,LOMBARD MYRIAM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]]
| GUIVARCH ALAN, PAREILLEUX KILLIAN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 16
| [[Contribution au logiciel EDCampus]]
| BEAUGRAND ELISA,DE GAUDENZI LOUIS
| Didier Donsez, Anthony Geourjon
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/16/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[VisuGPX : Application mobile pour ski rando]]
| ZERAMDINI OTBA, EL MUFTI ALI, DELBOS ROBIN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[FPGA et Deep Learnning]]
| COURTHIAL SAMUEL, LUIS FILIPE VELASCO DA SILVA
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| [[Source Héritage et NIX]]
| PASDELOUP ROMAIN,SALMON ALEXANDRE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[Proxy Cache HTTPS]]
| AUDIN RAPHAEL,RIVAL GAETAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[Reverse Proxy pour gestionnaire de taches]]
| GUYOT SACHA,EL AJI HOUDA,ASSI DIMA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/22/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 23
| [[Portail_pour_gestionnaire_de_taches|Portail pour gestionnaire de tâches]]
| ROLLIN ALEXIS,SAGET ANTOINE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/23/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2019.

===Projet Semestre S10===

Enseignants responsables : [[user:Donsez | Didier Donsez]]

Calendrier: 28/01 (13H30) à Fin Mars 2020.

Séances de Management de projets innovants: 29/01, 06/02, 13/02, 17/02, 18/03.

Réunion de présentation : 28/01 (13H30) . Faire couler le café.

Démarrage : 28/01 (13H30) . Faire couler le café.

Soutenance à mi-parcours : Début Mars, 9H00-11H30 (15 minutes par équipe).

Soutenance (puis Pot de la fin) : A définir : Semaine 16-20 Mars (probablement Jeudi ou Vendredi).

14/02: [https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2020 Eclipse IoT Day Grenoble]

====Propositions de projets S10====
* [[Contributions à Software Heritage]] : : Didier Donsez, Roberto Di Cosmo
* [[Contribution au projet open-souce ChirpStack]] (aka LoRaServer) : Didier Donsez
* [[Contributions open-source au projet JHipster]] : Didier Donsez
* [[Ecrire en gestes]] : Olivier Richard
* [[Kine 2.0]] (suite de [[Rééducation Kiné connecté]] 2019): Sylvain Toru
* [[Contributions open source au projet EdCampus]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Contributions open source au projet SmartRecruiting]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Secours Montagne avec LoRa]] : Bernard Tourancheau ??? avec le PGHM Isère
* [[Monnaies locales et blockchains]] avec Hyperledger, Didier Donsez, XXX (Cairn Grenoble). A CONFIRMER.
* [[IoTChain]] : Didier Donsez
* [[Projet STAPS]] : Didier Donsez

Reporté
* [[Analyse du pédalage cycliste sur home trainer via vidéo]] (Anthony Geourjon) en relation avec STAPS et TIS
* Projet IA/Edge: Databox : Olivier Richard

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-

!scope="row"| 1
| [[Projet STAPS]]
| ANCRENAZ Ariane, SAUTON Tanguy, SIBUE Quentin, VINCENT Mathieu (CP)
| Didier Donsez
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 2
| [[Contributions à Software Heritage]]
| Nathan Dalaine, Joachim Fontfreyde, Léni Gauffier, Yann Gautier
| Didier Donsez, Roberto Di Cosmo
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Sauvetage en montagne]]
| WYKLAND Damien, BADAT Leya, CUAU Victor, MASSON Jeremy, ZARCOS Paul
| Bernard Tourancheau
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Ecrire en gestes]]
| CHABRE Manon, COSCIA Daniel, DENIS Guillaume, DEARAUJO Bastien
| Olivier RICHARD
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-

|}

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2019/TP|PM2M]]==

Projets 2019-2020

2020-01-28T13:33:13Z

Damien.Wykland: /* Affectations S10 */

<<[[Projets 2018-2019]] | [[Projets]] | [[Projets 2020-2021]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard, Didier Donsez

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 20 Janvier 2020 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2019_2020. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions). Une bonnification sera accordée si le rapport et les transparents sont en anglais (la soutenance sera en francais).

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets===
* 1. [[ThingSat]] : LoRa in the Space, Didier Donsez avec le [https://www.csug.fr/ CSUG] (S)
* 2. [[LoRaRescueBalloon]], Didier Donsez avec le [https://www.csug.fr/ CSUG] et l'[[Institut polaire Paul Emile Victor]]
* Agriculture connectée en partenariat avec les projets collectifs IESE/MAT
** 3. à [[ASAC/AP|Polytech]] : Nicolas Palix
** 4. à [[ASAC/SJC|St Cassien]] : Nicolas Palix
* 5. [[Dataviz de la qualité de l'air et de la pollution sonore]], Didier Donsez, avec Atmo AURA et [https://github.com/CampusIoT/campusiot.github.io CampusIoT] (M)
* 6. [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]], Didier Donsez (S&M) (Tech Ionic à confirmer)
* 7. Intégration d'Intel [[Movidius]] ou [[MAix BiT]] à [[RobAIR]], Olivier Richard
* 8. [[Application mobile de secours du PGHM]] : Didier Donsez, Olivier Fabre (PGHM)
* 9. [[Application mobile pour la capture de marmottes]] : Didier Donsez, Franck Delbard
* 10. [[Supports pédagogiques open-source pour l'initiation à l’Internet des Objets pour l’enseignement de SNT (Sciences Numériques et Technologie) au lycée]] : Olivier Richard et Didier Donsez
* 11. [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]] : Didier DONSEZ, Franck ROUDET (Orange Labs Meylan)
* DatViz pour l'IoT
** 12. [[Amélioration de greffons Grafana]] : Didier Donsez
** 13. [[Tableau de bord et kit de mesure du confort dans les bâtiments de l'UGA]] : Didier Donsez, Fabien Hornebeck (DG DAPAL), Laurence Deligny (DG DAPAL)
** 14. [[Tableau de bord des capteurs LoRaWAN de la Ville de La Mure]] : Didier Donsez, Virginie Gondrand (Ville de La Mure)
** 15. [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]] : Didier Donsez, Jean-François Knoepfli (MoonshotLab), Joris Brémond (MoonshotLab)
* 16. [[Contributions open source au projet EdCampus]] : Didier Donsez, Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* 17. [[VisuGPX : Application mobile pour ski rando]], Didier Donsez, Ye.Ti (M)
* 18. [[Projet d'Auscultation Partagée]] avec IESE4 et TIS5, Olivier Richard, Didier Donsez, Julie Fontecave-Jallon
* 19. [[FPGA et Deep Learnning]] : Olivier Richard
* 20. [[Source Héritage et NIX]] : Olivier Richard
* 21. [[Proxy Cache HTTPS]] : Olivier Richard
* 22. [[Reverse Proxy pour gestionnaire de taches]] : Olivier Richard
* 23. [[Portail pour gestionnaire de taches]] : Olivier Richard
* 24. [[Paquets NIX pour Polytech]] : Olivier Richard
Non prioritaire
* [[Application mobile de calcul de son empreinte carbone]] : Didier Donsez, Anne Delaballe (Disrupt Campus), XX (Café Collapse)
* [[Serious game multi-joueurs pour tables tactiles en réseau]] : Anne-Laure Finkel, Tim Lepage, Didier Donsez. (S&M)
* [[Benchmark de MCU pour l'IoT]] : Didier Donsez
* [[Connecteur InfluxDB pour Cube.js]] : Didier Donsez
* [[SimCity]] avec [[ThreeJS]]
* [[WhereIsMyCar]] : application mobile pour se souvenir de l'endroit où sa voiture est garée. : Didier Donsez
* [[CannonBall de voitures autonomes 2018]]
* [[Covoiturage Solidaire]], Didier Donsez
* [[Intégration d'OpenAM à la génération de JHipster]] : Didier Donsez
* [[Comptage anonymisé de personnes]] : Didier Donsez et Franck Delbart
* Carte de service étudiant avec [[Eclipse Keyple]] : Didier Donsez
* [[Tableau de bord et kit de mesure du confort dans les bâtiments du CROUS]] : Didier Donsez (SOUS RESERVE)

==== Affectation ====
{|class="wikitable alternance"
|+ Affectation des projets INFO4 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 3
| [[ASAC/AP|Agriculture connectée Polytech]]
| VERNET MAXIME, SAJIDE IDRISS
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/3/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 4
| [[ASAC/ACJC|Agriculture connectée St Cassien]]
| LABBE NICOLAS,RUZAFA REMY
| PALIX Nicolas
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/4/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Testeur radio LoRaWAN en Ionic pour la plateforme CampusIoT]]
| CROCIATI MORGAN,GRAUGNARD TOM
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/6/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 7
| [[Intégration d'Intel Movidius ou MAix BiT à RobAIR]]
| PALOMO REMY, BOLEAT BAPTISTE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/7/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[Application mobile de secours du PGHM]]
| CHATON ALEXANDRA,FRION THOMAS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/8/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 9
| [[ Application mobile pour la capture de marmottes ]]
| EL JRAIDI RIM, NELSON WILLIAM
| Didier DONSEZ, Franck DELBARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/9/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[TODO]]
| CHAIX MANON,NGUENA ZEMAO GLORIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/10/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 11
| [[Géolocalisation indoor avec Bluetooth 5.1 Bluetooth Direction Finding: Angle of Arrival (AoA) and Angle of Departure (AoD)]]
| ARTAUD Adrien,FOUGERE SEBASTIAN
| Didier DONSEZ, Franck ROUDET
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/11/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 12
| [[Amélioration de greffons Grafana]]
| MURPHY MICA,VELUT CLAIRE
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/12/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| HO NHAT QUANG,MANISSADJIAN GABRIEL
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| BILOUNGA-BI-NDONG ALECK,LOMBARD MYRIAM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[Tableau de bord et kit de mesure du confort dans le bâtiment Moonshot Lab]]
| GUIVARCH ALAN, PAREILLEUX KILLIAN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 16
| [[Contribution au logiciel EDCampus]]
| BEAUGRAND ELISA,DE GAUDENZI LOUIS
| Didier Donsez, Anthony Geourjon
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/16/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[VisuGPX : Application mobile pour ski rando]]
| ZERAMDINI OTBA, EL MUFTI ALI, DELBOS ROBIN
| Didier Donsez
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[FPGA et Deep Learnning]]
| COURTHIAL SAMUEL, LUIS FILIPE VELASCO DA SILVA
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| [[Source Héritage et NIX]]
| PASDELOUP ROMAIN,SALMON ALEXANDRE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 21
| [[Proxy Cache HTTPS]]
| AUDIN RAPHAEL,RIVAL GAETAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/21/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 22
| [[Reverse Proxy pour gestionnaire de taches]]
| GUYOT SACHA,EL AJI HOUDA,ASSI DIMA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/22/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 23
| [[Portail_pour_gestionnaire_de_taches|Portail pour gestionnaire de tâches]]
| ROLLIN ALEXIS,SAGET ANTOINE
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/19-20/23/docs/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: ??? Septembre à ??? Décembre 2019.

===Projet Semestre S10===

Enseignants responsables : [[user:Donsez | Didier Donsez]]

Calendrier: 28/01 (13H30) à Fin Mars 2020.

Séances de Management de projets innovants: 29/01, 06/02, 13/02, 17/02, 18/03.

Réunion de présentation : 28/01 (13H30) . Faire couler le café.

Démarrage : 28/01 (13H30) . Faire couler le café.

Soutenance à mi-parcours : Début Mars, 9H00-11H30 (15 minutes par équipe).

Soutenance (puis Pot de la fin) : A définir : Semaine 16-20 Mars (probablement Jeudi ou Vendredi).

14/02: [https://wiki.eclipse.org/Eclipse_IoT_Day_Grenoble_2020 Eclipse IoT Day Grenoble]

====Propositions de projets S10====
* [[Contributions à Software Heritage]] : : Didier Donsez, Roberto Di Cosmo
* [[Contribution au projet open-souce ChirpStack]] (aka LoRaServer) : Didier Donsez
* [[Contributions open-source au projet JHipster]] : Didier Donsez
* [[Ecrire en gestes]] : Olivier Richard
* [[Kine 2.0]] (suite de [[Rééducation Kiné connecté]] 2019): Sylvain Toru
* [[Contributions open source au projet EdCampus]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Contributions open source au projet SmartRecruiting]] : Gérard Pollier (Disrupt Campus), Anthony Geourjon (Disrupt Campus)
* [[Secours Montagne avec LoRa]] : Bernard Tourancheau ??? avec le PGHM Isère
* [[Monnaies locales et blockchains]] avec Hyperledger, Didier Donsez, XXX (Cairn Grenoble). A CONFIRMER.
* [[IoTChain]] : Didier Donsez
* [[Projet STAPS]] : Didier Donsez

Reporté
* [[Analyse du pédalage cycliste sur home trainer via vidéo]] (Anthony Geourjon) en relation avec STAPS et TIS
* Projet IA/Edge: Databox : Olivier Richard

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2019-2020
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-

!scope="row"| 1
| [[Projet STAPS]]
| ANCRENAZ Ariane, SAUTON Tanguy, SIBUE Quentin, VINCENT Mathieu (CP)
| Didier Donsez
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 2
| [[Contributions à Software Heritage]]
| Nathan Dalaine, Joachim Fontfreyde, Léni Gauffier, Yann Gautier
| Didier Donsez, Roberto Di Cosmo
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-
!scope="row"| 3
| [[Projet Sauvetage en montagne]]
| WYKLAND Damien, BADAT Leya, CUAU Victor, MASSON Jeremy, ZARCOS Paul
| Bernard Tourancheau
| [https://gitlab.com/TODO/docs/suivi.md Fiche de suivi]
| [https://gitlab.com/TODO/docs/rapport.md Rapport final] - [https://gitlab.com/TODO/docs/rapport-technique.md Rapport technique] - [https://gitlab.com/TODO/presentation/intermediaire.md Présentation intermédiaire] - [https://gitlab.com/TODO/presentation/finale.md Présentation Finale] - [https://gitlab.com/TODO GitLab]
|-

|}

= Projets collectifs MAT/IESE =

== Années 3 et 4 ==

=[[Projets M2PGI Services Machine-to-Machine et Internet-of-Things]]=
==[[PM2M/2019/TP|PM2M]]==

VT2019

2019-11-24T16:07:42Z

Damien.Wykland: /* Séance 2 : 25/11 */

[[VT2018|<< Etudes 2018]] [[VT|Sommaire]] [[VT2020|Etudes 2020 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en 1FO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]] ou avec [[remarkjs]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 18/11 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* Présentation
* Choix des sujets

== Séance 2 : 25/11 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: Selenium - Automatisation de WebApps, BADAT, CUAU, [[Media:Selenium_VT2019.pdf|Slides]], [[Selenium|Fiche de synthèse]], [[VT2019 Selenium Demo|Démonstration]]
* 16h15 -> 16h45: Performance Monitoring, WYKLAND, [[Media:Perf monitoring.pdf|Slides]], [[VT2019_Performance_Monitoring|Fiche de synthèse]], [[VT2019_Demonstration_Grafana|Démonstration]]
* 16h45 -> 17h15: Iota, BETEND, JAN, [slides] [synthese]

== Séance 3 : 2/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 4 : 9/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 5 : 16/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 6 : 6/1/2020 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 7 : 13/1/2020 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

=Sujets=
# [[IoT Dataflow Mashup]] (démo avec [[Eclipse Kura Wires]])
# [[MapReduce et Hadoop]]
# [[Reconstruction 3D par Photogrammétrie]]
# [[ ARCore (Google) et ARKit (Apple) ]]
# [[JSONnet]]
# [[Géo-réplication]] : Démo avec [[Apache Kafka MirrorMaker]]
# [[Pulsar]]
# [[Elixir]] et [[Phoenix]] Web framework
# [[Wookey project]] (Demo on a STM32F407 Discovery board)
# [[RSocket]]
# [[Nacos]] : open source project by Alibaba for service discovery and service configuration.
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Architecture Serverless]] : démonstration avec le projet https://github.com/serverless/serverless sur votre compte Azure de votre compte GitHub Student Pack
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[Peloton]], a unified resource scheduler
# [[Microclimate]]
# [[AdTech]]
# [[Nearby communications]] (démonstration de [https://ionicframework.com/docs/native/google-nearby/ Nearby Messages API de Google avec Ionic])
# [[Conflict-free replicated data type]] (CRDT)
# [[Spinnaker]]

# [[gVisor]]: a new kind of sandbox that helps provide secure isolation for containers

# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]

# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]

# [[ESB]] : démonstration de [[Mule ESB]]
# [[MemCached]]

# [[Low-Power Global Area Network]]s ([[Sat-IoT]])
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[Psychométrie]]
# [[WebAssembly]]
# [[Fast Identity Online Alliance]] (FIDO)
# [[Apache MXNet]] : Demo avec [[Intel Movidius]] ([https://github.com/tspannhw/rpi-mxnet-movidius-minifi lien])
# [[DevSecOps]]
# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]
# [[Apache Beam]]
# [[plateforme logicielle open source de conduite autonome Apollo 2.0]]
# [[Mynewt]]
# [[Flogo]] Open Source Framework for IoT Edge Apps & Integration.
# [[Neural Processing Unit]] (NPU) : Demo de la clé [[Intel Movidius]] sur un RPI
# [[Huginn]]
# [[Snapcraft]]
# [[Kafka Streams]]
# [[Moby]] : démonstration de containers avec votre projet [[ECOM-RICM|eCOM]].
# [[Hazelcast]] : Démo avec Spring Boot ([https://dzone.com/storage/assets/6459742-dzone-rc247-gettingstartedwithspringbootandmicrose.pdf lien]) dans un projet [[JHipster]]
# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# [[Fautes Byzantines]] : Démonstration de [[BFT-SMaRt]]
# Insport Video
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]
# [[Performance Monitoring]]
# [[ADEPT]] : [[Blockchain]] at Home (ABANDONNé)
# [[ESB]] : démonstration de [[Mule ESB]]
# [[Access Network Query Protocol (ANQP)]]
# [[JCache]] : démonstration avec [[Apache Ignity]]
# [[MemCached]]
# [[Apache Stratos]]
# [[gceasy]] : Universal garbage collection log Analyser
# [[Apache Solr]] : Démonstration avec [http://hortonworks.com/hadoop-tutorial/indexing-and-searching-text-within-images-with-apache-solr/ Tesseract OCR]
# [[Valgrind]]
# [[Content Delivery Network]]s : Démonstration de [[Amazon S3]], Azure, Akamaï ... sur votre projet [[ECOM-RICM|eCOM]]
# [[CMS]] : Demo avec [[Crafter CMS]]
# [[DMS]] (GED) : Demo avec la version Community Edition d'[[Alfresco]] et de son API REST avec [[Swagger]]
# [[SIG]] : Démonstration de [[QGIS]]
# [[Apache Airflow]]
# [[Cryptojacking]] : démonstration d'un navigateur exécutant [https://github.com/cazala/coin-hive CoinHive] et affichage du coup énergétique de l'opération.
# [[RIOT-OS]] : système d'exploitation pour l'Internet des Objets (Démonstration sur une carte STM32 Nucleo LRWAN1).
# [[Zephyr]] : système d'exploitation pour l'Internet des Objets (Démonstration sur une carte [[Intel Quark D2000]]).
# [[HTTP/3]] : quoi de neuf ? Démonstration de l'amélioration des performances.
# [[Gyro]] : domain-specific language designed to concisely describe a cloud infrastructure. Démonstration avec votre application eCOM JHipster sur Azure.
# [[selenium]] contrôle automatisé de navigateur web - CUAU BADAT
# [[Rasa]] Traitement du langage naturel, chatbot -
# [[MPI]] DENIS & DE ARAUJO
# [[Brain Computer Interfaces ]] Alakali - Mastoura

File:Perf monitoring.pdf

2019-11-24T16:07:11Z

Damien.Wykland:

VT2019 Demonstration Grafana

2019-11-24T14:51:44Z

Damien.Wykland:

Voici la page de démonstration liée à la fiche de synthèse [[VT2019_Performance_Monitoring|Fiche de synthèse]].

=Prérequis=
Cette démo est très simple à reproduire étant donné que j'ai choisi d'utiliser docker sur tous les outils le supportant.

Il est donc nécessaire d'avoir une installation fonctionnelle de docker sur votre machine pour pouvoir continuer :

[[https://docs.docker.com/install/, Installer Docker]]

=Configuration sous Linux=
==Mise en place de InfluxDB et Grafana==
* Tout d'abord, placez vous dans un répertoire :
<pre>
mkdir /exemple && cd /exemple
</pre>

* Ensuite, vous pouvez créer le fichier docker-compose.yml avec le contenu ci-dessous :
<pre>
version: "2"
services:
grafana:
image: grafana/grafana
container_name: grafana
restart: always
ports:
- 3000:3000
networks:
- monitoring
volumes:
- grafana-volume:/var/lib/grafana
influxdb:
image: influxdb
container_name: influxdb
restart: always
ports:
- 8086:8086
networks:
- monitoring
volumes:
- influxdb-volume:/var/lib/influxdb
networks:
monitoring:
volumes:
grafana-volume:
external: true
influxdb-volume:
external: true
</pre>

* Ensuite vous devez créer le network ainsi que les deux volumes utilisés :
<pre>
docker network create monitoring
docker volume create grafana-volume
docker volume create influxdb-volume
</pre>

* Enfin, lancez le conteneur d'influxDB avec la commande -rm pour pouvoir configurer les variables d'environnement :

<pre>
docker run --rm \
-e INFLUXDB_DB=telegraf -e INFLUXDB_ADMIN_ENABLED=true \
-e INFLUXDB_ADMIN_USER=admin \
-e INFLUXDB_ADMIN_PASSWORD=supersecretpassword \
-e INFLUXDB_USER=telegraf -e INFLUXDB_USER_PASSWORD=secretpassword \
-v influxdb-volume:/var/lib/influxdb \
influxdb /init-influxdb.sh
</pre>

* La configuration est prête, pour lancer les conteneurs, il suffit de taper la commande suivante :

<pre>
docker-compose up -d
</pre>

Votre interface Grafana est désormais disponible à l'adresse localhost:3000 et la base de donnée à l'adresse localhost:8086

Remarque :
Il est nécessaire de configurer Grafana pour lui indiquer la source des données. Il suffit d'ajouter une source de donnée de type InfluxDB et de donner l'adresse suivante : http://influxdb:8086
Cela fonctionne grâce au network docker que nous avons créé auparavant.

==Mise en place de Telegraf==

* Tout d'abord, il est nécessaire d'installer Telegraf :

[[https://docs.influxdata.com/telegraf/v1.12/introduction/installation/, Installer Telegraf]]

* Ensuite, une fois installé, il suffit de modifier quelques lignes dans le fichier de configuration de Telegraf :

<pre>
###############################################################################
# OUTPUT PLUGINS #
###############################################################################
# Configuration for sending metrics to InfluxDB
[[outputs.influxdb]]
## The full HTTP or UDP URL for your InfluxDB instance.#### Multiple URLs can be specified for a single cluster, only ONE of the
urls = ["http://server1_ip:8086"]
## The target database for metrics; will be created as needed.
database = "telegraf"
## If true, no CREATE DATABASE queries will be sent. Set to true when using## Telegraf with a user without permissions to create databases or when the## database already exists.
skip_database_creation = true
## Name of existing retention policy to write to. Empty string writes to## the default retention policy. Only takes effect when using HTTP.# retention_policy = ""
## Write consistency (clusters only), can be: "any", "one", "quorum", "all".## Only takes effect when using HTTP.# write_consistency = "any"
## Timeout for HTTP messages.
timeout = "5s"
## HTTP Basic Auth
username = "telegraf"
password = "secretpassword"
</pre>

ATTENTION : Ne reprenez pas les mots de passe d'exemple cités ci-dessus.

=Utilisation de Grafana=

Maintenant que tout est configuré, il ne vous reste plus qu'a ajouter un dashboard qui vous plait depuis la liste des dashboards proposé par la communauté de Grafana, de selectionner notre base de donnée influxDB comme source, et vous pourrez monitorer la machine surveillée par Telegraf:

[[File:Dashboard grafana vt2019.png|600px|Exemple de Dashboard avec Grafana]]

=Sources=
* https://towardsdatascience.com/get-system-metrics-for-5-min-with-docker-telegraf-influxdb-and-grafana-97cfd957f0ac : Tutoriel de configuration avec Docker

VT2019 Performance Monitoring

2019-11-24T14:31:32Z

Damien.Wykland: /* Démonstration */

[[File:Dashboard grafana vt2019.png|600px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=
In a world where our IT structure is absolutely critical, even to the point where our lives could depend on it, we need some tools to assure that a system is working accordingly to its specs. That's where Performance Monitoring comes into play. It is composed of three main parts that are gathering, storing and visualing performance metrics. With the help of performance monitoring we can develop automated actions in case of failures, and even better, anticipate these failures to keep the systems running. I present here two main solutions to get started in monitoring metrics.

Keywords :
* Performance metrics
* Critical systems
* Availability
* Visualisation
* Analysis

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=
Voici la page de démonstration en lien avec cette synthèse : [[VT2019_Demonstration_Grafana|Démonstration]]

=Auteur=
* Année : [[VT2019|VT2019]]
* Sujet : Performance monitoring
* Auteur : [[User:Damien.Wykland | Damien WYKLAND]]

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019 Demonstration Grafana

2019-11-24T14:30:27Z

Damien.Wykland:

VT2019 Demonstration Grafana

2019-11-24T14:28:30Z

Damien.Wykland: /* Mise en place de Telegraf */

VT2019 Demonstration Grafana

2019-11-24T14:25:39Z

Damien.Wykland:

VT2019 Demonstration Grafana

2019-11-24T14:16:23Z

Damien.Wykland:

VT2019 Demonstration Grafana

2019-11-24T14:16:02Z

Damien.Wykland:

VT2019 Demonstration Grafana

2019-11-24T14:13:10Z

Damien.Wykland: Created page with "Voici la page de démonstration liée à la fiche de synthèse Fiche de synthèse. =Prérequis= Cette démo est très simple à reproduire..."

VT2019 Performance Monitoring

2019-11-24T14:06:30Z

Damien.Wykland:

[[File:Dashboard grafana vt2019.png|600px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=
In a world where our IT structure is absolutely critical, even to the point where our lives could depend on it, we need some tools to assure that a system is working accordingly to its specs. That's where Performance Monitoring comes into play. It is composed of three main parts that are gathering, storing and visualing performance metrics. With the help of performance monitoring we can develop automated actions in case of failures, and even better, anticipate these failures to keep the systems running. I present here two main solutions to get started in monitoring metrics.

Keywords :
* Performance metrics
* Critical systems
* Availability
* Visualisation
* Analysis

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Auteur=
* Année : [[VT2019|VT2019]]
* Sujet : Performance monitoring
* Auteur : [[User:Damien.Wykland | Damien WYKLAND]]

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019

2019-11-24T12:24:18Z

Damien.Wykland: /* Séance 2 : 25/11 */

[[VT2018|<< Etudes 2018]] [[VT|Sommaire]] [[VT2020|Etudes 2020 >>]]

=Veille Technologique et Stratégique=
* Enseignants: [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]
* UE/Module: EAM (HPRJ9R6B) et EAR (HPRJ9R4B) en 1FO5

L'objectif de cette UE est de réaliser un travail de synthèse et d’évaluation sur une technologie / spécification / tendance

Dans votre futur vie d'ingénieur, vous aurez à d'une part, vous former par vous-même sur une technologie émergente et d'autre part à réaliser une veille technologique (et stratégique) par rapport à votre entreprise et projet.
Il s'agira de réaliser
* le positionnement par rapport au marché
* d'être critique

Votre synthèse fait l'objet d'une présentation orale convaincante devant un auditoire (dans le futur, vos collègues, vos chefs ou vos clients) avec des transparents et un discours répété.
Pour finir de convaincre (Saint Thomas), vous ferez la présentation d'une démonstration.

Votre présentation sera noté et commenté par tous vos camarades via un sondage (téléphone mobile). Leurs notes et leurs commentaires seront notés en fonction de leur exactitude de jugement.

Remarque: Le [https://fr.wikipedia.org/wiki/Plagiat plagiat] est incompatible avec l'éthique de l'ingénieur. Le directeur d'école peut demander à votre traduction devant la commission disciplinaire de l'université. La sanction peut aller jusqu’à une interdiction d'inscription dans les établissements de l'enseignement supérieur français pendant plusieurs années : Le jeu, en vaut-il la chandelle ?

La présentation peut être réalisée avec [[reveal.js]] ou avec [[remarkjs]]

[[File:presentation-VT-RICM5-1516.pdf|transparents d'introduction à l'UE]]

=Planning=

== Séance 1 : 18/11 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* Présentation
* Choix des sujets

== Séance 2 : 25/11 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: Selenium - Automatisation de WebApps, BADAT, CUAU, [[Media:Selenium_VT2019.pdf|Slides]], [[Selenium|Fiche de synthèse]], [[VT2019 Selenium Demo|Démonstration]]
* 16h15 -> 16h45: Performance Monitoring, WYKLAND, [Slides], [[VT2019_Performance_Monitoring|Fiche de synthèse]], [[VT2019_Demonstration_Grafana|Démonstration]]
* 16h45 -> 17h15: Iota, BETEND, JAN, [slides] [synthese]

== Séance 3 : 2/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 4 : 9/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 5 : 16/12 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 6 : 6/1/2020 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

== Séance 7 : 13/1/2020 ==
Enseignants : [[User:Gpbonneau|Georges-Pierre Bonneau]], [[User:Donsez|Didier Donsez]]

* 15h45 -> 16h15: [sujet] [nom] [nom] [slides] [synthese]
* 16h15 -> 16h45: [sujet] [nom] [nom] [slides] [synthese]
* 16h45 -> 17h15: [sujet] [nom] [nom] [slides] [synthese]
* 17h15 -> 17h45: [sujet] [nom] [nom] [slides] [synthese]

=Sujets=
# [[IoT Dataflow Mashup]] (démo avec [[Eclipse Kura Wires]])
# [[MapReduce et Hadoop]]
# [[Reconstruction 3D par Photogrammétrie]]
# [[ ARCore (Google) et ARKit (Apple) ]]
# [[JSONnet]]
# [[Géo-réplication]] : Démo avec [[Apache Kafka MirrorMaker]]
# [[Pulsar]]
# [[Elixir]] et [[Phoenix]] Web framework
# [[Wookey project]] (Demo on a STM32F407 Discovery board)
# [[RSocket]]
# [[Nacos]] : open source project by Alibaba for service discovery and service configuration.
# [[NEMU]] : open source hypervisor specifically built and designed to run modern cloud workloads on modern 64-bit Intel and ARM CPUs.
# [[Architecture Serverless]] : démonstration avec le projet https://github.com/serverless/serverless sur votre compte Azure de votre compte GitHub Student Pack
# [[Fission]] : open-source serverless function framework for [[Kubernetes]] with a focus on developer productivity and high performance.
# [[Peloton]], a unified resource scheduler
# [[Microclimate]]
# [[AdTech]]
# [[Nearby communications]] (démonstration de [https://ionicframework.com/docs/native/google-nearby/ Nearby Messages API de Google avec Ionic])
# [[Conflict-free replicated data type]] (CRDT)
# [[Spinnaker]]

# [[gVisor]]: a new kind of sandbox that helps provide secure isolation for containers

# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]

# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]

# [[ESB]] : démonstration de [[Mule ESB]]
# [[MemCached]]

# [[Low-Power Global Area Network]]s ([[Sat-IoT]])
# [[ Voice-First Development]] : Designing, Developing, and Deploying Conversational Interfaces
# [[Psychométrie]]
# [[WebAssembly]]
# [[Fast Identity Online Alliance]] (FIDO)
# [[Apache MXNet]] : Demo avec [[Intel Movidius]] ([https://github.com/tspannhw/rpi-mxnet-movidius-minifi lien])
# [[DevSecOps]]
# Portails et l'API [[Portlet]] : Démo avec [[Liferay]]
# [[Apache Beam]]
# [[plateforme logicielle open source de conduite autonome Apollo 2.0]]
# [[Mynewt]]
# [[Flogo]] Open Source Framework for IoT Edge Apps & Integration.
# [[Neural Processing Unit]] (NPU) : Demo de la clé [[Intel Movidius]] sur un RPI
# [[Huginn]]
# [[Snapcraft]]
# [[Kafka Streams]]
# [[Moby]] : démonstration de containers avec votre projet [[ECOM-RICM|eCOM]].
# [[Hazelcast]] : Démo avec Spring Boot ([https://dzone.com/storage/assets/6459742-dzone-rc247-gettingstartedwithspringbootandmicrose.pdf lien]) dans un projet [[JHipster]]
# [[In-Memory Data Grids]] : Démonstration de [[Gigaspaces]] et [[XAP]] Open Source
# [[Fautes Byzantines]] : Démonstration de [[BFT-SMaRt]]
# Insport Video
# Gestionnaires de contenu : démonstration de [[Apache Jackrabbit]] dans le projet [[eCOM]]
# [[Memory-centric virtual distributed storage system]]
# [[Performance Monitoring]]
# [[ADEPT]] : [[Blockchain]] at Home (ABANDONNé)
# [[ESB]] : démonstration de [[Mule ESB]]
# [[Access Network Query Protocol (ANQP)]]
# [[JCache]] : démonstration avec [[Apache Ignity]]
# [[MemCached]]
# [[Apache Stratos]]
# [[gceasy]] : Universal garbage collection log Analyser
# [[Apache Solr]] : Démonstration avec [http://hortonworks.com/hadoop-tutorial/indexing-and-searching-text-within-images-with-apache-solr/ Tesseract OCR]
# [[Valgrind]]
# [[Content Delivery Network]]s : Démonstration de [[Amazon S3]], Azure, Akamaï ... sur votre projet [[ECOM-RICM|eCOM]]
# [[CMS]] : Demo avec [[Crafter CMS]]
# [[DMS]] (GED) : Demo avec la version Community Edition d'[[Alfresco]] et de son API REST avec [[Swagger]]
# [[SIG]] : Démonstration de [[QGIS]]
# [[Apache Airflow]]
# [[Cryptojacking]] : démonstration d'un navigateur exécutant [https://github.com/cazala/coin-hive CoinHive] et affichage du coup énergétique de l'opération.
# [[RIOT-OS]] : système d'exploitation pour l'Internet des Objets (Démonstration sur une carte STM32 Nucleo LRWAN1).
# [[Zephyr]] : système d'exploitation pour l'Internet des Objets (Démonstration sur une carte [[Intel Quark D2000]]).
# [[HTTP/3]] : quoi de neuf ? Démonstration de l'amélioration des performances.
# [[Gyro]] : domain-specific language designed to concisely describe a cloud infrastructure. Démonstration avec votre application eCOM JHipster sur Azure.
# [[selenium]] contrôle automatisé de navigateur web - CUAU BADAT
# [[Rasa]] Traitement du langage naturel, chatbot -
# [[MPI]] DENIS & DE ARAUJO
# [[Brain Computer Interfaces ]] Alakali - Mastoura

VT2019 Performance Monitoring

2019-11-24T12:21:35Z

Damien.Wykland: /* Abstract */

[[File:Dashboard grafana vt2019.png|600px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=
In a world where our IT structure is absolutely critical, even to the point where our lives could depend on it, we need some tools to assure that a system is working accordingly to its specs. That's where Performance Monitoring comes into play. It is composed of three main parts that are gathering, storing and visualing performance metrics. With the help of performance monitoring we can develop automated actions in case of failures, and even better, anticipate these failures to keep the systems running. I present here two main solutions to get started in monitoring metrics.

Keywords :
* Performance metrics
* Critical systems
* Availability
* Visualisation
* Analysis

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019 Performance Monitoring

2019-11-24T12:19:14Z

Damien.Wykland: /* Abstract */

[[File:Dashboard grafana vt2019.png|600px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=
In a world where our IT structure is absolutely critical, even to the point where our lives could depend on it, we need some tools to assure that a system is working accordingly to its specs. That's where Performance Monitoring comes into play. It is composed of three main parts that are gathering, storing and visualing performance metrics. With the help of performance monitoring we can develop automated actions in case of failures, and even better, anticipate these failures to keep the systems running.

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019 Performance Monitoring

2019-11-24T12:12:14Z

Damien.Wykland:

[[File:Dashboard grafana vt2019.png|600px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019 Performance Monitoring

2019-11-24T12:11:53Z

Damien.Wykland:

[[File:Dashboard grafana vt2019.png|1000px|thumb|Exemple de Dashboard avec Grafana]]
=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

File:Dashboard grafana vt2019.png

2019-11-24T12:09:45Z

Damien.Wykland:

VT2019 Performance Monitoring

2019-11-24T12:09:02Z

Damien.Wykland: /* Sources */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
[[File:Elk.png|thumb|800px|Fonctionnement de la solution ELK]]
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client
* https://techblog.commercetools.com/adding-consistency-and-automation-to-grafana-e99eb374fe40 : Comment automatiser Grafana
* https://www.elastic.co/fr/what-is/elk-stack : Suite ELK
* https://logz.io/blog/grafana-vs-kibana/ : Différences entre Grafana et Kibana

VT2019 Performance Monitoring

2019-11-24T12:06:51Z

Damien.Wykland: /* Sources */

VT2019 Performance Monitoring

2019-11-24T12:04:52Z

Damien.Wykland:

File:Elk.png

2019-11-24T12:04:10Z

Damien.Wykland:

VT2019 Performance Monitoring

2019-11-24T12:00:00Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:59:20Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:57:33Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement de la solution Telegraf + InfluxDB + Grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:56:49Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|thumb|800px|Fonctionnement telegraf + influxdb + grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:55:51Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|800px|Fonctionnement telegraf + influxdb + grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:55:28Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|600px|right|Fonctionnement telegraf + influxdb + grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:54:38Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|800px|right|Fonctionnement telegraf + influxdb + grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:54:20Z

Damien.Wykland: /* Solution "Telegraf + influxdb + Grafana" */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
[[File:Telegrafinfluxdbgrafana.png|right|Fonctionnement telegraf + influxdb + grafana]]
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

File:Telegrafinfluxdbgrafana.png

2019-11-24T11:52:27Z

Damien.Wykland:

VT2019 Performance Monitoring

2019-11-24T11:39:39Z

Damien.Wykland:

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

==Autres outils==
On peut citer quelques outils qui sont aussi utilisés :
* Graphite, qui est une solution "tout-en-un", qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web. Aujourd'hui il peut toujours servir de backend et être connecté à Grafana par exemple.
* Prometheus qui est un autre backend capable de récolter des métriques, les stocker, et les afficher en utilisant Grafana.

et beaucoup d'autres encore.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:32:58Z

Damien.Wykland: /* Kibana */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===
Kibana est l'outil de visualisation de la suite ELK. Il fournit toutes les fonctions nécessaire à la visualisation des données indexée dans ElasticSearch.

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:30:26Z

Damien.Wykland: /* ElasticSearch */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===
Outil principal de la suite Elastic, ElasticSearch est un moteur de recherche distribué très populaire en entreprise. Il permet de faire des recherches sur des documents en temps réel à travers une interface REST. Etant distribué, ElasticSearch supporte une montée en charge très facilement.

===Kibana===

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:27:18Z

Damien.Wykland: /* Logstash */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==Solution "ELK"==
===Logstash===
Logstash est un outil de collecte, d'analyse et de stockage de logs informatiques générés par tout type d'applications. Il fait partie de la famille des ETL (pour Extract-Transform-Load). Logstash peut donc récolter des logs, les filtrer, les analyser, et en extraire des informations.

===ElasticSearch===

===Kibana===

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T11:00:31Z

Damien.Wykland: /* ELK */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==Solution "ELK"==
===Logstash===

===ElasticSearch===

===Kibana===

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T10:59:23Z

Damien.Wykland: /* Telegraf + influxdb + Grafana */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Solution "Telegraf + influxdb + Grafana"==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==ELK==

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T10:57:20Z

Damien.Wykland: /* Exemple d'outils utilisés ensemble */

=Abstract=

=Introduction=
Né du besoin de surveiller la disponibilité, le temps de réponse et le comportement de nos applications et services courants, le performance monitoring (surveillance des performances) n'est en réalité qu'une suite d'outils permettant de suivre de bout en bout les données émanant de la ou les source(s) que l'on veut surveiller, jusqu'à une interface lisible, permettant de faire ressortir toutes éventuelles irrégularités et de lancer des alertes si nécessaire.

Que ce soit au niveau d'une application web, d'un réseau ou d'un serveur, si un élément est ralenti ou en panne, c'est toute l'experience utilisateur qui peut en souffrir. Il est ainsi primordial de pouvoir surveiller les métriques de tous nos systèmes en temps réel pour pouvoir agir le plus rapidement possible en cas de problème, mais surtout pour pouvoir anticiper ces problèmes avant même qu'il n'ai lieu grace à l'analyse des données. C'est pour cette raison que la notion de performance monitoring est aujourd'hui primordiale pour tout système jugé critique.

=Fonctionnement=

La plupart des solutions de performance monitoring peuvent être décomposés en trois parties distinctes :

* La récolte des données
* Le stockage des données
* La visualisation et l'analyse des données

===Recolte des données===
La recolte de données est la première étape pour toute surveillance de données. Les métriques surveillées peuvent être très diverses, donc les moyens de les récolter varient tout autant. Heureusement l'idée est simple : il suffit de récolter les données à partir d'une source et de les écrire dans la base de donnée. Ces sources sont aujourd'hui très variées, il est possible de surveiller des serveurs, des bases de données, toute application produisant des logs (sites webs, application mobiles), des réseaux et leurs charges, voir même des utilisateurs directement. On peut inclure aujourd'hui toutes les données émanant des capteurs de l'Internet of Things, qui représentent une source conséquente de données dont la majorité a pour unique vocation d'être monitoré (température, surveillance..)

Ainsi, beaucoup d'outils sont disponibles avec des plug-ins permettant d'adapter la récolte des données à tout projets existants relativement facilement. Cependant, les métriques recherchées sont souvent bas niveau (charge CPU, charge réseau, RAM utilisée..), ainsi l'application de récolte doit être installée directement sur tous les systèmes que l'on souhaite surveiller.

===Stockage des données===
Afin de pouvoir stocker toutes les données générée par les systèmes et récupérée par l'outil de récolte, il est judicieux de faire appel à des bases de données temporelle. En effet, ce sont des bases de données qui sont pensées pour fonctionner avec une notion de temps. Ainsi, il est possible de stocker un flux de donnée avec une métrique de temps et de pouvoir très facilement représenter ces données par la suite.

===Visualisation et analyse des données===
La partie la plus intéressante d'un point de vue monitoring est la visualisation de données. Le principe est de récupérer les métriques de la base de donnée temporelle et de les afficher sur un dashboard de manière concise, lisible et permettant ainsi en un clin d'oeil de repérer les anomalies d'un système ou d'un groupement de systèmes. Aujourd'hui, les outils de visualisation populaire sont des interfaces webs, permettant facilement la visualisation des données à distance. Il est possible de garder le stockage et la visualisation des données sur le même serveur de manière centralisé, comparé aux outils de récolte qui doivent être déployés.

=Exemple d'outils utilisés ensemble=
Comme vu précédemment, on distingue trois parties différentes dans un système de performance monitoring. Bien qu'il existe de nombreux outils de récolte de données, de stockage et de visualisation, on retrouve généralement les mêmes outils utilisés ensemble pour leurs cohérences et leurs compatibilité.

Voici quelques exemples d'outils utilisés ensemble :

==Telegraf + influxdb + Grafana==
===Telegraf===
Telegraf est un agent écrit en langage Go utilisé pour la collecte de métriques de performance du système sur lequel il est executé, et sur les services tournant sur ce même système. Il a été designé dans l'optique d'être très léger en utilisation mémoire, avec un système de plug-ins à intégrer en fonction des besoins du développeur, permettant de créer un telegraf "sur mesure". Il est donc très facile pour les développeurs de créer de nouveaux plugins pour collecter de nouvelles métriques. Il se connecte très facilement à InfluxDB ou tout autre service de base de données supporté.

===Influxdb===
InfluxDB est un système de gestion de base de données orientée séries chronologiques. Cela veut dire qu'InfluxDB est optimisé pour du stockage rapide avec très haute disponibilité de données estampillées avec une notion de temps. De fait, c'est un moyen de stockage idéal pour des métriques de performances qui sont forcément chronologiques, des données de capteurs IoT, ou n'importe quelle utilisation avec des données en temps réel. InfluxDB est également écrit en Go.

===Grafana===
Grafana est une interface permettant la visualisation et la mise en forme de données métriques. Grafana représente donc la partie visible de notre monitoring de performance en proposant des dashboards customisable très rapidement et permettant d'avoir une vue d'ensemble sur toutes les données que l'on agrège, en temps réel. Grafana est compatible avec plusieurs sources, dont InfluxDB, Graphite (qui était un système de performance très utilisé avant l'arrivée des interface de visualisation web) et Prometheus.

==ELK==

=Importance du monitoring de performance dans le domaine du web=
Différentes études montrent qu'un site web qui met trois secondes à charger fait perdre 40% de ses visiteurs. Le délai entre chaque changement de pages contribue aussi grandement à détourner les clients. Dans un marché ou la concurrence est rude, il est aujourd'hui indispensable d'avoir un site qui est non seulement rapide mais sans bugs et sur tout support (mobile et desktop).
On va ainsi surveiller plusieurs métriques, en voici quelques exemples :

* Le temps jusqu'à l'arrivée du premier octet au client
* Le temps de chargement de la page
* La durée du rendu côté client
* La durée du DNS..

=Démonstration=

=Sources=
* https://neilpatel.com/blog/loading-time/?wide=1 : Conséquences des délais de chargement sur la satisfaction client

VT2019 Performance Monitoring

2019-11-24T10:39:42Z

Damien.Wykland: /* Introduction */

VT2019 Performance Monitoring

2019-11-24T10:34:35Z

Damien.Wykland:

VT2019 Performance Monitoring

2019-11-24T10:32:30Z

Damien.Wykland: /* Fonctionnement */

VT2019 Performance Monitoring

2019-11-24T10:32:16Z

Damien.Wykland: /* Importance du monitoring de performance dans le domaine du web */

VT2019 Performance Monitoring

2019-11-24T10:31:57Z

Damien.Wykland: /* Sources */

VT2019 Performance Monitoring

2019-11-24T10:27:13Z

Damien.Wykland:

VT2019 Performance Monitoring

2019-11-24T10:26:21Z

Damien.Wykland: /* Recolte des données */

VT2019 Performance Monitoring

2019-11-24T10:24:41Z

Damien.Wykland: