Données éparses, mesures manquantes et lacunes dans les données

Problème

Vous avez installé l' intégration Prometheus OpenMetrics pour Docker ou Kubernetes, mais vous remarquez des données éparses, des métriques manquantes et des lacunes de données dans l'interface utilisateur de New Relic.

Solution

Si certaines mesures ne sont pas collectées régulièrement, procédez comme suit :

1. Vérifiez si le processeur est limité et si la mémoire allouée au conteneur est suffisante.

   Si le conteneur ne dispose pas de suffisamment de ressources disponibles, il peut envoyer des données avec un intervalle plus long entre les échantillons. Une limite de mémoire faible peut entraîner l'arrêt et le redémarrage de l'intégration. Les limites et requests de ressources correctes peuvent varier en fonction du nombre de cibles monitorées et du nombre de métriques exposées par chaque cible. Pour plus d'informations, consultez les directives de la documentation configuration de l'environnement de grande taille.

2. Vérifiez le message d'erreur suivant dans le log de l'intégration :

   { "err": "unexpected post response code: 413: Request Entity Too Large" }

   Copier

   Ce problème entraîne la perte de certaines charges et il est actuellement résolu dans une nouvelle sortie. Si présent, mettez à jour l'image vers la version la plus récente.

3. Si certains points de terminaison /metrics monitorés par l'intégration expirent ou prennent plusieurs secondes pour répondre, ils peuvent ralentir le scraping des données. Les performances de l'intégration peuvent se dégrader si plusieurs points de terminaison mettent énormément de temps à répondre. Cela conduit à des données intermittentes et manquantes.

   Pour détecter ces points de terminaison, exécutez :

   SELECT average(nr_stats_integration_fetch_target_duration_seconds) 
   FROM Metric where clusterName=’clustername' SINCE 30 MINUTES AGO FACET target LIMIT 30

   Copier

   Cette requête récupère les données exposées par l'intégration Prometheus OpenMetrics et affiche le temps nécessaire pour récupérer chaque point de terminaison.

   Corrigez le point de terminaison avec une latence supérieure à 1s, ou excluez-les de la monitoring en supprimant l'étiquette de scraping Prometheus .

4. S'il n'est pas possible de supprimer ces points de terminaison et que la latence dans la réponse ne peut être évitée, configurez l'intégration pour exécuter davantage de travailleurs en parallèle. Cela permet à l’intégration d’extraire plus de points de terminaison en même temps.

   Pour ce faire, mettez à jour l’intégration vers la version la plus récente et appliquez la nouvelle option de configuration worker_threads. Nous conseillons de le faire progressivement, à partir de 4, 6, 8 et jusqu'à 16.

   Cette solution de contournement ne fait que minimiser le problème, et si plusieurs points de terminaison se comportent mal, les performances seront toujours dégradées. De plus, la consommation de mémoire et de CPU augmentera avec le nombre de travailleurs, la mémoire et le CPU doivent donc être augmentés en conséquence.

5. Si tous les points de terminaison du moniteur ont une faible latence et que le conteneur n'est pas limité, exécutez la requête suivante. Cela vous aide à vérifier combien de temps l'intégration prend pour extraire toutes les cibles et pour envoyer les données si elles dépassent le scrape_duration configuré.

   SELECT latest(nr_stats_integration_process_duration_seconds) FROM Metric
   where clusterName=’clustername' SINCE 30 MINUTES AGO TIMESERIES

   Copier

   Tout d’abord, mettez à jour l’intégration avec la dernière image publiée. Ensuite, pour réduire le temps nécessaire pour scraper toute la cible, augmentez le nombre de workers avec l'option configuration worker_threads. Nous conseillons de le faire progressivement, de 4 à 6, 8, et jusqu'à 16 jusqu'à ce que r_stats_integration_process_duration_seconds se rapproche du scrape_duration défini. Notez que la consommation de mémoire et l’utilisation du processeur augmenteront.