Migration des métriques Grafana

Aperçu

Une prestation de services professionnels à prix fixe de 3 semaines calendaires qui migre un parc représentatif de métriques Grafana vers Elastic Observability selon une approche axée sur l’ingestion (parcours 1). Les métriques Prometheus arrivent d’abord dans Elastic, puis l’Observability Migration Platform (OMP) convertit les tableaux de bord Grafana inclus dans le périmètre et certaines règles d’alerte sélectionnées à partir de données réelles. Le périmètre est exprimé en unités quantifiables, et non en jours de conseil, afin que les limites soient lisibles pour les deux parties.

Parcours 1 axé sur l’ingestion : métriques ingérées dans Elastic avec une structure compatible avec PromQL au moyen de remote-write Prometheus, d’EDOT ou d’intégrations Elastic Agent → conversion OMP appliquée au projet Elastic en production → mise au point assistée des panneaux dans la limite convenue → évaluation des règles d’alerte dans la limite convenue → présentation côte à côte.

Portée

• Phase 1 : vérification des critères de démarrage, lancement du projet, approche d’ingestion convenue, liste restreinte d’alertes et durée impartie confirmées, confirmation après le lancement envoyée
• Phase 2 : évaluation de la scorecard OMP avec le client, inventaire des sources de données, sessions de découverte (architecture de collecte des métriques, systèmes nommés, contraintes réseau, responsabilité de l’alerting), plan d’ingestion du parcours 1, mapping système-configuration et liste restreinte d’alertes arrêtés par écrit
• Phase 3 : écriture à distance de Prometheus et/ou jusqu’à 6 configurations d’exemple EDOT/Elastic Agent déployées pour les systèmes convenus et nommément désignés, réexécution d’OMP et de --validate sur le projet Elastic du client après ingestion, tableaux de bord convertis téléchargés dans le Kibana du client, assistance à la mise au point des visualisations pour jusqu’à 15 panneaux assistés par OMP (remappage des filtres, corrections des noms de champs, ajustements de la structure des requêtes), évaluation des règles d’alerte pour jusqu’à 3 règles présélectionnées (adaptation d’une règle générée par OMP, équivalent natif Elastic ou clôture structurée accompagnée de recommandations écrites)
• Phase 4 : présentation comparative côte à côte des tableaux de bord Grafana convenus et de leurs équivalents dans Kibana, accompagnement (extension de l’ingestion, fonctionnement des tableaux de bord convertis), remise du backlog résiduel écrit
• Phase 5 : transfert complet des artefacts ; clôture du projet ; courriel de clôture

Limites de périmètre quantifiables (tous plafonds stricts) :

• Configurations d’exemple pour l’ingestion : jusqu’à 6 configurations EDOT/Elastic Agent et/ou endpoints d’écriture à distance Prometheus
• Mise au point assistée des panneaux : jusqu’à 15 panneaux assistés par OMP (plafond interne de prestation : 16 heures)
• Évaluation des règles d’alerte : jusqu’à 3 règles d’alerte (plafond interne de prestation : 8 heures)

Hors périmètre

Cette mission ne comprend pas :

• Déploiement de l’Agent sur l’ensemble du parc au-delà des 6 configurations d’échantillon (nécessite un avenant)
• Copie des données historiques Prometheus/Loki/Tempo
• Les panneaux dépassant le quota de 15 panneaux pris en charge — ceux-ci sont consignés dans le backlog résiduel documenté par écrit
• Règles d’alerte dépassant la limite d’évaluation de 3 règles, elles sont consignées dans le backlog résiduel écrit
• Remappage OTel des tableaux de bord du parcours 1 vers le parcours 2 (mission distincte)
• Reconstruction structurelle des panneaux qu’OMP classe comme Outside (les panneaux Outside ne sont pas décomptés du quota de 15 panneaux ; ils sont consignés dans le backlog résiduel)
• Sources de données autres que Prometheus (Loki, CloudWatch, InfluxDB, etc.), sauf si elles sont explicitement répertoriées dans le bon de commande
• Parité visuelle avec Grafana au pixel près
• Refonte du canal de notification de Grafana vers Kibana (circuit de notification minimal, uniquement pour la validation des alertes)
• Basculement de Grafana vers Kibana — le client continue à faire fonctionner Grafana en parallèle pendant toute la mission ; le basculement est une décision du client après la mission
• Ingestion des logs, APM/traçage ou RUM (disponibles dans le cadre de missions ultérieures)
• Déploiements multi-clusters ou multi-environnements au-delà du projet Elastic convenu

Toute prestation en dehors du champ d’application défini ci-dessus nécessite un ordre de modification signé par les deux parties (émis via le formulaire de commande). Tous les éléments du périmètre non traités dans les limites du forfait sont consignés dans le backlog résiduel écrit lors de la revue et ne constituent pas des manquements à la livraison.

Exigences du contrôle de démarrage

Les éléments suivants doivent être confirmés avant le début de la mission. Les travaux ne peuvent pas commencer tant que tous les éléments du contrôle de démarrage ne sont pas reçus et vérifiés :

1. Export JSON du tableau de bord Grafana — de l’échantillon représentatif convenu, dont la disponibilité pour la préévaluation OMP a été confirmée
2. Export JSON des alertes Grafana, couvrant le parc d’alertes convenu dans le périmètre
3. Sortie OMP/fiche de score Emplify, issue d’une exécution préalable à l’engagement, examinée avant la signature du contrat, la répartition entre Assisted et Outside doit être communiquée au client
4. Projet Elastic cible confirmé — ECH 9.5+ ou Observability Serverless répondant aux critères, avec remote-write Prometheus/PromQL natif (validation du SA requise)

Si les artefacts nécessaires à la validation des critères de démarrage ne sont pas disponibles lors de la réunion de lancement, le retard est consigné par écrit et imputé aux jours de conseil, conformément aux conditions du forfait à prix fixe.

Conditions et hypothèses relatives au prix fixe

• Le client dispose d’un projet Elastic existant (ECH 9.5+ ou Observability Serverless répondant aux critères) avant la réunion de lancement, le SA a confirmé la prise en charge de l’écriture à distance de Prometheus/de PromQL natif
• Les quatre éléments du contrôle de démarrage sont reçus et vérifiés avant le début de la mission
• L’exemple représentatif de tableau de bord et d’alerte est convenu et arrêté avant la réunion de lancement, les quotas (15 panneaux assistés et 3 règles d’alerte) ont été communiqués au client et acceptés par celui-ci avant la signature
• Un interlocuteur unique côté client, habilité à prendre des décisions, est confirmé avant le lancement
• Les métriques du client sont actuellement collectées via le scrape Prometheus, l‘écriture à distance, l’OTel Collector ou les intégrations Elastic Agent compatibles avec le parcours 1 (sources de données de la famille Prometheus)
• Le client fournit un accès réseau pour l’ingestion — aucun obstacle connu au chargement des métriques dans le projet Elastic cible ; les contraintes de sécurité, de proxy ou de certificat sont signalées avant le lancement
• Le client reste en double exécution (Grafana actif aux côtés de Kibana) pendant toute la mission ; aucun basculement de Grafana n’est prévu dans le cadre de ce package
• Les ressources techniques du client (ingénieurs en infrastructure/SRE) sont disponibles pour les sessions de découverte en semaine 1 et la présentation guidée en semaine 3
• La date de la présentation de la 3e semaine est confirmée lors de la réunion de lancement
• Les retards dus à l’indisponibilité du client, à l’absence d’accès, aux contraintes réseau non résolues ou à la remise tardive des artefacts sont imputés aux jours de conseil et peuvent affecter la livraison dans le délai de 3 semaines

Livrables

Lancement & planification

• Une (1) confirmation écrite post-lancement, documentant le périmètre convenu, l’approche pour ingérer les données, les plafonds de panneaux/alertes et la date de la présentation
• Un (1) parcours, un (1) plan d’ingestion, mapping des systèmes convenus et nommément désignés vers les configurations EDOT/Agent ou l’écriture à distance, consigné par écrit à l’issue de la découverte

Ingestion et validation (limitée aux systèmes nommément désignés convenus dans le plan d’ingestion du parcours 1)

• endpoint(s) d’écriture à distance Prometheus pour les systèmes identifiés d’un commun accord, déployé(s) et vérifié(s) dans le projet Elastic du Client 
• Jusqu’à six (6) configurations d’exemple d’EDOT/Elastic Agent pour les systèmes identifiés d’un commun accord, déployées et vérifiées dans le projet Elastic du client
• Une (1) sortie de réexécution OMP et les résultats de --validate, confirmant l’ingestion dans le projet Elastic du client après le déploiement

Tableaux de bord et visualisations

• Tableaux de bord Grafana inclus dans le périmètre, convertis et présents dans le Kibana du client, limités aux tableaux de bord recensés dans le plan d’ingestion du parcours 1 (1) (signaler ci-dessous, recommander un nombre précis)
• Mise au point assistée des visualisations appliquée à un maximum de quinze (15) panneaux assistés par OMP, limitée à : remappage des filtres, corrections des noms de champs et ajustements de la structure des requêtes (nombre de panneaux et type de mise au point appliquée documentés par panneau)

Alerting

• Jusqu’à trois (3) règles d’alerte évaluées, avec un résultat documenté pour chaque règle : règle émise par OMP ajustée/validée, équivalent natif d’Elastic créé, ou clôture structurée accompagnée de recommandations écrites

Présentation guidée et accompagnement

• Une (1) session de présentation comparative côte à côte, planifiée et dispensée en direct au Client, comparant les tableaux de bord Grafana convenus à leurs équivalents dans Kibana (signaler ci-dessous, « livré ou mis à disposition »)
• Un (1) document de notes d’accompagnement et de transfert de configuration portant sur l’extension de l’ingestion et le fonctionnement du tableau de bord converti

Clôture

• Une (1) liste écrite des éléments résiduels en attente, recensant les panneaux dépassant le quota de quinze (15) panneaux, l’ensemble des panneaux hors périmètre, les règles d’alerte dépassant le plafond de trois (3) règles et tout élément non migrable, avec, pour chacun, une approche recommandée et une catégorie d’effort
• Un (1) document de recommandations de suivi (à signaler ci-dessous — chevauche le backlog résiduel)
• Transfert complet des artefacts : exports, sortie OMP, configurations, références de tableaux de bord, résultats d'alerte, et backlog résiduel
• Un (1) courriel de clôture, confirmant l’achèvement du projet et le transfert des artefacts

Complétion

La mission sera considérée comme achevée lorsque : tous les livrables prévus dans le périmètre auront été produits, la présentation guidée aura été réalisée ou mise à la disposition du client, et le backlog résiduel écrit aura été remis. Elastic peut déclarer l’achèvement dès le transfert des artefacts, indépendamment de la décision ultérieure du client concernant le basculement depuis Grafana. La non-participation du client à la présentation guidée n’empêche pas l’achèvement dès lors qu’Elastic a mis cette présentation guidée à disposition.

Complétion

La mission sera considérée comme achevée dès la remise du rapport final de mission et la réalisation de l’atelier de transfert de connaissances.

Conditions générales

Les termes commençant par une majuscule qui sont utilisés, mais non définis, dans la présente description de package ont le sens qui leur est attribué dans le Bon de commande, la Description de service applicable ou le Contrat de services Elastic.

Aucune approbation formelle du Client ni aucun processus d’acceptation des jalons ou des livrables ne s’applique à ce forfait de services à prix fixe. Chaque Service est réputé accepté dès son achèvement.

« Achèvement » désigne, pour un Service, le moment où Elastic a exécuté l'ensemble des activités comprises dans le périmètre du présent Forfait de Services, y compris (le cas échéant) la remise de tout rapport écrit, support ou session de transfert de connaissances décrit dans ledit périmètre, ou l'expiration de la période définie pour cette prestation, selon la première de ces échéances. L’achèvement ne nécessite ni approbation du Client ni acceptation d’un quelconque livrable.

Le Client est seul responsable de la sauvegarde, de la maintenance, et de la sécurité de son environnement, de ses systèmes, et de ses données. Elastic n’est pas responsable des modifications de configuration, des pertes de données, de l’indisponibilité, ou de tout autre impact sur l’environnement du Client découlant du Service, ou lié à celui-ci.

Cette mission fournit une solution configurée et auto-gérée .NET de recherche de documents Elastic inédite, comprenant l'analyse du cas d'usage de recherche, le design et l'ingestion du modèle de données, le développement de requêtes d'exemple avancées, la configuration RBAC avancée, le déploiement de l'infrastructure ainsi qu'un rapport final, le tout dans les limites du périmètre au forfait défini. Elastic ne garantit aucun résultat particulier en matière de performances, de coûts, d’exploitation ou de résultats commerciaux au-delà des livrables définis ci-dessus. Le Client reste seul responsable des opérations courantes, des modifications de configuration effectuées en dehors du périmètre de la prestation, ainsi que de toutes les activités postérieures à la prestation liées à son environnement.

Les références faites dans ce forfait à la validation, aux tests, aux tests de recette ou bancs d'essai de recette, aux requêtes de référence, à la préparation au lancement ou au passage en production décrivent des activités réalisées, démontrées ou fournies par Elastic et ne constituent en aucun cas une condition de recette, d'approbation, de test ou de paiement pour le Client. L'Achèvement intervient selon les modalités définies dans le présent forfait, indépendamment de toute activité de ce type, et aucune fraction des honoraires ne peut être retenue ou différée dans l'attente du résultat d'un test, d'une validation ou d'un passage en production.