Fiabilité et Sécurité des Applications

Pourquoi surveiller des applications ?

• Être au courant des problèmes
• Pouvoir réagir en cas de problèmes
• Modéliser le comportement des applications pour les améliorer
• Anticiper les situations
• Économiser les ressources

Surveillance des applications

Que faut-il mettre en place ?

• Des systèmes et/ou du code pour
  • produire l’information souhaitée <-
  • collecter cette information
  • stocker l’information
  • exploiter l’information <-

Quel impacts sur le développement d’applications ?

Équiper l’infrastructure pour produire, collecter et conserver l’information

• domaine des “ops”
• côté “devs”: important de savoir ce qui peut être fait

Équiper les applications pour produire l’information

• domaine des “devs”
• savoir comment faciliter la vie des “ops”

État de santé d’une application

• Active ?
• Fonctionnement correct ?
• Performances correctes ?
• Quelle utilisation des ressources ?
• Objet d’une attaque ?
• Dysfonctionnements internes / causés par d’autres applications ?

Cycle de vie d’une application

• Configuration
• Interactions avec l’environnement
  • e.g. connexion à une BD
• Démarrage
• L’application s’exécute
• Arrêt

Cycle de vie et monitoring

Dans quel état se trouve l’application ?

• A-t-elle démarré ?
  • Le processus est-il lancé ?
  • Les phases de configuration sont-elles terminées ?
  • Les ports sont-ils ouverts ?
• Est-elle en fonctionnement ?
  • Le processus est-il encore vivant ?
  • L’application répond-elle aux requêtes ?

Cycle de vie et K8S

• K8S teste si les conteneurs ont terminé
  • Les conteneurs terminés en erreur peuvent être relancés automatiquement
• Déploiements et StatefulSets:
  • Création de pods additionnels au besoin
• Changement de configuration
  • Mise à jour de fichiers de configuration dans le conteneur
  • Destruction/recréation de pod en cas de changement plus statique de la configuration

Sondes

• Code qui s’exécute pour tester l’état de l’application
  • Dépendant de l’application
    • Requête HTTP
    • Parsing de logs
    • Présence de fichiers
• Le résultat d’une sonde est booléen: réussite ou échec
  • +unknown si échec interne

Sondes dans K8S

• Types dans k8s (doc):
  • readyness: l’application est démarrée et est prête à recevoir des requêtes
  • liveness: l’application est en fonctionnement (mais pas forcément apte à recevoir des requêtes)
  • startup: l’application a terminé sa phase de démarrage (à utiliser uniquement si le démarrage est très long ou imprévisible)

Configuration dans K8S

• Configurable par conteneur
• code à exécuter
  • exec dans le conteneur
  • httpGet: requête HTTP GET sur le conteneur
  • autres: tcpSocket (port ouvert), grpc (réponse)
• délai initial et fréquence

Consommation des ressources

• Mesures fournies par l’infrastructure
  • CPU, RAM, disque, bande passante
• Utile pour:
  • détecter des bugs, e.g. fuite mémoire
  • détecter une charge anormale, e.g. CPU
  • anticiper les saturations (disque, mémoire)
  • identifier les composants gourmands
  • scaling, éventuellement automatisé
  • load balancing

Performances métier (1)

Exemples de types de mesures

• temps de réponses
• nombre de requêtes

Performances métier (2)

Cibles des mesures

• l’application elle-même
• les services tiers

Performances métier (3)

Usages

• levée d’alerte sur l’utilisabilité
• diagnostic de performance
• détection de pannes tierces

Prometheus

• Base de donnée “time-series”
• Très utilisée pour la collecte et l’archivage de métriques
• Intègre une interface basique de requêtage
  • filtrage par mots-clé
• Déploiement léger
  • Attention à l’espace disque

Prometheus: mise en oeuvre

• Le serveur Prometheus
  • pull les mesures
  • à intervalles réguliers
• Les fournisseurs de mesures (applications, infra, etc)
  • exposent les mesures
  • en HTTP
  • dans un format texte particulier

Nombreuses bibliothèques disponibles pour mettre à disposition des mesures depuis une application

Logs: pourquoi faire ?

• Savoir ce qui se passe dans son application
  • Audit
  • Détection de problèmes
  • Diagnostics

Contenus des logs

• Une information explicite
  • Éviter “Je suis passé ici”
• Du contexte:
  • timestamp
  • origine dans le code
  • des informations sur la requête à l’origine du calcul

On utilise une bibliothèque de logging

Niveaux de log

Error, Warning, Info, Debug, Trace, etc

• Objectif: pouvoir décider facilement de la production de certains logs
• sans avoir à repackager l’application
• sur simple configuration
• voire avec une reconfiguration dynamique

Suivi de requêtes

• Nécessité de tracer les enchaînements d’appels
• au sein d’une application concurrente
• entre différentes applications

=> Création d’identifiants pouvant être utilisés pour tracer les requêtes

Injection de contexte

• Pouvoir ajouter des information ad-hoc de contexte dans les logs
• Ensemble de clés valeurs automatiquement ajoutées
  • e.g. identifiant de requête
• Possibilité d’ajouter des paires dans un contexte
• Contexte géré implicitement
  • MDC en Java

Pourquoi requêter ?

• Nécessité de chercher des mesures/logs particuliers pour
  • découvrir des problèmes (remontées d’alertes)
  • comprendre la source d’un problème (diagnostic)
  • modéliser des comportements (analyse offline)

Filtrage et monitoring/logging structuré

Pour un filtrage efficace:

• méta-données associées aux logs
  • contexte de production
    • application, instance (infra)
    • requête, code, timestamp, utilisateur, etc (app)
• en général sous formes de clés/valeurs
• dans un format rapide à parser par les application de collecte/stockage
  • e.g. JSON