Dans Didi, les données métriques de la plate-forme observable ont certaines exigences informatiques en temps réel, et ces exigences informatiques en temps réel sont supportées par des ensembles de tâches Flink. La raison pour laquelle il existe plusieurs ensembles de tâches Flink est que chaque service nécessite des calculs d'indicateurs différents en fonction de ses observations métier, ce qui correspond également à différentes topologies de traitement des données . Nous faisons de notre mieux pour résumer les mêmes besoins informatiques des utilisateurs, mais en raison des limitations du modèle de développement de tâches informatiques en temps réel et du cadre informatique en temps réel de Flink, la conception de ces tâches informatiques d'indicateurs d'observation n'est pas suffisamment universelle. En utilisant Flink pour le calcul en temps réel des indicateurs de métriques, la maintenance de plusieurs ensembles de tâches Flink se heurte aux problèmes suivants :
Les capacités générales de calcul des métriques qui auraient dû être résumées ont été construites à plusieurs reprises et sont de qualité mitigée et ne peuvent pas être accumulées.
La logique de traitement est codée en dur de manière aléatoire dans le code de la tâche de streaming et est difficile à mettre à jour et à maintenir.
La version, l'extension et la réduction de Flink nécessitent le redémarrage des tâches, ce qui entraînera des retards de sortie des indicateurs, des points d'arrêt et des erreurs.
La plate-forme Flink est relativement coûteuse, représentant une grande partie de nos factures internes, et il existe une certaine pression sur les coûts.
Afin de résoudre ces problèmes, nous avons développé un ensemble de moteurs de calcul temps réel : observer-compute (OBC en abrégé). Ce qui suit est une introduction à l'implémentation d'OBC.
Objectifs de conception
Au début du projet, les objectifs de conception déterminés par OBC étaient les suivants :
1. Créer un moteur de calcul universel en temps réel dans le domaine du calcul des indicateurs de métriques . Ce moteur présente les caractéristiques suivantes :
Conformément aux normes de l'industrie : utilisation de PromQL comme langage de description pour les tâches de traitement de flux
Gestion et contrôle flexibles des tâches : les stratégies sont configurées, les tâches informatiques prennent effet en temps réel et le plan d'exécution peut être intervenu manuellement
Traçabilité des liens informatiques : capable d'atteindre une traçabilité au niveau politique des résultats de calcul
Conteneurisation native du cloud : le déploiement de la conteneurisation du moteur permet une expansion et une contraction dynamiques sans temps d'arrêt.
2. Le produit peut répondre à tous les besoins de calcul d'indicateurs métriques de la plate-forme observable, remplacer les tâches de calcul répétées, réduire les coûts et augmenter l'efficacité, et remodeler les liens de collecte, de transmission et de calcul d'observations.
Actuellement, à l'exception de la fonctionnalité de calcul de la traçabilité des liens, toutes les autres fonctionnalités du moteur ont été implémentées. OBC fonctionne de manière stable en ligne depuis plus de plusieurs mois. Plusieurs ensembles de tâches informatiques Flink au cœur de la plate-forme observable ont été migrés vers OBC. On s'attend à ce que les tâches migrées permettent d'économiser un coût cumulé de 1 million de yuans pour l'observable. plateforme d’ici la fin de l’année.
Architecture du moteur
L'architecture du moteur est illustrée dans la figure ci-dessus et est divisée en trois composants : obc-ruler est le composant de contrôle du moteur, qui fournit des capacités d'enregistrement et de découverte de services pour d'autres composants du moteur. Il est également responsable de l'accès aux stratégies informatiques et contrôle des plans d'exécution. obc-distributor ingère les indicateurs Metrics de la file d'attente de messages Metrics, correspond à la stratégie de calcul et transmet les données à obc-worker conformément au plan d'exécution de la stratégie. obc-worker est le composant du moteur qui est réellement responsable des calculs. Il est chargé d'effectuer les calculs des indicateurs conformément au plan d'exécution et de fournir les résultats des calculs vers un stockage persistant externe.
discussion sur la convivialité
Avant de présenter en détail la logique de base de chaque composant, commençons par présenter nos réflexions et nos compromis sur la convivialité, ainsi que quelques concepts introduits pour atteindre les objectifs de convivialité. Cette partie de la discussion aidera à comprendre la logique de base de chaque composant.
réflexion sur la convivialité
Les exigences en matière de disponibilité des données dans les scénarios informatiques en temps réel peuvent être divisées en exigences en temps réel et exigences en matière de précision , qui nécessitent des données à faible latence et de haute précision. La précision peut être décrite comme de bonnes données et aucune perte. L’exigence que les données soient bonnes est ce que j’appelle l’exigence d’exactitude, et l’exigence que les données ne soient pas perdues est ce que j’appelle l’exigence d’intégrité.
Pour les données d’observation des entreprises, du point de vue des résultats finaux, il convient également de discuter de la disponibilité sous les trois angles ci-dessus :
En temps réel : il ne devrait pas y avoir de retard important dans le stockage des données.
Précision : les données stockées doivent refléter avec précision l'état du système.
Intégrité : les données déposées dans le stockage ne peuvent comporter aucun point ou point d'arrêt manquant.
Le processus simple de traitement des données d’observation peut être simplifié comme suit : collecte => stockage. Ce qui est collecté dans un tel processus est ce qui est collecté, et il n’est pas nécessaire de discuter de l’exactitude des données. Parmi les deux exigences de temps réel et d'intégrité, afin de réduire la complexité de mise en œuvre et les frais d'exploitation du système, l'approche générale consiste à garantir le temps réel et à sacrifier l'intégrité.
Les scénarios dans lesquels les données d'observation participent aux calculs en temps réel seront plus complexes que les scénarios ordinaires, et l'exactitude des données devra être discutée plus en détail. Notre flux de données interne depuis observe-agent (fin de la collecte) => mq => obc-distributor => obc-worker => stockage persistant, en partant du principe que le délai de distribution des données dans la même fenêtre de calcul atteignant obc-worker satisfait aux Dans cette hypothèse, au moins une fois la sémantique depuis la fin de la collecte jusqu'à obc-worker doit être garantie, et la logique de déduplication des données et d'intégrité de la fenêtre de calcul doit être implémentée sur obc-worker pour garantir des résultats précis. Pour nous, tant le coût de conception et de mise en œuvre que le coût des ressources informatiques supplémentaires pour garantir la précision sont légèrement plus élevés. Et lorsque nous utilisons Flink pour calculer les indicateurs de métriques, nous ne pouvons pas garantir que les données de sortie finales seront exactes. Par conséquent, OBC a également fait certains compromis nécessaires dans la conception de la solution. Résultats du calcul, nous faisons de notre mieux pour garantir les résultats du calcul . Cela ne fera que briser les points (exhaustivité) et ne fera pas d'erreurs (précision), mais cela ne promet pas que les données produites seront exactes.
conception de convivialité
Tout d'abord, nous introduisons un concept appelé temps de basculement. La signification du basculement est commutation. Ce concept est emprunté à m3aggregator. Dans OBC, l'heure de basculement sera définie sur une heure ultérieure à l'heure à laquelle la configuration change comme heure effective réelle de la configuration, de sorte que le distributeur obc et le travailleur obc aient plusieurs opportunités de se synchroniser avec la même configuration avant la modification. la configuration prend réellement effet. Le concept de temps de basculement est introduit ici initialement car lorsque obc-distributor transmet des données à obc-worker, il sélectionnera l'instance de travailleur vers laquelle elle doit être transférée sur l'anneau de hachage formé par obc-worker. , le travailleur Lorsque le hachage constitué change, un problème surviendra : si le changement prend effet immédiatement, alors obc-distributor percevra que le processus de changement de hachage est séquentiel, et il y aura une incohérence à court terme dans l'anneau de hachage du travailleur qui prend effet dans le cluster de distributeurs. La configuration sera configurée via le basculement. Retarder le temps d'effet réel peut donner au distributeur plus de temps pour détecter les changements de configuration. Une conception d’utilisabilité plus spécifique est divisée en les points suivants :
1. Obc-worker plante, dérive et redémarre, provoquant au maximum trois points d'arrêt dans certaines courbes, sans aucun point d'erreur.
Il existe un mécanisme de synchronisation des battements de cœur entre le travailleur et le dirigeant, qui est synchronisé toutes les 3 secondes.
Le distributeur synchronise le hachage du travailleur de la règle avec une fréquence de sonnerie de 3 secondes.
La règle complète la logique de mise à jour de la version de l'anneau de hachage en fonction du statut du travailleur. Un basculement est une version et la version historique est conservée jusqu'à 10 minutes.
Jugement du dirigeant sur la mort d'un travailleur : le rythme cardiaque n'a pas été mis à jour depuis 8 secondes, ou le dirigeant appelle activement l'interface pour se déconnecter.
Temps de retard de propagation pour l'anneau de hachage : 8 s
2. La dérive et le redémarrage du distributeur obc ne provoqueront pas de points d'arrêt de courbe ou de points erronés.
obc est déployé sur notre plate-forme cloud interne. Notre plate-forme cloud interne dispose de certaines capacités de prise en charge pour un redémarrage progressif : la dérive et le redémarrage du conteneur enverront un signal SIGTERM au processus métier. Le distributeur écoutera ce signal et fera deux choses après avoir reçu le signal :
Arrêtez de consommer depuis MQ
Les points de données de métriques, les points de données dans le cache qui n'ont pas encore été envoyés au travailleur seront envoyés dès que possible.
3. Les paniques du distributeur Obc et le nœud physique où il se trouve peuvent provoquer des points d'arrêt et des erreurs.
Dans ce cas, le distributeur n'a aucune chance de gérer les conséquences : une partie des données mises en cache dans la mémoire et qui n'ont pas encore été envoyées au travailleur est perdue, ce qui entraînera des erreurs dans les résultats de calcul.
Quel est l’impact de cette situation sur les utilisateurs ? Notre ancien lien de calcul de métriques observe-agent (fin de collecte) => mq => router => kafka => flink. Le module routeur dans le lien entreprend une partie du travail similaire au distributeur. Il a également le même problème et fonctionne depuis tant d'années. Il semble que la perception des utilisateurs ne soit pas évidente
4. L'exigence de précision des résultats de l'indicateur est qu'il n'y aura pas de points d'arrêt ni d'erreurs lors de la mise à jour des stratégies dans un délai de 60 secondes ou moins.
Une fois que la mise à jour de la stratégie prend effet dans le cluster, des erreurs à court terme se produiront si la stratégie n'est pas synchronisée. Afin de résoudre ce problème, le concept de temps de basculement est également introduit dans la stratégie. Le temps de basculement est aligné sur 60 secondes. .
Introduction à chaque composant
règle obc
Le module de règle a deux fonctions principales : l'enregistrement/la découverte de services et la gestion des politiques, comme le montre la figure suivante :
La construction des capacités d'enregistrement/découverte des services est divisée en trois couches. La couche abstraite kv et les couches kv de liste de membres utilisent la bibliothèque tierce grafana/dskit. Cette bibliothèque prend en charge divers kv tels que consul et etcd sous la couche abstraite kv. Nous avons finalement Nous avons choisi d'utiliser la liste de membres kv pour construire la cohérence finale kv basée sur la capacité de synchronisation des données fournie par le protocole gossip. La raison en est que nous espérons que l'observable lui-même devrait réduire autant que possible les dépendances externes pour éviter de compter sur des composants externes pour fournir capacités d'observation, et ces composants externes s'appuient sur nos capacités d'observation pour assurer leur stabilité, ce qui est un problème de dépendance circulaire. L'explication directe du battement de cœur et du hachage de la couche supérieure réside dans les deux clés enregistrées sur le magasin kv et dans la logique de fusion des conflits qui les prend en charge. La clé de pulsation stocke des informations telles que l'adresse du travailleur, l'heure d'enregistrement, la dernière heure de pulsation, les jetons de hachage attribués au travailleur, etc., tandis que la clé de hachage stocke les anneaux de hachage du travailleur de plusieurs versions de basculement.
Le module de gestion des politiques est divisé en quatre couches. La couche la plus basse est constituée de divers chargeurs, qui sont responsables du chargement des configurations à partir de sources de politiques externes. La figure répertorie les chargeurs de politiques informatiques de plusieurs de nos produits les plus importants. Pour les tâches informatiques existantes, afin de migrer OBC, nous personnaliserons un analyseur pour convertir les stratégies informatiques. Pour les nouvelles tâches informatiques, nous aurons besoin d'une utilisation unifiée de PromQL pour décrire ses exigences informatiques et utiliser l'analyse de l'analyseur PromQL. Le plan d'exécution produit par l'analyseur est un arbre, et l'optimiseur fera quelques optimisations sur le plan d'exécution. En fait, il ne s'agit actuellement que d'une simple fusion de certains opérateurs. Le gestionnaire multiversion effectue la planification globale des mises à jour des politiques et interdit les politiques anormales.
distributeur obc
La fonction principale du module de distribution est de corréler les stratégies de calcul et la transmission des points de données Metrics.
Le travail effectué ici dans la correspondance de stratégie consiste à filtrer les points de données en fonction de l'étiquette spécifiée et à étiqueter les points de données filtrés avec l'ID de la stratégie correspondante. L'un de nos plus grands clusters informatiques OBC en ligne a un volume d'entrée de près de 1 000 W/s et le nombre de politiques informatiques efficaces est de 1,2 W. La quantité de données est en effet trop importante, donc afin d'améliorer l'efficacité du filtrage, nous avons a apporté certaines restrictions sur les politiques efficaces : Le filtrage des politiques doit contenir deux étiquettes, __name__ et __ns__, et ces deux étiquettes ne peuvent pas utiliser de correspondance régulière. __name__ est le nom de l'indicateur et __ns__ signifie espace de noms, qui représente le cluster de services auquel l'indicateur est signalé. Nous nous appuyons sur ces deux labels pour construire un index à deux niveaux afin d'améliorer l'efficacité de l'appariement des politiques.
L'action de réétiquetage consiste à ajouter/supprimer/modifier les étiquettes des points de données en fonction des exigences de la politique. En termes de syntaxe de configuration, afin d'unifier la description, nous traitons ces règles dans des fonctions PromQL et limitons les paramètres vectoriels de ces fonctions à un seul sélecteur ou autre fonction de relabel. L'action de mappage est similaire à la jointure de table de dimension dans d'autres flux informatiques. Elle est le produit d'un compromis afin d'accéder aux tâches informatiques existantes et ne sera pas présentée en détail.
Le processus de sélection des travailleurs :
Temps d'alignement du point de données event_time : align_time = event_time - event_time % de résolution, où la résolution est la précision de l'indicateur de résultat attendu donné dans la stratégie
Sélection des anneaux de hachage de travail : utilisez align_time pour rechercher le dernier anneau de hachage de travail dans la liste des anneaux de hachage dont le basculement n'est pas supérieur à align_time.
Sélection de l'instance de travail : utilisez planid + align_time + la valeur d'une série d'étiquettes spécifiées comme clé pour calculer la valeur de hachage, et utilisez la valeur de hachage pour trouver l'instance de travail dans l'anneau de hachage du travailleur. La série d'étiquettes spécifiée est générée par la règle après analyse de la stratégie et est généralement vide pour les stratégies qui nécessitent le traitement d'une petite quantité de données.
travailleur obc
La fonction principale du travailleur est le calcul des indicateurs de métriques
Le distributeur garantit que les points de métriques de la même politique, de la même dimension d'agrégation et de la même fenêtre de calcul seront transmis au même travailleur. Les points de données de métriques reçus par le travailleur contiendront les informations d'identification de la politique, et le travailleur les utilisera pour rechercher et calculer le contenu de la politique. La plus petite unité d'opération logique pour calculer les stratégies est l'action. Les fonctions, les opérations binaires et les opérations d'agrégation dans PromQL sont toutes traduites en actions. Dans la matrice d'agrégation du travailleur, sous chaque action se trouve une série de fenêtres temporelles alignées en fonction de la résolution. Dans la fenêtre temporelle, un ensemble de données qui doivent être calculées ensemble est écrit dans la même unité de calcul. L'unité de calcul est chez le travailleur. La plus petite unité informatique physique. Les données ajoutées à la même unité de calcul ne sont pas mises en cache mais sont utilisées pour les calculs en temps réel sauf si nécessaire.
Cela peut être difficile à comprendre. Laissez-moi vous donner un exemple, en prenant la règle de calcul somme par (appelant, appelé) (rpc_counter). Le filtrage de l'indicateur d'origine rpc_counter est terminé dans le distributeur, et l'action de somme par (appelant , appelé) est traité comme une action. Le type d'action est une opération d'agrégation. Le type d'agrégation est la sommation. Les dimensions de la sortie de données après l'agrégation sont l'appelant et l'appelé. Lors du traitement des points de données, l'opérateur comparera les données avec l'appelé. même valeur des deux étiquettes de l'appelant et de l'appelé. Les points sont envoyés à la même unité d'agrégation. Chaque fois que l'unité d'agrégation reçoit un point, elle effectuera une action telle que sum += point.value.
Un problème auquel les travailleurs doivent prêter attention lors du traitement des opérations binaires et des opérations d'agrégation est le réglage du temps d'ouverture de la fenêtre. Combien de temps une fenêtre attend-elle que toutes les données dont elle a besoin arrivent ? Cette valeur affecte directement le temps réel et la précision de sortie de l'indicateur. Nous avons défini la politique par défaut suivante, basée sur la distribution des délais de nos propres métriques dans la transmission des liens :
Si la valeur initiale du pas de l'indicateur est inférieure ou égale à 10, le temps d'ouverture de la fenêtre est fixé à 25 s.
Si la valeur de pas de l'indicateur d'origine est supérieure à 10, le temps d'ouverture de la fenêtre est réglé sur 2*pas + 5. Si le temps d'ouverture de la fenêtre est supérieur à 120 s, le temps d'ouverture de la fenêtre est réglé sur 120.
Cette partie présente la mise en œuvre de chaque composant de manière relativement brève. Elle ne présente que le processus de base. De nombreux compromis et optimisations que nous avons faits en termes de performances et de fonctions seront présentés séparément lorsque nous en aurons l'occasion.
Contenu supplémentaire
Afin de faciliter la compréhension de tous, du contenu supplémentaire est ajouté ici.
Exemple de stratégie de calcul
La stratégie interne d'OBC est exprimée sous la forme d'un arbre. Les nœuds feuilles de l'arbre doivent être les conditions de filtrage ou les constantes de Metrics, et les nœuds feuilles ne doivent pas être des constantes (une telle stratégie n'a aucun sens pour les événements pilotés par les événements). moteurs de calcul).Le filtrage des métriques La condition est appelée Filtre dans la politique. Le filtre est exécuté sur le distributeur et le reste des actions est exécuté sur le travailleur. Si la stratégie n'est pas spécifiquement définie, les métriques correspondant à la stratégie dans la même fenêtre seront envoyées au même travailleur. Le traitement des actions ultérieures sera terminé sur ce travailleur. Les données de différentes fenêtres peuvent être envoyées à différents travailleurs. La raison de c’est que l’équilibrage des charges entre les travailleurs ne peut pas être obtenu simplement en les dispersant dans la dimension politique.
Il y a un point spécial à noter ici. Si la quantité de données dans une seule fenêtre d'une certaine politique est trop importante pour qu'un seul travailleur puisse la gérer, nous effectuerons manuellement certains paramètres pour diffuser la politique à plusieurs travailleurs selon un calcul global. dimensions. S'il ne peut pas être démonté ou si un seul travailleur ne peut toujours pas le manipuler après l'avoir démonté, nous choisirons de l'interdire. Bien sûr, comme nous limitons les données filtrées dans la politique de calcul à l'étiquette __ns__ et que nous ne pouvons utiliser que les données de métriques du même service pour le calcul, jusqu'à présent, nous n'avons pas rencontré de situation nécessitant une politique d'interdiction. Pour les situations où un seul travailleur ne peut pas le gérer, vous pouvez également choisir de mettre en œuvre des capacités de calcul en cascade entre les travailleurs et de traiter des tâches de données volumineuses de manière fusionnée. S'il y a une demande ultérieure, cette capacité peut être rapidement étendue sur l'architecture actuelle.
Prise en charge de PromQL
OBC espère utiliser PromQL comme méthode d'accès utilisateur pour les stratégies informatiques, ce qui peut réduire la compréhension des utilisateurs des stratégies et des coûts d'accès. À la date de rédaction, notre niveau d'achèvement de la prise en charge de la syntaxe et des fonctions PromQL n'est pas élevé. La raison principale en est qu'il existe de nombreuses opérations et accès stratégiques aux stocks des opérateurs qui ne seront pas utilisés. La demande nous pousse à mettre en œuvre progressivement Dans l'implémentation, il existe également certaines syntaxes PromQL qui ne conviennent pas à l'implémentation dans les calculs en temps réel, telles que le modificateur de décalage, le modificateur @ et la sous-requête.
Dans l'article précédent, nous avons introduit que le distributeur s'assure que les données de la même fenêtre de calcul de la même stratégie de calcul sont transmises au même travailleur. Vous vous demandez peut-être ici, qu'en est-il du vecteur de plage ? Comment calculer la colère lorsque deux points dans la fenêtre avant et après des opérations telles que la colère (http_request_total[10s]) sont transmis à différents travailleurs ? Si vous avez de tels doutes, je dois me féliciter de vous avoir fait lire attentivement et comprendre ce que j'ai écrit auparavant.
Les vecteurs de plage, y compris le sélecteur de vecteur de plage et la fonction de vecteur de plage, ne sont pas pris en charge dans la version actuelle d'OBC. La raison pour laquelle ils ne sont pas pris en charge est que nous ne pouvons pas les utiliser pour le moment. Vous pouvez penser que nos données internes sont toutes des jauges. types dans Prometheus. Pour les requêtes, l'indicateur dit de compteur de notre côté compte en fait le volume de requêtes dans chaque cycle de 10. Les données entre les cycles ne seront pas accumulées, tout comme nos données de compteur ont été augmentées (http_request_total) avant d'être rapportées. 10s]) une telle opération. Bien sûr, nous envisagerons certainement d'implémenter la prise en charge de la syntaxe liée aux vecteurs de plage à l'avenir, mais nous apporterons également certaines restrictions de syntaxe.
Latence précise des requêtes de granularité du cluster
Didi Observable Platform n'avait pas le concept d'histogramme comme type de données avant de prendre en charge la collecte Prometheus Exporter et la récupération de données PromQL. Concernant le délai de demande de service, nous utiliserons l'algorithme t-digest du côté de la collecte pour approximer la distribution du délai d'interface de chaque instance de service et rapporterons les données de retard des valeurs quantiles 99 & 95 & 90 & 50 par défaut. En raison du manque d'informations originales, il est impossible de fournir aux utilisateurs un calcul relativement précis de la valeur du quantile de retard de l'interface de granularité du cluster. Ils ne peuvent utiliser que la valeur moyenne ou maximale de l'indicateur de valeur du quantile de retard de granularité sur une seule machine.
Nous avons également résolu ce problème sur OBC.La méthode spécifique est que OBC coopère avec la fin de la collecte.Lorsque la fin de la collecte signale l'indicateur de valeur du quantile de retard, elle rapporte également ensemble les informations de compartiment de la distribution des retards d'interface. Les informations regroupées ne tombent pas dans le stockage persistant et ne seront ingérées dans OBC qu'à la demande. OBC étend les opérations pertinentes dans un opérateur d'agrégation PromQL. Le nom de cet opérateur est centile. Son action consiste à fusionner les informations regroupées d'une seule machine pour obtenir une nouvelle distribution de retard, produisant les quantiles de cette distribution à la demande.
Résumé et perspectives
Jusqu'à présent, OBC fonctionne de manière stable en ligne depuis plus de plusieurs mois. Plusieurs tâches de calcul de métriques de base de la plate-forme observable ont été migrées vers OBC, et des économies de coûts significatives ont été réalisées.
Concernant les idées d'itération ultérieure du projet, voici une introduction à l'un des points centraux. Nous espérons inclure la fin de la collecte dans cet ensemble de moteurs informatiques pour parvenir à l'intégration de la collecte et du calcul : pour les besoins informatiques de l'utilisateur, nous pouvons nous déplacer comme le plus en avant possible. La fin de l'acquisition est terminée, et le pré-calcul peut être effectué à la fin de l'acquisition et le pré-calcul peut être effectué à la fin de l'acquisition autant que possible.
Après calcul par le moteur de calcul, nous avons produit davantage de données d'observation, y compris des données originales et de nouveaux résultats de calcul. Où ces données sont-elles stockées ? Qu'il s'agisse de choisir le stockage en lignes ou en colonnes, d'utiliser les solutions existantes ou l'auto-recherche, et comment résoudre d'énormes problèmes de données. Le prochain article racontera l'histoire du stockage des données d'observation à Didi.
Discussion nocturne native du cloud
Comment supportez-vous les besoins de calcul d’indicateurs observables dans l’environnement de production ? Bienvenue à laisser un message dans la zone de commentaires. Si vous avez besoin de communiquer davantage avec nous, vous pouvez également envoyer un message privé directement au backend.
L'auteur sélectionnera l'un des messages les plus significatifs et enverra une valise personnalisée Didi, vous souhaitant un voyage sans souci le 1er octobre. Le tirage au sort aura lieu le 26 septembre à 21 heures.
