L'informatique sans serveur a transformé la façon dont les équipes construisent et déploient des applications, offrant une évolutivité quasi infinie et un prix de paiement par exécution. Mais les mêmes caractéristiques qui rendent les environnements d'exécution sans serveur attrayants, les environnements d'exécution à courte durée de vie, l'échelle automatique et une architecture fortement répartie, créent des points aveugles de surveillance importants. Sans un tableau de bord conçu spécialement, les équipes peinent à corréler une seule demande d'utilisateur à des dizaines d'invocations de fonctions, à détecter la latence de démarrage à froid ou à comprendre les facteurs de coûts.

Les défis uniques de la surveillance de l'informatique sans serveur

Les fonctions sans serveur sont apatrides et éphémères. Une fonction AWS Lambda peut fonctionner pendant quelques centaines de millisecondes, puis disparaître. Cette nature transitoire rend difficile l'agrégation des mesures à travers les invocations, surtout lorsque les fonctions sont déclenchées par des événements provenant de sources multiples. L'environnement d'exécution est également partagé, ce qui signifie que les démarrages froids – le retard lorsqu'une nouvelle instance de fonction tourne – peuvent introduire une latence imprévisible.

En outre, les architectures sans serveur impliquent souvent de nombreux petits services couplés de façon lâche. Tracer une transaction sur API Gateway, Lambda, DynamoDB et Step Functions nécessite des outils de traçage distribués. Sans tableau de bord consolidé, les ingénieurs perdent du temps à sauter entre des interfaces de surveillance séparées.

Pourquoi les tableaux de bord Générique Automne Court

Les fournisseurs de Cloud comme AWS, Azure et Google Cloud offrent des tableaux de bord de surveillance pré-construits pour leurs services sans serveur. Par exemple, AWS CloudWatch fournit un tableau de bord Lambda avec des nombres d'invocations, des taux d'erreur et des percentiles de durée.

  • Lack de contexte de services croisés:[ Une seule demande d'utilisateur pourrait impliquer API Gateway, Lambda, SQS et DynamoDB. Les tableaux de bord des fournisseurs de services de cloud montrent rarement la relation entre ces services.
  • Customisation limitée:[ Vous ne pouvez pas facilement filtrer par des étiquettes personnalisées (p. ex. environnement, équipe, drapeau de fonction) ou créer des mesures composites.
  • Aucune intégration avec des outils externes:[ Vous pourriez avoir besoin de corréler les mesures du cloud avec les données de performance d'application des outils APM ou des journaux d'un agrégateur central.
  • Grâcité insuffisante:[ Les tableaux de bord standard montrent souvent des agrégats sur des fenêtres à longue durée, en dissimulant des pics à courte durée ou des problèmes de démarrage à froid.

Les tableaux de bord personnalisés comblent ces lacunes en permettant aux équipes de définir exactement ce qui compte : de la concordance en temps réel et des pourcentages de démarrage à froid à la budgétisation par fonction et par erreur.

Métriques de base Chaque tableau de bord sans serveur devrait suivre

Avant de construire un tableau de bord, identifiez les paramètres qui affectent directement vos objectifs de niveau de service (SLO) et votre coût. Bien que l'ensemble exact dépend de votre application, les éléments suivants sont universellement importants pour les charges de travail sans serveur:

  • Compte d'invocation et de proximité:[ Vous indique combien de charge vos fonctions poignée.
  • Taux d'erreur et types d'erreur:[ Suivez toutes les réponses 4xx et 5xx, les chronométrages et le throttling.
  • Durée percentiles (p50, p95, p99):[ Le temps d'exécution affecte directement l'expérience utilisateur et le coût (car vous payez pour la durée).
  • Taux de démarrage et latence froids:[ Les démarrages froids affectent l'expérience utilisateur. Surveillez le pourcentage d'invocations froides et la latence supplémentaire qu'ils introduisent.
  • Invocations angoissées:[ Lorsque la concordance dépasse la limite réservée, les fonctions sont throttlées. Cette mesure vous aide à ajuster la concordance réservée ou à demander une augmentation de limite.
  • Coût par invocation (facultatif mais recommandé):[ La combinaison des paramètres d'invocation, de durée et de mémoire vous donne un coût estimé par exécution. Un tableau de bord qui montre les tendances des coûts aide à prévenir les surprises budgétaires.
  • Mesures commerciales personnalisées:[ Par exemple, nombre de commandes traitées, d'inscriptions d'utilisateurs ou de transformations d'images.

Construction de blocs d'un tableau de bord de surveillance personnalisé

Un tableau de bord robuste et personnalisé repose sur quatre piliers : collecte, stockage, visualisation et alerte. Chaque bloc doit être soigneusement choisi et configuré pour supporter les charges de travail sans serveur.

Collecte de données

Les fonctions sans serveur émettent des métriques et des journaux via les services de surveillance natifs du fournisseur de cloud (CloudWatch, Azure Monitor, Google Cloud Monitoring). De plus, vous pouvez utiliser les instruments de vos propres fonctions pour émettre des métriques personnalisées en utilisant les SDK du fournisseur ou les bibliothèques open-source. Par exemple, dans un Node.js Lambda, vous pouvez utiliser le paquet pour envoyer asynchronement des métriques personnalisées de CloudWatch. Pour collecter des données de plusieurs fournisseurs dans un environnement hybride ou multicloud, envisagez d'utiliser un collecteur basé sur un agent comme les exportateurs de Prometheus ou Telegraf.

Stockage et consultation

Les bases de données de séries chronologiques sont le choix naturel pour la surveillance des paramètres. Prométhée[ est une option open-source populaire qui fonctionne bien sans serveur si vous définissez un paramètre d'écriture distante ou utilisez un service Prométhée géré de votre fournisseur de cloud. Vous pouvez également utiliser une base de données à usage général comme Elasticsearch pour les journaux et les paramètres ensemble.

Visualisation

La couche de visualisation consomme les données de la base de données des séries chronologiques et rend des tableaux de bord interactifs.Grafana[] est la norme de facto pour cela, prenant en charge Prométhée, CloudWatch, Elasticsearch, et des dizaines d'autres sources de données.

Alerte

Les tableaux de bord ne sont pas seulement pour la visualisation passive; ils doivent déclencher des notifications lorsque les mesures traversent des seuils prédéfinis. Prométhée et Grafana ont tous deux des moteurs d'alerte intégrés. Réglez les alertes pour des taux d'erreur élevés, des latences anormales, des pourcentages élevés de démarrage à froid et des limites de convergence.

Choisir les bons outils pour votre tableau de bord

Le paysage d'outillage pour la surveillance sans serveur est vaste. Votre choix dépend de l'infrastructure existante, de l'expertise de l'équipe et du budget. Voici les combinaisons les plus courantes:

  • Grafana + Prométhée + CloudWatch Exportateur: Une pile open-source qui vous donne le contrôle total. Configurez l'exportateur CloudWatch pour tirer les métriques de Lambda dans Prométhée, puis visualisez dans Grafana. Cette pile fonctionne bien pour les équipes qui exécutent déjà Kubernetes ou ont une expérience opérationnelle.
  • Datadog: Une solution SaaS avec des intégrations sans serveur profondes, y compris le traçage en temps réel, la gestion des journaux et des tableaux de bord sans serveur pré-construits. ]Datadog] vous permet de créer des tableaux de bord personnalisés avec son propre langage de requête et prend en charge l'alerte sur les paramètres, les journaux et les traces.
  • Nouvelle Relique: Similaire à Datadog, avec une forte instrumentation sans serveur et un constructeur de tableau de bord flexible. Son module de surveillance sans serveur découvre automatiquement les fonctions et les map aux services.
  • Cloud fournisseur natif + visualisation tierce:[ Par exemple, en utilisant AWS CloudWatch Logs Insights pour requête et Grafana , la source de données CloudWatch pour visualisation. Cette approche évite de payer pour un magasin de métriques séparé, mais peut être moins performant à l'échelle.
  • Le tableau de bord sans serveur: Si vous utilisez le cadre sans serveur, son tableau de bord intégré offre une façon simple de surveiller les invocations, les erreurs et les journaux de fonctions.

Guide étape par étape : Construire un tableau de bord personnalisé avec Grafana et Prométhée

Ce guide se déplace à travers la création d'un tableau de bord de surveillance complet pour AWS Lambda en utilisant Grafana et Prométhée avec l'exportateur CloudWatch. La même approche peut être adaptée pour les fonctions Azure ou Google Cloud.

1. Configurer Prométhée et l'exportateur CloudWatch

Installez Prométhée sur un serveur (ou utilisez un service géré comme Amazon Managed Service for Prométhée). Ensuite, exécutez le , qui gratte les paramètres CloudWatch et les expose au format Prométhée. Configurez l'exportateur pour recueillir les paramètres clés de Lambda : , , , et . Par exemple, la configuration de l'exportateur pourrait comprendre :

metrics:
 - aws_namespace: AWS/Lambda
 aws_metric_name: Invocations
 aws_dimensions: [FunctionName]
 aws_statistics: [Sum]
 - aws_namespace: AWS/Lambda
 aws_metric_name: Duration
 aws_dimensions: [FunctionName]
 aws_statistics: [Average, p95, p99]

Une fois que l'exportateur est en marche, il expose un paramètre que Prométhée peut érafler.

2. Configurer Prométhée pour écraser l'exportateur

Ajoutez une tâche de grattage dans votre fichier qui pointe vers le paramètre export. Réglez un intervalle de grattage de 30 à 60 secondes – les mesures sans serveur sont souvent agrégées en une minute par CloudWatch, donc un grattage plus rapide est inutile.

3. Installer et connecter Grafana

Déployez Grafana (cloud ou on-premises) et ajoutez Prométhée comme source de données. Fournissez l'URL du serveur Prométhée. Testez la connexion pour s'assurer que les mesures sont en cours.

4. Créer un tableau de bord pour la santé fonctionnelle

Dans Grafana, créez un nouveau tableau de bord et commencez à ajouter des panneaux. Pour un panneau de vue d'ensemble, utilisez la requête PromQL pour afficher le taux d'invocation global. Ajoutez un panneau pour le taux d'erreur : . Utilisez un panneau de séries chronologiques avec des seuils de couleur (verts sous 1 %, jaunes entre 1 % et 5 %, rouges au-dessus de 5 %).

5. Ajouter un panneau pour les percentiles de durée

Interrogez les percentiles de durée en utilisant si vous exportez une métrique d'histogramme. Sinon, utilisez la statistique de l'exportateur de CloudWatchs p95. Affichez les p50, p95 et p99 en tant que séries séparées sur un seul graphique.

6. Créer un groupe de travail axé sur le démarrage à froid

Si vous exportez une métrique personnalisée pour les démarrages à froid (en instrumentant votre fonction pour enregistrer une valeur de 1 sur le démarrage à froid et de 0 sur le démarrage à chaud), vous pouvez calculer le taux de démarrage à froid : . Utilisez un panneau de jauge pour afficher le pourcentage.

7. Mettre en place des alertes à Grafana

Grafana v8 et plus tard ont un système d'alerte unifié. Créez une règle d'alerte pour les taux d'erreur élevés (par exemple, >5% sur 5 minutes) et pour la durée élevée de p99 (par exemple, >3 secondes). Configurez les canaux de notification pour Slack et email. Testez l'alerte avec une requête d'échantillon pour s'assurer qu'elle allume correctement.

Caractéristiques avancées: Aller au-delà des mesures de base

Une fois le tableau de bord de base en place, envisager de l'améliorer avec des capacités avancées qui fournissent une meilleure compréhension opérationnelle.

Loges et métriques corrélatives

De nombreux problèmes sans serveur nécessitent de regarder les journaux aux côtés des métriques. Par exemple, un pic d'erreurs peut être causé par une charge utile d'entrée spécifique. Ajoutez un panneau de journaux à votre tableau de bord Grafana en utilisant une source de données comme Loki (pour Prométhée) ou Elasticsearch. Créez une corrélation qui vous permet de cliquer sur un pic métrique et de voir les entrées de journaux connexes dans le contexte.

Détection d'anomalies avec apprentissage automatique

Les seuils statiques fonctionnent pour des modèles connus, mais le trafic sans serveur peut être saisonnier ou en rupture. Utilisez des services comme AWS CloudWatch Anomalily Detection ou un outil de surveillance dédié basé sur ML pour détecter des comportements inhabituels.

Tableau de bord pour l'optimisation des coûts

Les coûts sans serveur sont déterminés par les invocations de fonction, la durée et l'allocation de mémoire. Créez un tableau de bord séparé qui affiche le coût par fonction, le coût par environnement et les dépenses mensuelles estimées. Combinez les paramètres de facturation CloudWatch avec les paramètres d'utilisation de Lambda. Par exemple, utilisez la métrique de AWS/Billing et corrélez-la avec les résumés de fonction.

Panneaux métriques d'affaires personnalisés

Instrumentez vos fonctions pour émettre des mesures personnalisées qui reflètent les résultats de l'entreprise : nombre de commandes, transactions ratées, inscriptions de l'utilisateur, etc. Intégrez-les dans votre tableau de bord opérationnel afin que, lorsqu'une panne technique survient, vous puissiez immédiatement voir l'impact de l'entreprise.

Meilleures pratiques pour l'entretien continu du tableau de bord

La construction d'un tableau de bord n'est pas une activité ponctuelle. À mesure que votre architecture sans serveur évolue, votre surveillance doit également être assurée.

  • Itérer en fonction des incidents:[ Après un incident de production, examinez si votre tableau de bord aurait fait surface la cause racine plus rapidement. Ajoutez des paramètres manquants ou créez de nouveaux panneaux en conséquence.
  • Continuez à vous concentrer : Un tableau de bord encombré de dizaines de panneaux est difficile à lire en cas d'urgence. Visez les panneaux de 5 à 10 par vue et séparez les paramètres opérationnels des paramètres opérationnels en différents onglets ou tableaux de bord.
  • Utilisez des noms et des balises uniformes: Appliquer des balises uniformes (p. ex. , ) à toutes les fonctions et ressources.
  • Création automatique du tableau de bord:[ Utilisez des outils de code infrastructure-comme Terraform ou l'API Grafana pour fournir des tableaux de bord à côté de vos déploiements sans serveur.
  • Rédiger un examen automatisé :[ Prévoir des examens trimestriels avec l'équipe pour faire des pans désuets et en ajouter de nouveaux. Les tableaux de bord que personne ne regarde sont un fardeau de maintenance – si une mesure n'est pas actionnable, le supprimer.
  • Éduquer l'équipe :[ Assurez-vous que tous les ingénieurs savent interpréter le tableau de bord et comment effectuer des forages dans des billots lorsqu'ils détectent une anomalie. Un tableau de bord n'est que aussi bon que les gens qui l'utilisent.

Conclusion

En construisant des tableaux de bord personnalisés de surveillance adaptés à vos fonctions, aux modes de trafic et aux paramètres opérationnels, vous obtenez une visibilité en temps réel en termes de performance, de coût et de fiabilité. La combinaison d'outils open-source comme Prométheus et Grafana avec des services de surveillance cloud-native offre une pile flexible et puissante qui s'échelle avec votre environnement. Commencez par un petit ensemble de mesures de base – invocations, erreurs, durée, démarrages à froid – et développez-vous progressivement à mesure que votre compréhension de votre comportement sans serveur s'approfondit. Avec un tableau de bord bien conçu, vous pouvez détecter les problèmes avant qu'ils n'aient une incidence sur les utilisateurs, optimiser l'utilisation des ressources et maintenir l'agilité que vous promettez sans serveur.