Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Geocom2017] Georchestra & monitoring

150 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

[Geocom2017] Georchestra & monitoring

  1. 1. geOrchestra & Monitoring
  2. 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. 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. 4. Architecture simplifiée HTTP
  5. 5. Comment ça marche? ping API
  6. 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. 7. Outils de monitoring
  8. 8. Page de status publique
  9. 9. Reportage disponibilité IDG
  10. 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. 11. Monitoring métier (core)
  12. 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. 13. Monitoring - dev (ops)
  14. 14. Analyse des logs
  15. 15. Profilage
  16. 16. Suivi des webservices
  17. 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. 18. Conclusion ● Différents outils, différents usages, différents publics ● Outils utilisés matures ● Équipe devops: Grande expertise dans le domaine

×