Doyoucheck, monitoring web

Vraiment sympa. J'attends de voir l'évolution du produit, car pour l'instant j'utilise pingdom mais si vous apportez des éléments en plus, ça pourrait m'intéresser.

Hello !
Merci tout d'abord pour le retour :) quels éléments souhaiterais-tu voir apparaître ? C'est peut-être déjà en cours de dév...

Salut Simon75017,
je trouve que ton idée est super mais il y a déjà bcp de concurrant et c'est assez facile à faire sur son propre raspberry pi,
je crois que si tu veux te démarquer des autres il faudrait que tu instaures des services en plus par exemple:
-si le site semble down prendant plus d un certaint, tu proposes de le rediriger vers un autre serveur ouvers un site de substitution static (que tu héberges chez toi ou pas ).
-envoyer un message directement au serveur pour qu'il exécute des protocoles bien précis tel que le redémarrage, arrêt des systèmes de payements , etc
-....

Sinon je trouve ton idée vraiment biens (et si tu instaure ces services en plus, je deviendrai surement un futur client :-) )
jc

C'est un exemple, mais générer des rapports détailler. C'est surtout pour permettre d'appuyer des retours sur des hébergeurs ou sur de la maintenance applicative. (tous les mois ou semaines par exemple). Et teste de ping à partir de différent continent.

Perso, j ai un peux peur du système d email sans système de "diminution de dégats" :
Par exemple, ca arrive qu un de mes hebergeurs (heroku pour RoR) subit une attaque ou tombe tout simplement en panne, mes clients reçoivent alors un email tout en même temps pour les alerter et ils vont tous me contacter en même temps et ca devient un gros foutoir .
C est pour ca que je pense qu il est mieux de mettre en place un système de secour et à la limite on peut informer le client par un mail.
Pour bien faire (je ne suis pas sur que c est possible) il faudrait savoir si c est une attaque groupée où le dev sait intervenir ou pas .
jc

@gynidarl, je comprend ta démarche, mais tu viens de démontrer l'erreur même de l'ux, penser pratique avant de penser outil. Comme tu peux le comprendre @Simon75017 n'est pas graphiste et son collègue non plus, donc en premier lieu ils ont penser outil et, j'imagine, font du mieux qu'ils peuvent pour créer et développer un service. Penser graphisme dès le début d'un projet, c'est perdre du temps pour apporter quelque chose d'incertain. (Impossible de chiffrer la valeur ajouter sur de l'ux "à part de l'AB testing"). Si je devais allez plus loin, l'ux est bien souvent pris pour ce qu'il est et non pour ce qu'il devrait apporter a un projet. Dans trop de projets je vois qu'on fait de ux pour faire de l'ux et le résultat c'est que ça ne fonctionne pas. Exemple type qu'on me donne "regarde google" oui google fonctionne bien, mais si tu regardes bien niveau ux, ils ont pleins de choses qui sont a l'opposé des valeurs et aussi de l'usage utilisateur. Créer des frustrations et donc aller à l'encontre de l'usage et de l'expérience utilisateur peut être une bonne chose sur un plan marketing et pourtant les ux ne veulent pas l'admettre. Penser ux design (non pas ux) est une mauvaise chose à mon avis. Si on prend l'exemple de ce projet, la partie ux c'est résoudre un problème fondamental de suivi de projet, ux designe c'est les éléments que tu viens de cités.

Désolé je me suis un peu perdu ^^.

Salut :)
Actuellement je suis sur UptimeRobot, et chacun de vous à ses avantages comme ses inconvénients.
Le point positif comparé à Uptime robot, c'est l'interface qui est plus fluide... MAIS, ça manque de graphique je trouve, pas de graphique sur le down, sur le nombre de site tombé... Avoir un graph sur le temps de réponse de son site serait génial je pense ;).
Les fonctionnalités semblent être aussi au rendez vous, j'ai pas encore vu le temps de réponse. La localisation ! ça c'est une idée !
Après les points négatifs : le temps ! on ne peut pas choisir 2 minutes par exemple. Bon, après je pense que tout le monde choisis 30s (j'ai préféré une minute ^^ )
Le deuxième chose négatif, c'est le temps d'essais... 30j, pour 10 interfaces... Je comprend qu'il faut rentabiliser le projet (et je suis tout à fait d'accord) mais, sur exemple de uptime robot, j'ai 50 scans (ce qui est trop) illimité dans le temps, mais ils limitent le temps entre chaque ping, ils limitent les foncitonnalités. Après c'est un choix marketing et je respecte, mais sachant qu'il existe moins cher ailleurs, est-ce que le public sera au rendez vous ?

Cordialement :)

Mince, les mails de notification Grafikart passent en spam chez Gmail, je n'ai pas vu vos réponses, désolé pour le retard ! Il y a des points très intéressants soulevés ici, je prends du temps pour y répondre proprement cet après midi :)
Merci à vous tous pour le temps que vous avez passé à regarder et essayer ! C'est vraiment des retours précieux pour nous (qui ne sommes en effet pas graphistes, ni UX :) )

@jchr :

"c'est assez facile à faire sur son propre raspberry pi"
C'est partiellement vrai :) tu vas dépendre d'un seul provider internet, et pour la partie alerting, tu vas devoir développer des choses également, pour évider le flood d'alertes. L'idée de l'infra que l'on monte, c'est de proposer un service monitoring redondé en cas de pb, et d'industrialiser les monitoring. J'ai également commencé à monitorer mes sites web avec des scripts custom et des daemons, mais ça reste du bricolage dans un garage (et c'est loin d'être péjoratif venant de moi :) )

"si le site semble down prendant plus d un certaint, tu proposes de le rediriger vers un autre serveur ouvers un site de substitution static (que tu héberges chez toi ou pas )."
On y a pensé, mais ce n'est pas notre métier de router du trafic web, je n'ai pas les compétences pour monter un service d'hébergement web qui soit plus robuste qu'un hébergeur web dont c'est le métier. Il y a deux options :

• prendre en charge l'ensemble du trafic, à la manière de Cloudflare, et de le dispatcher sur un serveur quand tout va bien, ou sur un autre quand ça va pas. Ça requiert une expertise très importante et des moyens réseaux/hosting importants.
• modifier la zone DNS du client (plus réalisable) mais on tombe alors dans le je déplace le pointage du/des records A de la zone, ça va prendre entre xx minutes et xx heures pour être totalement effectif quid d'un incident qui va durer 5 minutes, puis revenir ? C'est un peu tirer à l'arme lourde ici, et l'impact peut être long, le temps de la propagation DNS

"envoyer un message directement au serveur pour qu'il exécute des protocoles bien précis tel que le redémarrage, arrêt des systèmes de payements , etc"
Ça c'est prévu, je vais développer un système de webhook, afin de notifier via un call http et un content JSON à une url cible du client, d'un incident en cours. Libre ensuite pour le client de faire ce qu'il souhaite de cette information.

"Pour bien faire (je ne suis pas sur que c est possible) il faudrait savoir si c est une attaque groupée où le dev sait intervenir ou pas ."
Alors c'est possible puisque l'on arrive à dire "oh, OVH a un pb, quand on voit plusieurs dizaines de sites tomber au même moment", mais à industrialiser la détection, ça va ralentir un peu le process d'alerte. Je vais réfléchir à cette éventualité, c'est une piste intéressante

@galyb :

"générer des rapports détailler. C'est surtout pour permettre d'appuyer des retours sur des hébergeurs ou sur de la maintenance applicative. (tous les mois ou semaines par exemple). Et teste de ping à partir de différent continent."
Nous envoyons déjà un rapport hebdomadaire par URL monitorée, et un rapport mensuel, avec uptime et les différents incidents constatés, est-ce que tu verrais autre chose ?

@Gynidark :

"J'ai l'impression que c'est un thème qui a été repris et qui a été maltraité."
Je dois bien l'avouer pour le front office, une fois connecté :/

"- le select pour sélectionner la langue. Pourquoi il float comme ça en plein milieu de la page ?

• Vous êtes déjà inscrit ? Connectez-vous" ça devrais pas être le contraire ? Le but, c'est d'avoir des nouveaux utilisateurs non ?
• Déjà # vérifications effectuées et # incidents signalés." pourquoi il n'est pas centré verticalement/horizontalement ?
• J'aurai ajouté une transition dès l'hover de t'es boutons afin d'avoir des boutons fluides."
  Pour cette partie là, je transmets à mon associé, qui s'occupe de la partie front office, afin qu'il regarde tes remarques et les prenne en compte :) ça me dépasse un peu pour être honnête, n'étant pas du tout porté sur l'UX/design, il sera plus à même de comprendre et corriger :)

@dryusdan :

"ça manque de graphique je trouve, pas de graphique sur le down, sur le nombre de site tombé... Avoir un graph sur le temps de réponse de son site serait génial je pense ;)."
Alors pour ce qui est des graphiques de temps de réponse, il y a déjà, par contre, il n'y a pas de graph d'incidents en prod, j'ai produit ça il y a quelques jours mais ce n'est pas encore en prod sur le front office. Il va y avoir en effet un graph de durée d'incidents par heures, afin de visualiser les périodes de problèmes.

"Après les points négatifs : le temps ! on ne peut pas choisir 2 minutes par exemple. Bon, après je pense que tout le monde choisis 30s (j'ai préféré une minute ^^ )"
Pour cette partie là, j'ai envie de dire qui peut le plus, peut le moins :) Est-ce que c'est impactant pour toi des checks trop rapprochés ?

"Le deuxième chose négatif, c'est le temps d'essais... 30j, pour 10 interfaces"
Oui, pour ça c'est vraiment un choix marketing, je ne sais pas si ce sera le bon, mais on n'est pas parti sur un mode de fonctionnement avec un plan freemium, il sera sans doute toujours temps de changer dans quelques mois si l'on voit que les gens n'adhèrent pas du tout :)

J'espère avoir répondu à toutes les questions de tout le monde ?

Merci beaucoup à tous encore une fois, de prendre le temps de tester et de me remonter vos avis/critique, c'est juste top d'avoir ces retours pour avancer.

Simon

Est-ce que c'est impactant pour toi des checks trop rapprochés ?

Pas le moins du monde.

Hello !

Un petit update sur une feature en cours de développement, le monitoring de scénarios HTTP, afin de monitorer un back office par exemple, un petit aperçu du formulaire dynamique permettant de construire le check :

A noter que rien n'est inséré en clair en base de données pour ce qui est des valeurs de champs POST, le front office chiffre les données en utilisant une clé publique, et ne possède pas la clé privée de déchiffrement, uniquement présente sur les serveurs de monitoring (RSA 4048 bits).

Les mots de passes stockés sont donc en sécurité en base.

Ça avance ça avance, d'ici quelques semaines la feature sera disponible, sans doute avant ça en bêta :)

Si vous voulez tester Doyoucheck d'ici là, toujours la même adresse https://doyoucheck.com/fr/

et juste parce que ça donne un peu le tournis (à moi au moins), on a passé les 1.11 milliards de vérifications HTTP effectuées depuis que l'on a commencé à les compter sur nos ptits doigts musclés, et un peu plus de 1M d'incidents reportés sur les sites monitorés.

On stocke donc à l'heure actuelle environ 800 millions d'entrées de données de monitoring en database (pas MySQL)

Woop woop :)

Salut,

Déjà pour te dire que ton projet a l'air vraiment bien et j'espère qu'il continuera à evoluer ! Bravo
J'ai dans l'optique de m'inscrire :)
J'aime beaucoup la feature qui est en cours de développement. Donc si je comprends bien d'après l'exemple, si l'expression est affiché, l'utilisateur sera alerté qu'il y a une incidence ?
Et est-ce que tu gères s'il y a une redirection vers la page de maintenance par exemple ?

Bon je vais faire une critique mineure (qui sert à rien) mais ça peut apporter quelque chose
Ton background entre la page visualisation https://app.doyoucheck.com/p/register et https://doyoucheck.com/fr/ n'est pas à la même position. Est-ce normal ? Voulu ?
Faut bien trouver une petite critique sinon c'est pas drôle ahah

En tout cas bravo et continue comme ça ! Par curiosité si ce n'est pas trop indiscret, vous avez utilisé quoi comme techno ?

Bien à toi,

Jérémie

Salut Jérémie,
Merci déjà pour ton feedback :) C'est en perpétuelle évolution depuis environ un an, et ça continue. Pour l'instant le service est limité aux vérifications http, mais il sera implémenté des vérifs dns, smtp, ping par exemple.

En fait, ce que tu cherches à faire, c'est get une page et vérifier si un pattern est présent ? Si oui, c'est déjà opérationnel et en prod sur le service existant. La feature en cours de dév est à utiliser pour monitorer un formulaire par exemple, ou un succession d'actions, comme "je get une page login, je poste mes identifiants, puis je get la page mon profil, et je me déconnecte" et si la chaine est exécutée sans pépin, alors tout roule, sinon s'il y a une étape où ça coince, je veux recevoir une alerte.

Les redirections sont bien gérées, le monitoring suit les redirections dans la limite de 5 il me semble que j'ai fixé, et regarde le résultat final.

Mmmm pour ce qui est de la position des blocks dans les pages, je dois dire que ce n'est pas ma partie, je vais donc remonter à mon associé qui s'occupe du développement du Front office afin qu'il regarde ça :)

Comme technos, il y en a plusieurs majeures, Mysql 5.7 pour le stockage des incidents, des users, des plans, de tout ce qui ne nécessite pas d'avoir des millions d'entrées, et pour le moment Influxdb pour la partie stockage des points de monitoring. Rabbitmq est également utilisé pour gérer les actions asynchrones et les transmissions de données inter serveurs.

Et une flotte de VPS un peu partout dans le monde pour fournir des analyses depuis plusieurs pays, chacun des serveurs de l'infra étant redondé par au moins un serveur slave.

Voilà voilà, et bonne soirée :)

Simon

Salut,

Si la page du formulaire en POST nécessite un paramètre CRSF, ça se passe comment ? Tu peux récupérer une valeur avec un selecteur dans une page chargé en GET et l'utiliser ensuite ?

En voilà une super question qu'elle est bonne... Le cas des tokens CSRF stockés en session est déjà géré puisque les cookies sont conservés et transmis durant toute la transaction, mais je n'avais en effet pas du tout envisagé le cas où le token serait placé dans le formulaire en champ hidden... Il faut que j'y réfléchisse, c'est une excellente remarque, merci !

@tleb est-ce que tu as un exemple perso de formulaire sécure avec un champ hidden que je pourrais essayer en live ?
Je comptais déjà intégrer une feature de variables au sein des transactions http, mais c'est un cas auquel je n'avais pas pensé

Premier site qui me vient en tête qui gère pas tout en front, derrière une API : zestedesavoir.com

Sinon, tu peux te créer un tout petit serveur qui simule un token csrf avec un random dans le formulaire