Alerting Grafana vs Icinga2
Bonjour, Petite problématique du vendredi : actuellement, nous utilisons Icinga2 avec l'excellent Anag [1] de Damian Degois pour nous réveiller au milieu de la nuit si un morceau de notre infra part en vrille (j'aurais pu utiliser 'torche' mais je crois que les masses ne sont pas prêtes encore). Souhaitant basculer le stockage sur InfluxDB (question de perf), nous aimerions utiliser Telegraf pour faire la remontée des métriques mais cela nous empêche d'utiliser la partie API de Icinga2. Ou alors il faut faire un double monitoring : alertes SNMP & Ping avec Icinga2 et métriques via Telegraf. Je ne trouve pas ça très satisfaisant. Je me suis pas mal documenté sur des exemples que j'ai trouvés ici et là mais on dirait que la plupart des boites ont des gens qui regardent un écran 24h/24 et que personne ne voit l'intérêt de pouvoir dormir de temps à autre. Les rares qui font ça passent par des services tiers type Pagerduty mais ça ne me tente pas non plus, pour une question d'indépendance sur un sujet qui est quand même très critique. Pas très envie de multiplier les SPoF. Du coup, ma question : et vous, comment faites vous ? A) Pagerduty B) un insomniaque dans l'équipe C) la réponse D Merci d'avance pour votre partage ! Julien [1] https://play.google.com/store/apps/details?id=info.degois.damien.android.aNa...
Salut, Pagerduty ici. Je pense qu'il est dans tous les cas important de décorréler ce qui génère l'alerte (Icinga ou autre) de ce qui gère l'alerte ensuite (réveiller les bonnes personnes, gestion du calendrier/des overrides, déduplication, auto acquittement...). Le double monitoring comme tu le mentionnes n'est pas vraiment intéressant car tu seras coincé le jour où tu voudras faire des alertes sur les métriques de Telegraf. Cordialement, Le ven. 25 juin 2021 à 16:15, Julien Escario <julien.escario@altinea.fr> a écrit :
Bonjour,
Petite problématique du vendredi : actuellement, nous utilisons Icinga2 avec l'excellent Anag [1] de Damian Degois pour nous réveiller au milieu de la nuit si un morceau de notre infra part en vrille (j'aurais pu utiliser 'torche' mais je crois que les masses ne sont pas prêtes encore).
Souhaitant basculer le stockage sur InfluxDB (question de perf), nous aimerions utiliser Telegraf pour faire la remontée des métriques mais cela nous empêche d'utiliser la partie API de Icinga2. Ou alors il faut faire un double monitoring : alertes SNMP & Ping avec Icinga2 et métriques via Telegraf. Je ne trouve pas ça très satisfaisant.
Je me suis pas mal documenté sur des exemples que j'ai trouvés ici et là mais on dirait que la plupart des boites ont des gens qui regardent un écran 24h/24 et que personne ne voit l'intérêt de pouvoir dormir de temps à autre.
Les rares qui font ça passent par des services tiers type Pagerduty mais ça ne me tente pas non plus, pour une question d'indépendance sur un sujet qui est quand même très critique. Pas très envie de multiplier les SPoF.
Du coup, ma question : et vous, comment faites vous ?
A) Pagerduty B) un insomniaque dans l'équipe C) la réponse D
Merci d'avance pour votre partage !
Julien
[1]
https://play.google.com/store/apps/details?id=info.degois.damien.android.aNa...
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 25/06/2021 16:33, Mathieu Corbin wrote:
Je pense qu'il est dans tous les cas important de décorréler ce qui génère l'alerte (Icinga ou autre) de ce qui gère l'alerte ensuite (réveiller les bonnes personnes, gestion du calendrier/des overrides, déduplication, auto acquittement...).
+100. Gérer un on-call sans ce type d'outil c'est quand meme vraiment painful (PD, VictorOps ou autres).
Le double monitoring comme tu le mentionnes n'est pas vraiment intéressant car tu seras coincé le jour où tu voudras faire des alertes sur les métriques de Telegraf.
-- Raphael Mazelier
Le 25/06/2021 à 17:50, Raphael Mazelier a écrit :
On 25/06/2021 16:33, Mathieu Corbin wrote:
Je pense qu'il est dans tous les cas important de décorréler ce qui génère l'alerte (Icinga ou autre) de ce qui gère l'alerte ensuite (réveiller les bonnes personnes, gestion du calendrier/des overrides, déduplication, auto acquittement...).
+100.
Gérer un on-call sans ce type d'outil c'est quand meme vraiment painful (PD, VictorOps ou autres).
Ok, merci du retour. On va faire un test de PagerDuty du coup. Mais dépendre d'un service tiers, aussi fiable soit-il, me gêne quand même pour quelque chose d'aussi critique. Personne n'a d'équivalent à PargerDuty en self-hosted ? Pour le moment, nous avons un Icinga2 chez nous pour le principal et un secondaire chez un tiers pour surveiller le principal (et vice versa) + 2/3 équipements critiques type routeurs de bordure. Ca fonctionne plutôt bien depuis 6 ans.
Le double monitoring comme tu le mentionnes n'est pas vraiment intéressant car tu seras coincé le jour où tu voudras faire des alertes sur les métriques de Telegraf.
C'est exactement mon soucis. En plus de consommer de la ressource pour récupérer deux fois le même métrique : BP, CPU, etc ... Je suis surpris du peu de contributions : question mal posée ou nous sommes aussi peu à poser ces problématiques sur la table ? Bonne semaine, Julien
Salut, On Mon, Jun 28, 2021 at 09:40:50AM +0200, Julien Escario wrote:
Le 25/06/2021 à 17:50, Raphael Mazelier a écrit :
On 25/06/2021 16:33, Mathieu Corbin wrote:
Je pense qu'il est dans tous les cas important de décorréler ce qui génère l'alerte (Icinga ou autre) de ce qui gère l'alerte ensuite (réveiller les bonnes personnes, gestion du calendrier/des overrides, déduplication, auto acquittement...).
+100.
Gérer un on-call sans ce type d'outil c'est quand meme vraiment painful (PD, VictorOps ou autres).
Ok, merci du retour. On va faire un test de PagerDuty du coup. Mais dépendre d'un service tiers, aussi fiable soit-il, me gêne quand même pour quelque chose d'aussi critique.
Sans intention de t'offenser mais plutôt dans celle de parler clairement, cette remarque me paraît issue d'une doctrine plus que d'un raisonnement. Je m'explique. Si vous n'avez aucun fournisseur de services tiers pour le moment (e.g. cloud), alors je comprends que passer le cap soit un changement de doctrine. Mais si on parle simplement de criticalité, je ne suis pas d'accord sur le fait de dire "pas de service tiers, c'est trop critique". Un service d'alerting doit avoir un minimum de dépendances, c'est une best practice. Mais le fait que ce soit outsourcé ou pas n'a pas de rapport. Je ne connais pas PagerDuty, mais d'après leur nom, je dirais que l'alerting c'est leur coeur de métier. Donc premièrement, ils ont probablement beaucoup plus de monde travaillant sur leur service que ton équipe ne pourra jamais en mettre juste sur l'alerting. Ensuite, il est dans leur intérêt de fournir un service très fiable, il en va de la survie de la société. Je ne dis pas que tu dois prendre PagerDuty les yeux fermés, un peu de recherche sur leur fiabilité, les avantages et les inconvénients est nécessaire. Mais je voulais juste essayer de rectifier cette fausse best practice "pas de service tiers, c'est trop critique". Ca peut être le cas, mais c'est plus subtil. -- Jeremie Le Hen My PIN is the last four digits of Pi.
Le 28/06/2021 à 10:04, Jeremie Le Hen a écrit :
Salut,
On Mon, Jun 28, 2021 at 09:40:50AM +0200, Julien Escario wrote:
Ok, merci du retour. On va faire un test de PagerDuty du coup. Mais dépendre d'un service tiers, aussi fiable soit-il, me gêne quand même pour quelque chose d'aussi critique. Sans intention de t'offenser mais plutôt dans celle de parler clairement, cette remarque me paraît issue d'une doctrine plus que d'un raisonnement.
Tu as totalement raison, c'est plus de la doctrine que de l'argumentaire technique. Le fait est que je n'ai pas de REX sur un service comme PagerDuty et que j'aimerais éviter de découvrir que mon infra est down et que je n'ai pas eu d'alerte parce que PD est down également au même moment. La probabilité est très faible mais on fait bien du RAID6 (pardon RAIDZ2) non ?
Je m'explique. Si vous n'avez aucun fournisseur de services tiers pour le moment (e.g. cloud), alors je comprends que passer le cap soit un changement de doctrine.
Alors c'est un problème d'explication de ma part : je suis fournisseur de cloud. On a une infra, on la maîtrise même si pour certaines choses critiques, on est bien obligés d'avoir quelques VMs chez des tiers, notamment pour prévoir le cas extrême où tout est à plat.
Mais si on parle simplement de criticalité, je ne suis pas d'accord sur le fait de dire "pas de service tiers, c'est trop critique". Un service d'alerting doit avoir un minimum de dépendances, c'est une best practice. Mais le fait que ce soit outsourcé ou pas n'a pas de rapport.
Je ne connais pas PagerDuty, mais d'après leur nom, je dirais que l'alerting c'est leur coeur de métier. Donc premièrement, ils ont probablement beaucoup plus de monde travaillant sur leur service que ton équipe ne pourra jamais en mettre juste sur l'alerting. Ensuite, il est dans leur intérêt de fournir un service très fiable, il en va de la survie de la société.
Ce n'est pas vrai pour une société hégémonique sur un segment de marché. Passé une certaine taille, la survie n'est pas en jeu après un incident majeur (cf OVH, Cloudflare il y a quelques années ou fastly plus récemment). Lorsque tu n'as pas le choix de la solution ou que le changement est impossible pour des raisons techniques, politiques ou legacy, tu fais jouer le SLA si tu en as un, tu grognes un coup, les presta te promet que ça ne se reproduira plus et tu relances tout comme avant. Quand tu maîtrises ton truc, tu as effectivement plus de chances d'avoir un incident puisque ce n'est, par définition, pas ton cœur de métier mais tu connais les causes exactes et tu maîtrises ton plan de remédiation. Oui, tout ça devient philosophique ;-)
Je ne dis pas que tu dois prendre PagerDuty les yeux fermés, un peu de recherche sur leur fiabilité, les avantages et les inconvénients est nécessaire. Mais je voulais juste essayer de rectifier cette fausse best practice "pas de service tiers, c'est trop critique". Ca peut être le cas, mais c'est plus subtil.
En fait, je m'oriente vers un truc qui fini par devenir complexe : un monitoring de PagerDuty depuis mon infra et une infra tierce. Mais même soucis : qui va pousser l'alerte en cas de pépin ? Bref, ça tourne en rond cette histoire. J'ai encore un peu de temps pour y réfléchir. Julien
La question est bien posée je pense mais il y a peu de solution sur étagère sauf peut être https://supervision-clever.fr/supervision-alarmes-gestion-astreintes/ dont je ne suis ni utilisateur, ni revendeur et encore moins actionnaire (je tiens à le préciser :) Se faire réveiller implique de faire sonner un tel il n'y a donc pas beaucoup de choix: soit tu te fabriques une pondeuse d'appel avec ton PABX, soit tu utilises une solution comme PagerDuty ou autre ou alors et ce que nous on fait: on détourne une solution de marketing tel pour lui faire appeler ton astreinte. Pour ce qui est de s'appuyer sur un tiers, eh bien c'est une question de feeling. Moi je dis que faire appel à une solution spécialisée faite par des gens dont c'est le métier et le gagne pain, ça donne quand même un certain niveau de rassurance. Sans compter que si tout est vraiment en rade chez toi, y compris ta sup et ta solution d'alerte, avoir ce petit bout de truc à l'extérieur ça peut aider ! Bonne recherche, Matthieu Le lun. 28 juin 2021 à 09:43, Julien Escario <julien.escario@altinea.fr> a écrit :
Le 25/06/2021 à 17:50, Raphael Mazelier a écrit :
On 25/06/2021 16:33, Mathieu Corbin wrote:
Je pense qu'il est dans tous les cas important de décorréler ce qui génère l'alerte (Icinga ou autre) de ce qui gère l'alerte ensuite (réveiller les bonnes personnes, gestion du calendrier/des overrides, déduplication, auto acquittement...).
+100.
Gérer un on-call sans ce type d'outil c'est quand meme vraiment painful (PD, VictorOps ou autres).
Ok, merci du retour. On va faire un test de PagerDuty du coup. Mais dépendre d'un service tiers, aussi fiable soit-il, me gêne quand même pour quelque chose d'aussi critique.
Personne n'a d'équivalent à PargerDuty en self-hosted ?
Pour le moment, nous avons un Icinga2 chez nous pour le principal et un secondaire chez un tiers pour surveiller le principal (et vice versa) + 2/3 équipements critiques type routeurs de bordure. Ca fonctionne plutôt bien depuis 6 ans.
Le double monitoring comme tu le mentionnes n'est pas vraiment intéressant car tu seras coincé le jour où tu voudras faire des alertes sur les métriques de Telegraf.
C'est exactement mon soucis. En plus de consommer de la ressource pour récupérer deux fois le même métrique : BP, CPU, etc ...
Je suis surpris du peu de contributions : question mal posée ou nous sommes aussi peu à poser ces problématiques sur la table ?
Bonne semaine,
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Matthieu Noirbusson
Coucou, Le Mon, 28 Jun 2021 09:40:50 +0200, Julien Escario <julien.escario@altinea.fr> a écrit :
Je suis surpris du peu de contributions : question mal posée ou nous sommes aussi peu à poser ces problématiques sur la table ?
Mon expérience perso est d'avoir des usagers qui sont conscients qu'ils ne ne sont pas en charge du 18 et qui nous laissent dormir la nuit. Bien sûr ça ne répond pas à la demande des gens qui sont conscient d'être en charge du 18 (mais ils ne sont peut être pas si nombreux), ni des gens qui ne sont pas conscients de l'avoir en charge (mais personne ne fait ça, non ?) François -- François Poulain <fpoulain@metrodore.fr>
Le 28/06/2021 à 10:20, François Poulain a écrit :
Coucou,
Le Mon, 28 Jun 2021 09:40:50 +0200, Julien Escario <julien.escario@altinea.fr> a écrit :
Je suis surpris du peu de contributions : question mal posée ou nous sommes aussi peu à poser ces problématiques sur la table ? Mon expérience perso est d'avoir des usagers qui sont conscients qu'ils ne ne sont pas en charge du 18 et qui nous laissent dormir la nuit.
Bien sûr ça ne répond pas à la demande des gens qui sont conscient d'être en charge du 18 (mais ils ne sont peut être pas si nombreux), ni des gens qui ne sont pas conscients de l'avoir en charge (mais personne ne fait ça, non ?)
François
On a pas les mêmes usagers/clients pour le coup ;-) On ne peut pas vraiment comparer notre problématique au 18 : l'astreinte pour eux, c'est une équipe qui est donc un local dédié, réveillé (au moins en partie) et qui répond à un téléphone donc l'alerte est gérée par le réseau téléphonique. Si l'acheminement des appels est H.S, c'est en dehors de leur zone de responsabilité, ils n'ont plus la main. Bref, la comparaison n'est pas (ou peu) pertinente en l'état. Julien
Bonjour Julien, De notre côté on était Nagios et Munin on a presque fini de migrer tout sur Prometheus / Grafana, il restera un bout de Nagios pour les supervisions à gérer à la main hors infogérance et dépannage. Car on a profité Pour la notification on a des règles assez strictes qui ne nous réveillent que quand nécessaire et que pour des services sur lesquels nous avons la main. Pour la notification question indépendance on a aussi fait ce choix et nous avons deux mini pc avec des modem gsm pour envoyer les textos. Un petit programme perl fait le load balancing des alertes sur les deux boitiers et est capable de gérer le failover si un des deux boitiers n'est pas joignable (ils sont sur des réseaux IP et opérateur gsm différents dans des lieux différents). Les services extérieurs de notification vous faites comment quand c'est votre backbone / réseau managé par un tiers qui tombe et que vos sondes ne sont plus capables d'envoyer leurs notifications? Pour avoir déjà connu ce genre de souci, c'est un boitier sms sur un des sites de production joignable en local par un alertmanager, et l'autre boitier sms en dehors de notre réseau avec une autre sonde Nagios / Prom qui monitore depuis l'extérieur notre réseau. Quand y a une isolation réseau on a double notification ce qui confirme que c'est pas juste un bgp qui bagote. Voilà pour nous Le 25/06/2021 à 16:13, Julien Escario a écrit :
Bonjour,
Petite problématique du vendredi : actuellement, nous utilisons Icinga2 avec l'excellent Anag [1] de Damian Degois pour nous réveiller au milieu de la nuit si un morceau de notre infra part en vrille (j'aurais pu utiliser 'torche' mais je crois que les masses ne sont pas prêtes encore).
Souhaitant basculer le stockage sur InfluxDB (question de perf), nous aimerions utiliser Telegraf pour faire la remontée des métriques mais cela nous empêche d'utiliser la partie API de Icinga2. Ou alors il faut faire un double monitoring : alertes SNMP & Ping avec Icinga2 et métriques via Telegraf. Je ne trouve pas ça très satisfaisant.
Je me suis pas mal documenté sur des exemples que j'ai trouvés ici et là mais on dirait que la plupart des boites ont des gens qui regardent un écran 24h/24 et que personne ne voit l'intérêt de pouvoir dormir de temps à autre.
Les rares qui font ça passent par des services tiers type Pagerduty mais ça ne me tente pas non plus, pour une question d'indépendance sur un sujet qui est quand même très critique. Pas très envie de multiplier les SPoF.
Du coup, ma question : et vous, comment faites vous ?
A) Pagerduty B) un insomniaque dans l'équipe C) la réponse D
Merci d'avance pour votre partage !
Julien
[1] https://play.google.com/store/apps/details?id=info.degois.damien.android.aNa...
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
De notre côté on a développé un test cyclique qui envoie une notif très régulièrement vers un robot à l'extérieur qui nous alerte s'il ne reçoit rien. C'est compliqué d'aller plus loin... Le lun. 28 juin 2021 à 11:18, Wallace <wallace@morkitu.org> a écrit :
Bonjour Julien,
De notre côté on était Nagios et Munin on a presque fini de migrer tout sur Prometheus / Grafana, il restera un bout de Nagios pour les supervisions à gérer à la main hors infogérance et dépannage. Car on a profité
Pour la notification on a des règles assez strictes qui ne nous réveillent que quand nécessaire et que pour des services sur lesquels nous avons la main.
Pour la notification question indépendance on a aussi fait ce choix et nous avons deux mini pc avec des modem gsm pour envoyer les textos. Un petit programme perl fait le load balancing des alertes sur les deux boitiers et est capable de gérer le failover si un des deux boitiers n'est pas joignable (ils sont sur des réseaux IP et opérateur gsm différents dans des lieux différents).
Les services extérieurs de notification vous faites comment quand c'est votre backbone / réseau managé par un tiers qui tombe et que vos sondes ne sont plus capables d'envoyer leurs notifications? Pour avoir déjà connu ce genre de souci, c'est un boitier sms sur un des sites de production joignable en local par un alertmanager, et l'autre boitier sms en dehors de notre réseau avec une autre sonde Nagios / Prom qui monitore depuis l'extérieur notre réseau.
Quand y a une isolation réseau on a double notification ce qui confirme que c'est pas juste un bgp qui bagote.
Voilà pour nous Le 25/06/2021 à 16:13, Julien Escario a écrit :
Bonjour,
Petite problématique du vendredi : actuellement, nous utilisons Icinga2 avec l'excellent Anag [1] de Damian Degois pour nous réveiller au milieu de la nuit si un morceau de notre infra part en vrille (j'aurais pu utiliser 'torche' mais je crois que les masses ne sont pas prêtes encore).
Souhaitant basculer le stockage sur InfluxDB (question de perf), nous aimerions utiliser Telegraf pour faire la remontée des métriques mais cela nous empêche d'utiliser la partie API de Icinga2. Ou alors il faut faire un double monitoring : alertes SNMP & Ping avec Icinga2 et métriques via Telegraf. Je ne trouve pas ça très satisfaisant.
Je me suis pas mal documenté sur des exemples que j'ai trouvés ici et là mais on dirait que la plupart des boites ont des gens qui regardent un écran 24h/24 et que personne ne voit l'intérêt de pouvoir dormir de temps à autre.
Les rares qui font ça passent par des services tiers type Pagerduty mais ça ne me tente pas non plus, pour une question d'indépendance sur un sujet qui est quand même très critique. Pas très envie de multiplier les SPoF.
Du coup, ma question : et vous, comment faites vous ?
A) Pagerduty B) un insomniaque dans l'équipe C) la réponse D
Merci d'avance pour votre partage !
Julien
[1] https://play.google.com/store/apps/details?id=info.degois.damien.android.aNa...
_______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Matthieu Noirbusson
Bonjour, De mon côté, j'utilise un rapsberry en observation sur l'infra. A une époque, j'utilisais l'alerting de google agenda (car gratuit) en créant des évènements immédiats avec rappel SMS / notification. Puis c'est devenu impossible et je suis passé par mon FAI pour envoyer des SMS. Finalement, je me contente désormais d'envoyer des mails. Tout est en python (mail) ou en php (sms) et j'ai toujours les codes si ça en intéresse certains. Cordialement, Le 28/06/2021 à 12:10, Noirbusson Matthieu a écrit :
De notre côté on a développé un test cyclique qui envoie une notif très régulièrement vers un robot à l'extérieur qui nous alerte s'il ne reçoit rien. C'est compliqué d'aller plus loin...
Le lun. 28 juin 2021 à 11:18, Wallace <wallace@morkitu.org <mailto:wallace@morkitu.org>> a écrit :
Bonjour Julien,
De notre côté on était Nagios et Munin on a presque fini de migrer tout sur Prometheus / Grafana, il restera un bout de Nagios pour les supervisions à gérer à la main hors infogérance et dépannage. Car on a profité
Pour la notification on a des règles assez strictes qui ne nous réveillent que quand nécessaire et que pour des services sur lesquels nous avons la main.
Pour la notification question indépendance on a aussi fait ce choix et nous avons deux mini pc avec des modem gsm pour envoyer les textos. Un petit programme perl fait le load balancing des alertes sur les deux boitiers et est capable de gérer le failover si un des deux boitiers n'est pas joignable (ils sont sur des réseaux IP et opérateur gsm différents dans des lieux différents).
Les services extérieurs de notification vous faites comment quand c'est votre backbone / réseau managé par un tiers qui tombe et que vos sondes ne sont plus capables d'envoyer leurs notifications? Pour avoir déjà connu ce genre de souci, c'est un boitier sms sur un des sites de production joignable en local par un alertmanager, et l'autre boitier sms en dehors de notre réseau avec une autre sonde Nagios / Prom qui monitore depuis l'extérieur notre réseau.
Quand y a une isolation réseau on a double notification ce qui confirme que c'est pas juste un bgp qui bagote.
Voilà pour nous
Le 25/06/2021 à 16:13, Julien Escario a écrit :
Bonjour,
Petite problématique du vendredi : actuellement, nous utilisons Icinga2 avec l'excellent Anag [1] de Damian Degois pour nous réveiller au milieu de la nuit si un morceau de notre infra part en vrille (j'aurais pu utiliser 'torche' mais je crois que les masses ne sont pas prêtes encore).
Souhaitant basculer le stockage sur InfluxDB (question de perf), nous aimerions utiliser Telegraf pour faire la remontée des métriques mais cela nous empêche d'utiliser la partie API de Icinga2. Ou alors il faut faire un double monitoring : alertes SNMP & Ping avec Icinga2 et métriques via Telegraf. Je ne trouve pas ça très satisfaisant.
Je me suis pas mal documenté sur des exemples que j'ai trouvés ici et là mais on dirait que la plupart des boites ont des gens qui regardent un écran 24h/24 et que personne ne voit l'intérêt de pouvoir dormir de temps à autre.
Les rares qui font ça passent par des services tiers type Pagerduty mais ça ne me tente pas non plus, pour une question d'indépendance sur un sujet qui est quand même très critique. Pas très envie de multiplier les SPoF.
Du coup, ma question : et vous, comment faites vous ?
A) Pagerduty B) un insomniaque dans l'équipe C) la réponse D
Merci d'avance pour votre partage !
Julien
[1] https://play.google.com/store/apps/details?id=info.degois.damien.android.aNa... <https://play.google.com/store/apps/details?id=info.degois.damien.android.aNag>
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ <http://www.frsag.org/>
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ <http://www.frsag.org/>
-- Matthieu Noirbusson
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Rémy Dernat Chef de projet SI IR CNRS - ISI / ISEM
participants (8)
-
François Poulain -
Jeremie Le Hen -
Julien Escario -
Mathieu Corbin -
Noirbusson Matthieu -
Raphael Mazelier -
Rémy Dernat -
Wallace