Envoi de données au moyen de Logstash ou de Kafka à partir d'Elastic APM

Dans le cadre des déploiements modernes, les serveurs d'application ont généralement une courte durée de vie ou utilisent du matériel moins fiable (des VM non prioritaires ou des instances spot) que d'autres composants, tels que les files d'attente de messages ou les bases de données. Dans de tels cas, il est préférable de transférer rapidement les données vers un système plus fiable.

À compter de la version 6.4.0, les serveurs APM sont capables d'envoyer des données par l'intermédiaire de Logstash et de Kafka. Vous pouvez ainsi déléguer les exigences de fiabilité à l'un de ces systèmes. En utilisant Logstash, bénéficiez également de la possibilité d'enrichir vos données APM avec l'un des nombreux plug-ins Logstash.

Explorons le processus de configuration et examinons quelques avertissements liés à l'envoi de données au moyen d'un autre système avant l'ingestion par Elasticsearch.

  1. Configuration de Logstash pour alimenter Elasticsearch
  2. Configuration d'un serveur Elastic APM pour effectuer des envois vers Logstash
  3. Configuration d'Elasticsearch
  4. Insertion facultative de source maps
  5. Introduction de Kafka

Configuration de Logstash

Ajoutez d'abord un pipeline pour configurer Logstash et permettre à ce dernier de recevoir des événements à partir d'un serveur APM à l'aide du protocole Beats ou Lumberjack, puis envoyez-les à Elasticsearch.

input {
   beats {
        id => "apm-server"
        port => 5044
  }
}
output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "apm-%{[beat][version]}-%{[processor][event]}-%{+YYYY.MM.dd}"
  }
}

Un index est créé par jour et par type d'événement (transaction, durée, etc.) tout comme celui que la configuration du serveur APM par défaut aurait généré. Les source maps introduisent ici une nouveauté que nous étudierons par la suite dans cet article.

Vous vous interrogez peut-être sur la présence des références à Beats. Les serveurs APM utilisent l'architecture Beats et transmettent donc les mêmes métadonnées avec les événements. Cela signifie qu'il est possible de traiter les données APM dans la même instance Logstash que d'autres données Beats en appliquant une condition à [@metadata][beat] == "apm-server".

Configuration d'un serveur APM

Maintenant que Logstash est configuré, mettez à jour le fichier "apm-server.yml" du serveur APM pour produire les événements comme il convient :

output.elasticsearch:
  enabled: false
output.logstash
  enabled: true
  hosts: ["logstash:5044"]

D'autres options, y compris les paramètres d'interruption, de proxy et SSL, sont détaillées dans la documentation des serveurs Elastic APM.

Si le monitoring est activé dans le serveur APM, réglez vos paramètres comme suit :

xpack.monitoring.elasticsearch:
  enabled: true
  hosts: ["elasticsearch:9200"]

Cela permettra au monitoring du serveur APM de transiter directement vers Elasticsearch.

Configuration d'Elasticsearch

Il ne reste plus qu'une étape à suivre avant de lancer le serveur APM. Elasticsearch doit d'abord savoir stocker les données APM conformément aux attentes de l'interface utilisateur d'APM. Un modèle d'index est nécessaire. Ce modèle peut être chargé de deux façons.

Si vous êtes en mesure de diriger temporairement un serveur APM vers Elasticsearch, procédez comme suit :

 apm-server setup --template

Sinon, exportez d'abord le modèle à partir du serveur APM :

apm-server export template > apm-6.4.2.tmpl.json

Chargez-le ensuite dans Elasticsearch. Avec curl, vous pouvez procéder de la façon suivante :

curl -XPUT -H 'Content-Type: application/json' http://elasticsearch:9200/_template/apm-6.4.2 -d @apm-6.4.2.tmpl.json

Chacune des opérations devrait indiquer si elle a réussi ou échoué. Pour vous assurer du bon chargement du modèle, recherchez _template/apm-*. Cela devrait renvoyer un ensemble de documents semblable à ce qui suit :

{
  "apm-6.4.2": {
    "order": 1,
    "index_patterns": [
      "apm-6.4.2-*"
    ],
...

Notez que le modèle d'indexation correspond au modèle configuré dans Logstash. Vous pouvez aussi constater qu'il inclut les informations de version. Cela signifie que cette étape de configuration doit être effectuée :

  1. avec une version de serveur APM identique à celle qui se connecte à Logstash ;
  2. à chaque mise à niveau du serveur APM.

Utilisez-le

Démarrez le serveur APM et commencez à analyser le comportement de votre application.

Source maps

Les source maps servent à mapper du code brouillé vers ses sources d'origine. Ils sont le plus souvent utilisés pour revenir sur du code JavaScript minifié.

Les source maps requièrent un examen spécial lorsque la sortie du serveur APM n'est pas destinée à Elasticsearch. Quelle que soit la façon dont ils atteignent Elasticsearch, ils doivent être stockés pour permettre au serveur APM de les utiliser. Pour configurer le stockage des source maps, configurez "rum.source_mapping.elasticsearch" comme suit :

apm-server:
  rum:
    source_mapping:
      elasticsearch:
        hosts: ["elasticsearch:9200"]
        index_pattern: "apm-*-sourcemap*"

Cela indique au serveur APM de rechercher les source maps dans les index qui correspondent à "apm--sourcemap".

Bien que les source maps puissent être chargées avec Logstash, nous recommandons de les envoyer directement à Elasticsearch lors du processus de déploiement pour qu'elles soient stockées avant que tout événement ne requière un mappage. Si cela n'est pas faisable, la configuration Logstash indiquée dans cet article correspond au modèle d'indexation par défaut utilisé, le cas échéant, pour extraire les source maps. Vous n'avez donc rien à modifier.

Introduction de Kafka dans le flux

Kafka permet aussi de mettre en mémoire tampon les événements provenant du serveur APM pour être transmis à Elasticsearch. Voici une simple configuration de serveur APM avec Kafka :

output.kafka:
  enabled: true
  hosts: ["kafka:9092"]
  topics:
    - default: 'apm'
      topic: 'apm-%{[context.service.name]}'

Cet exemple utilise un sujet par service, mais cela n'est pas obligatoire. D'autres options de configuration sont décrites dans la documentation.

Une fois que les événements passent par Kafka, vous pouvez configurer Logstash pour les transmettre à Elasticsearch. Par exemple :

input {
  kafka {
    id => "apm-server-kafka"
    bootstrap_servers => ["kafka:9092"]
    topics_pattern => "apm.*"
    codec => "json"
  }
}
output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "apm-%{[beat][version]}-%{[processor][event]}-%{+YYYY.MM.dd}"
  }
}

Un index est à nouveau créé par jour et par type d'événement (transaction, durée, etc.) tout comme celui que la configuration du serveur APM par défaut aurait généré. D'autres options du plug-in Logstash Kafka sont décrites dans la documentation.

Faites un essai.

Le serveur APM offre la flexibilité nécessaire pour transmettre des données APM avec Logstash ou Kafka. Faites un essai et partagez vos commentaires dans notre forum de discussion. Vos contributions nous intéressent, alors n'hésitez pas à consulter notre code source et à signaler un problème ou à proposer des contributions avec la fonction Pull request.