|
Splunk |
Datadog |
Analyse des logs |
Splunk ingère, indexe et stocke automatiquement tout fichier lisible par l’homme, quelle que soit sa source. Les métriques et l’intégralité des traces sont automatiquement corrélées aux logs, ce qui permet aux équipes de localiser et de résoudre rapidement les problèmes. Nous avons fait nos preuves en matière d’indexation et de recherche à grande échelle sur les données d’entreprise. Nos solutions mettent au jour les éléments connus et inconnus pour que les équipes d’ingénierie et d’ITOps trouvent ce dont elles ont besoin, quand elles en ont besoin. |
Le dépôt de données de Datadog n’a pas la flexibilité de Splunk et se concentre principalement sur le stockage de séries chronologiques de métriques et des logs d’applications. Contrairement à ce que permet Splunk, les utilisateurs doivent faire un choix entre coût et performance pour les recherches, ce qui prolonge le MTTR lorsque les ingénieurs rencontrent des problèmes imprévus. Le résultat : des interruptions prolongées et des frais imprévus lorsqu’il faut réindexer les logs afin d’améliorer les requêtes après coup. |
Détection et alertes |
Les collecteurs Splunk Observability Cloud diffusent des données granulaires d’une seconde toutes les 2 à 3 secondes, ce qui permet de créer des visualisations, de détecter les problèmes et de générer des alertes en quasi temps réel. Cette vitesse améliore le MTTR et l’expérience du consommateur, et elle réduit la frustration des ingénieurs et des responsables métiers. |
Les agents de Datadog interrogent les données de télémétrie APM toutes les 60 secondes. Le stockage, le traitement et la visualisation de la télémétrie prennent plus de temps. Ce retard entraîne une augmentation du MTTR, un ralentissement de la détection et des alertes et une dégradation de l’expérience pour les ingénieurs et responsables métiers. |
Conservation et intégration des données |
La traçabilité NoSampleTM de Splunk conserve toutes les traces, sans risque de stocker des traces redondantes. La gestion du pipeline de métriques facilite la transformation, l’édition et la suppression des données afin de trouver le bon équilibre entre coûts et performances. Nous prenons également en charge la recherche fédérée dans AWS S3, afin de réduire les coûts tout en conservant la fonctionnalité de recherche. Le résultat ? Vous disposez de toutes les données dont vous avez besoin pour isoler les problèmes rapidement et facilement, tout en gardant un contrôle total sur les coûts. |
Datadog conserve 100 % des données de trace pendant les 15 premières minutes, après quoi les utilisateurs sont obligés d’échantillonner les traces.8 Cela peut retarder certaines alertes et ralentir le dépannage, parce que les ingénieurs doivent attendre que la plateforme capture les traces suspectes. Il manque au pipeline de Datadog les capacités de routage robustes dont dispose Splunk. Ses transformations sont moins flexibles et parviennent difficilement à expurger les données sans modifier la source sous-jacente. Les clients sont encouragés à « déshydrater » les données, ce qui augmente les coûts et complique la tâche des ingénieurs quand ils doivent rechercher et isoler des problèmes. |
Expérience de dépannage |
Splunk identifie l’impact commercial des problèmes de performances qui englobent plusieurs services et équipes. Nous corrélons les métriques, les logs et les traces au sein de visualisations cohérentes et claires, associées à des seuils d’alerte dynamiques enrichis par IA. Splunk permet d’élaborer très facilement des requêtes de recherche à partir de n’importe quel élément de données grâce à de vastes bibliothèques de suggestions et à des logs entièrement indexés. Splunk IT Service Intelligence offre une visibilité sur la santé de l’entreprise et ses liens avec celle des actifs et des services informatiques. Les utilisateurs localisent et résolvent les problèmes plus rapidement avec Splunk. |
Dans les scénarios complexes, les capacités de dépannage de Datadog ne sont pas aussi robustes. La collecte limitée de traces complètes et la longueur de la période d’apprentissage empêchent les ingénieurs d’utiliser des seuils d’alerte dynamiques pour investiguer les problèmes imprévus. Ils sont contraints de régler manuellement les alertes pour parvenir à la source des problèmes. L’analyse de logs repose sur à une combinaison de balises définies automatiquement et par l’utilisateur. En l’absence de balises, les utilisateurs ont recours à des requêtes d’attributs potentiellement lentes. Les vues métiers ne prennent pas en charge les données tierces et ne peuvent pas être aussi finement personnalisées que ne le permet Splunk. |
Prise en charge d’OpenTelemetry |
Splunk Observability Cloud intègre nativement OpenTelemetry et Splunk contribue activement au projet. Les utilisateurs de Splunk peuvent, en toute confiance, collecter les données OpenTelemetry, les traiter, les transformer, les visualiser et s’en servir de base pour créer des alertes, sans s’inquiéter des exceptions et des contraintes spécifiques à OpenTelemetry. Ils ont la possibilité de contribuer directement à la communauté et de profiter pleinement des avantages d’OpenTelemetry. |
La documentation OpenTelemetry de Datadog comporte des erreurs et fait perdre du temps aux utilisateurs qui doivent corriger les exemples de code avant de pouvoir les comprendre. Son traçage OpenTelemetry ne prend pas en charge les événements de span et les utilisateurs ne peuvent pas relier les traces et les logs en modifiant manuellement leur propre module ou bibliothèque de logging. Les données de logging et de traces sont conservées séparément : il est donc impossible de les corréler, et les utilisateurs ne peuvent pas interroger les données de span sous forme de métriques dans leur tableau de bord. |