Synthèse ● Savoir quoi monitorer ● Sélectionner "astucieusement" ses sondes ○ Selon le public visé ○ Selon le contexte (bug passager moissonnage & TLSv1) Risques liés au monitoring ● Submersion sous l'information ● Le monitoring a un coût (rétention, nouvelle infrastructure) ● … Mais c'est nécessaire

1. geOrchestra &
Monitoring

2. Le monitoring
C’est avoir des informations factuelles et en temps réel sur le
fonctionnement de sa plateforme.
● Service Up ou indisponible
● Service opérationnel ou en panne (Erreurs)
● Utilisation (fréquentation et usage)
● Performance du webservice (temps de réponse)
● Contenu/configuration/validation OGC/Inspire
● La base pour le reportage, suivi des usages et des SLA
Transparence des actions et de politiques publiques

3. Le monitoring
Cela sert:
● Communiquer auprès de ses utilisateurs (UP!!!)
● Administrer sa plateforme
○ Vision agrégée du contenu
○ Optimiser les configurations
● Dépanner (identifier la panne, ex: composant, multihost)
● Infogérer (dimensionnement des ressources (RAM/CPU)
● Faire du reportage
○ Prouver que cela marche: Disponibilité / SLA
○ Justifier de l’utilisation auprès des decisionnaires #Utilisateurs, #de
tuiles, #requetes

4. Architecture simplifiée
HTTP

5. Comment ça marche?
ping API

6. Différents publics, différents
dashboards
● État des services (utilisateurs finaux)
● Monitoring de la plateforme (administrateur(s))
● Monitoring de l'infrastructure (développeurs /
sysadmins)

7. Outils de monitoring

8. Page de status publique

9. Reportage disponibilité IDG

10. SLA / reportage
Fiabilité, Transparence et indépendance de l’information fournie
● service externe, ex. Pingdom, qui fait des tests depuis ses propres
serveurs
● reporting opérationnel, même si la plateforme est DOWN
Besoins pour les sondes externes:
● Architecture orientée service Web
● Accessibilité de la plateforme aux sondes

11. Monitoring métier (core)

12. Liste d’éléments IDG monitorable
● Informations système des serveurs de la plateforme
● Statuts PINGDOM
● Nombre d’utilisateurs en attente / expirés / sans rôle / Nb total
● Nombre d’organismes en attente / nb total
● Nombre de couches cassées / nombre de couches total
● Nombre de MD invalides / non conformes inspire / OpenData / nb de MD total
● Liens MD/données cassées
● … ?

13. Monitoring - dev (ops)

14. Analyse des logs

15. Profilage

16. Suivi des webservices

17. Synthèse
● Savoir quoi monitorer
● Sélectionner "astucieusement" ses sondes
○ Selon le public visé
○ Selon le contexte (bug passager moissonnage & TLSv1)
Risques liés au monitoring
● Submersion sous l'information
● Le monitoring a un coût (rétention, nouvelle
infrastructure)
● … Mais c'est nécessaire

18. Conclusion
● Différents outils, différents usages, différents publics
● Outils utilisés matures
● Équipe devops: Grande expertise dans le domaine