Managed Service for Prometheus:Connecter des applications Spring Boot à Managed Service for Prometheus

Contexte

Les applications MVC traditionnelles basées sur SSM nécessitent une configuration complexe où la moindre erreur peut provoquer des dysfonctionnements. Spring Boot résout ce problème grâce à l'auto-configuration : si les packages JAR nécessaires sont présents, Spring Boot configure automatiquement l'application. Vous pouvez également remplacer les classes d'auto-configuration par des configurations personnalisées pour développer rapidement des applications de niveau entreprise.

Un système de surveillance complet pour les applications Spring Boot se compose généralement des éléments clés suivants.

Collect monitoring data

Les méthodes les plus courantes pour collecter les données de surveillance sont les modèles push (poussée) et pull (extraction). L'écosystème de surveillance Prometheus est un exemple type de système basé sur le modèle pull. Managed Service for Prometheus illustre parfaitement ce modèle. Les applications et l'infrastructure exposent les données de surveillance via une interface conforme à OpenMetrics, et Managed Service for Prometheus extrait périodiquement ces données pour les stocker à long terme.

OpenMetrics est un protocole de métriques natif du cloud, hautement évolutif, qui définit la norme pour le reporting des métriques cloud-native à grande échelle. Il prend en charge à la fois la représentation textuelle et les Protocol Buffers. Le format textuel, plus répandu, constitue le protocole par défaut utilisé par Managed Service for Prometheus pour l'extraction des données. L'exemple suivant illustre le format de représentation des métriques basé sur OpenMetrics.

# TYPE acme_http_router_request_seconds summary
# UNIT acme_http_router_request_seconds seconds
# HELP acme_http_router_request_seconds Latency though all of ACME's HTTP request router.
acme_http_router_request_seconds_sum{path="/api/v1",method="GET"} 9036.32
acme_http_router_request_seconds_count{path="/api/v1",method="GET"} 807283.0
acme_http_router_request_seconds_created{path="/api/v1",method="GET"} 1605281325.0
acme_http_router_request_seconds_sum{path="/api/v2",method="POST"} 479.3
acme_http_router_request_seconds_count{path="/api/v2",method="POST"} 34.0
acme_http_router_request_seconds_created{path="/api/v2",method="POST"} 1605281325.0
# TYPE go_goroutines gauge
# HELP go_goroutines Number of goroutines that currently exist.
go_goroutines 69
# TYPE process_cpu_seconds counter
# UNIT process_cpu_seconds seconds
# HELP process_cpu_seconds Total user and system CPU time spent in seconds.
process_cpu_seconds_total 4.20072246e+06
# EOF

La plupart des composants d'infrastructure de l'écosystème cloud-native peuvent exposer des métriques au format texte OpenMetrics. Pour les composants ne prenant pas nativement en charge ce format, la communauté Prometheus propose une riche collection d'exportateurs Prometheus. Ces composants (ou exportateurs) répondent aux requêtes d'extraction périodiques de Managed Service for Prometheus afin d'enregistrer leur statut opérationnel dans Managed Service for Prometheus pour une analyse ultérieure. Vous pouvez également utiliser les SDK multilingues de Managed Service for Prometheus pour instrumenter votre code et intégrer vos propres métriques métier dans l'écosystème Prometheus.

Data visualization and analysis

Après avoir collecté les métriques des applications et de l'infrastructure, interrogez, analysez et comparez des données multidimensionnelles pour comprendre l'état du système. Grafana, un outil open source leader en matière de visualisation de données, offre une large gamme de types de graphiques et de modèles. Managed Service for Prometheus fournit un service Grafana entièrement géré pour interroger, analyser et visualiser vos données de surveillance.

Timely alerting and incident management

Lorsqu'un service risque de tomber en panne, le système de surveillance doit notifier rapidement les administrateurs afin qu'ils puissent résoudre les problèmes ou les prévenir de manière proactive, minimisant ainsi l'impact sur l'activité. En analysant différentes métriques et les données historiques, les administrateurs identifient et résolvent les causes profondes des incidents.

Vue d'ensemble du processus d'intégration

Pour les applications Spring Boot, la communauté propose le framework Spring Boot Actuator, qui simplifie l'instrumentation du code, la collecte et la publication des métriques pour les développeurs Java. À partir de Spring Boot 2.0, Actuator a été reconstruit sur Micrometer, offrant des capacités de surveillance plus puissantes et flexibles. Micrometer est une façade de métriques, analogue à SLF4J pour la journalisation. Grâce à Micrometer, les applications peuvent se connecter à divers systèmes de surveillance, tels que AppOptics, Datadog, Elastic, InfluxDB et Managed Service for Prometheus.

Lors du mappage des métriques des applications Java, Micrometer utilise la sémantique suivante pour mapper ses types de métriques vers les types utilisés par Managed Service for Prometheus :

• Le type de métrique Counter de Micrometer correspond au type Counter dans Managed Service for Prometheus et sert à décrire une variable monotone croissante, telle que le nombre d'appels API, de hits de cache ou de visites totales. Un Timer inclut logiquement un Counter. Si vous utilisez un Timer pour collecter les temps de réponse d'une API, il collectera également le nombre d'appels. Par conséquent, il n'est pas nécessaire de spécifier à la fois un Timer et un Counter pour la même API.

• Le type de métrique Gauge de Micrometer correspond au type Gauge dans Managed Service for Prometheus et décrit une variable qui fluctue continuellement dans une plage donnée, comme l'utilisation du processeur ou le nombre de tâches dans la file d'attente d'un pool de threads.

• Le type de métrique Timer de Micrometer correspond au type Histogram dans Managed Service for Prometheus et sert à décrire des données liées au temps, telles que la distribution du temps de réponse (RT) d'une API.

• Le type de métrique DistributionSummary de Micrometer correspond au type Summary dans Managed Service for Prometheus. Semblable à un Histogram, un Summary est utilisé pour les distributions statistiques. Toutefois, comme la distribution est calculée côté client avant d'être envoyée à Managed Service for Prometheus pour stockage, les résultats Summary ne peuvent pas être agrégés sur plusieurs machines. Cela limite son utilisation, car il ne permet pas d'obtenir une vue globale de la distribution des données.

Integration workflow

Pour connecter une application Spring Boot déployée dans un cluster Kubernetes à Managed Service for Prometheus, suivez le processus suivant : instrumentation du code > déploiement de l'application > découverte de service.

Commencez par ajouter les dépendances Maven Spring Boot Actuator requises à votre code, puis enregistrez les métriques que vous souhaitez surveiller ou ajoutez des annotations aux méthodes de vos contrôleurs.

Ensuite, déployez l'application instrumentée dans Kubernetes et enregistrez l'endpoint de collecte des métriques auprès de Managed Service for Prometheus. Ce processus est connu sous le nom de service discovery. Managed Service for Prometheus fournit la découverte de service via la définition de ressource personnalisée (CRD) ServiceMonitor.

Enfin, une fois que Managed Service for Prometheus a découvert avec succès l'endpoint de métriques de l'application cible, configurez les sources de données et créez des tableaux de bord dans Grafana. Vous pouvez également configurer des alertes basées sur les métriques clés.

Objectifs de surveillance

En connectant une application Spring Boot dans un cluster Kubernetes à Managed Service for Prometheus, vous pouvez atteindre les objectifs suivants :

• Surveiller le point d'entrée du système : Suivez les métriques RED clés (Rate, Errors, Duration) pour les API externes sur un service frontal qui gère le trafic client.

• Surveiller les chemins système critiques : Observez les objets clés du chemin critique des services backend, tels que le statut de la file d'attente d'un pool de threads ou le taux de hit d'un cache Guava intégré.

• Surveiller les métriques personnalisées liées à l'activité : Mettez en œuvre la surveillance de métriques spécifiques à votre activité, telles que le nombre de visiteurs uniques pour une API particulière.

• Surveiller les performances de la JVM : Suivez le garbage collection (GC) et l'utilisation de la mémoire de la JVM.

• Centraliser la surveillance : Agrégez et affichez toutes les métriques précédentes sur un tableau de bord unifié et configurez des alertes pour les indicateurs clés.

Étape 1 : Configurer Spring Boot Actuator

Cette rubrique utilise une application de microservices native du cloud construite avec Spring Boot et Spring Cloud Alibaba pour démontrer comment connecter une application de microservices Spring Boot dans un cluster Kubernetes à Managed Service for Prometheus.

1. Ajoutez les dépendances Spring Boot Actuator à votre fichier pom.xml.

   <!-- spring-boot-actuator dependency -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>
   <!-- prometheus dependency -->
   <dependency>
       <groupId>io.micrometer</groupId>
       <artifactId>micrometer-registry-prometheus</artifactId>
   </dependency>

2. Dans le fichier application.properties, ajoutez la configuration suivante pour exposer le port des données de surveillance. Dans cet exemple, le port est 8091.

   # Add the following configuration to application.properties to expose metrics
   spring.application.name=frontend
   management.server.port=8091
   management.endpoints.web.exposure.include=*
   management.metrics.tags.application=${spring.application.name}

   Une fois la configuration réussie, accédez au port 8091 de l'application. Les données de surveillance au format OpenMetrics sont disponibles sur le chemin /actuator/prometheus de ce port.

Étape 2 : Instrumenter le code

Pour collecter les métriques RED d'une API, ajoutez l'annotation @Timed à la méthode correspondante. L'exemple suivant ajoute @Timed à l'API de la page d'accueil.

@Timed(value = "main_page_request_duration", description = "Time taken to return main page", histogram = true)
@ApiOperation(value = "Home page", tags = {"Home page operations"})
@GetMapping("/")
public String index(Model model) {
    model.addAttribute("products", productDAO.getProductList());
    model.addAttribute("FRONTEND_APP_NAME", Application.APP_NAME);
    model.addAttribute("FRONTEND_SERVICE_TAG", Application.SERVICE_TAG);
    model.addAttribute("FRONTEND_IP", registration.getHost());
    model.addAttribute("PRODUCT_APP_NAME", PRODUCT_APP_NAME);
    model.addAttribute("PRODUCT_SERVICE_TAG", PRODUCT_SERVICE_TAG);
    model.addAttribute("PRODUCT_IP", PRODUCT_IP);
    model.addAttribute("new_version", StringUtils.isBlank(env));
    return "index.html";
}

Si votre application utilise une bibliothèque de cache intégré telle que Guava Cache et que vous souhaitez suivre son statut d'exécution, encapsulez les objets clés à l'aide des méthodes de décoration de Micrometer.

Modifying the Guava cache

1. Injectez MeterRegistry. Spring Boot injecte automatiquement l'implémentation PrometheusMeterRegistry.

2. Encapsulez le cache local à l'aide d'une API utilitaire, qui est GuavaCacheMetrics.monitor dans le code suivant.

3. Activez l'enregistrement des statistiques du cache en appelant la méthode .recordStats().

4. Nommez l'objet cache pour générer les métriques correspondantes.

@Resource
private static MeterRegistry meterRegistry;
private static final LoadingCache<String, String> REFRESH_CACHE = GuavaCacheMetrics.monitor(
        meterRegistry,
        CacheBuilder.newBuilder()
                .recordStats()
                .build(new CacheLoader<String, String>() {
                    @Override
                    public String load(String key) {
                        // Implement the specific load operation here.
                        return "";
                    }
                }),
        "refresh-cache");

Modifying the thread pool

1. Injectez MeterRegistry. L'implémentation spécifique injectée ici est PrometheusMeterRegistry.

2. Encapsulez le pool de threads à l'aide d'une API utilitaire.

3. Nommez le pool de threads pour générer les métriques correspondantes.

@Resource
private static MeterRegistry meterRegistry;
private static final ScheduledExecutorService REFRESH_EXECUTOR = ExecutorServiceMetrics.monitor(
        meterRegistry,
        Executors.newScheduledThreadPool(1,
                new ThreadFactory() {
                        public Thread newThread(Runnable r) {
                            Thread thread = new Thread(r);
                            thread.setDaemon(true);
                            thread.setName("dubbo.outlier.refresh-" + thread.getId());
                            return thread;
                        }
                }),
        "refresh-executor"
);

Pour surveiller les métriques personnalisées spécifiques à l'activité, injectez MeterRegistry dans votre bean, puis construisez un Counter, un Gauge ou un Timer selon vos besoins. Enregistrez-le auprès du MeterRegistry pour exposer la métrique, comme illustré dans l'exemple suivant.

@Service
public class DemoService {
    Counter visitCounter;
    public DemoService(MeterRegistry registry) {
        visitCounter = Counter.builder("visit_counter")
            .description("Number of visits to the site")
            .register(registry);
    }
    public String visit() {
        visitCounter.increment();
        return "Hello World!";
    }    
}

Les modifications de code requises sont maintenant terminées. Reconstruisez l'image de l'application et déployez-la dans un cluster Kubernetes où Managed Service for Prometheus est installé. Ensuite, configurez un ServiceMonitor dans la console Managed Service for Prometheus pour activer la découverte de service. Pour plus d'informations, consultez Observabilité des conteneurs et gestion des instances.

Une fois le ServiceMonitor configuré, retrouvez l'application nouvellement enregistrée dans la liste Targets.

Sur la page Targets, si vous voyez default/frontend-service-monitor/0 (1/1 up) et que l'état est UP, cela indique que l'endpoint de métriques (chemin : /actuator/prometheus) fonctionne correctement et que la configuration ServiceMonitor est active.

Étape 3 : Configurer les tableaux de bord

Managed Service for Prometheus collecte et stocke désormais les données de surveillance de votre application. Configurez des tableaux de bord et des alertes pour visualiser les données. Les modèles de tableaux de bord communautaires Grafana open source suivants peuvent vous aider à construire votre propre tableau de bord de surveillance.

• Statistiques Spring Boot 2.1

• JVM (Micrometer)

En utilisant ces modèles et le service Grafana intégré de Managed Service for Prometheus, créez un tableau de bord qui regroupe les métriques clés pour le développement et les opérations quotidiennes sur une seule page. Par exemple, un tableau de bord construit à partir de ces modèles peut inclure une vue d'ensemble, les temps d'exécution des composants, l'utilisation de la mémoire, la mémoire heap et non-heap, ainsi que le statut du garbage collection générationnel.