Un outil expérimental qui indique la disponibilité des services des chatons?

Bonjour les chatons :smirk_cat:

Le site stats.chatons.org propose une fonctionnalité qui est encore en développement, mais qui nous semble assez digne d’intérêt – et éventuellement sensible – pour en discuter dès maintenant. Cette fonctionnalité affiche la disponibilité « réelle » des différents services fédérés par le collectif.

Kesskessé ?

Vous la retrouverez à l’adresse https://stats.chatons.org/chatons-uptimes.xhtml ou simplement depuis la page d’accueil ou directement sur celle d’un chaton, en cliquant sur l’îcone qui affiche un radar :
countdown-mono

L’outil va vérifier la viabilité des liens sur la page d’accueil du service, toutes les heures, ce qui permet d’avoir un regard sur l’état de disponibilité du-dit service.

En fonction des retours successif sur la journée, le voyant s’affichera de différentes couleurs :

  • vert, retours « ok » sur la journée,
  • jaune, retours « erreurs » sur la journée mais dernier retour « ok »,
  • orange, retours « ok » sur la journée mais dernier retour « erreur »,
  • rouge, retours « erreurs » sur la journée.

Pour l’instant, la page montre le retour sur les trois dernières semaines (enfin, depuis hier !), sur l’ensemble des services référencés sur ChatonsInfos.

Ce n’est que le début

Cette fonctionnalité en est à ses balbutiement et va connaître des changements rapidement, la pertinence des résultats qu’elle donne est encore à évaluer et la façon dont elle les donne aussi (et, bien sûr, il sera possible de trier le tableau).

On peut encore imaginer de nombreux usages à cette fonctionnalité, qui avec certes un léger monitoring participe à la transparence sur l’offre des services des chatons. Sur le moyen-long terme, c’est par exemple un indicateur qui pourrait permettre de diriger les utilisateurs vers des services disponibles.

Parlons-en !

Vous l’aurez compris, nous sommes très enthousiastes au sujet cette fonctionnalité – encore expérimentale – qui pourrait se révéler très pertinente – tant au sujet de la qualité des services que de l’accessibilité à ceux-ci.

J’ai aussi mis un point à l’ordre du jour de la réunion virtuelle mensuelle de juin de la semaine prochaine afin que l’on puisse en discuter, car avoir vos retours sur cette fonctionnalité expérimentale qui n’était pas prévu pour stats.chatons.org initialement nous semble primordial.

Miaou,

Antoine pour le GT ChatonsInfos :kissing_cat: :sparkles:

10 Likes

MAIS C4EST FOR MI DA BLE !!! Diablerie , super outil !!!

1 Like

Mais attend un peu, c’est super ça ! Est-ce qu’il est envisageable de recevoir un email quand un de nos services passent du vert au orange ?

2 Likes

C’est TOP !

Par contre je remarque que certain service sont en rouge / orange pour Zici : https://stats.chatons.org/zici-uptimes.xhtml

  • https://pastebin.zici.fr/ il dit ERROR 403 alors que je ne la constat pas … de votre côté ?
  • agenda a une indispo vers 4h… c’est l’heure de la fin des sauvegardes… peut être une petite indispo dû a une latence de réponse, mais du coup ça risque d’être souvent Orange (selon la chance entre la vérifie/les sauvegardes) est-ce qu’une seconde tentative peut être émise avant de considérer que c’est injoignable ? (a voir si je suis le seul, si c’est récurent… sinon c’est bien comme ça)

David

1 Like

tester de mon coté, j’y ai bien accès :slight_smile:

Damned ! Visiblement, j’ai pas renseigné les bonnes adresses sur certains services d’ARN. C’est l’occasion de mettre à jour nos .properties car je l’avais fait vraiment au tout tout début…

Par contre, y en a un qui est disponible mais qui pourtant s’affiche en rouge.

La feature a priori ne fonctionnera pas vraiment si on tombe sur la page de connexion du SSO de YunoHost… Je veux dire le service pourrait être en panne que ça s’affichera quand même vert.

Un grand merci pour vos retours et votre enthousiasme. Le fait que cette nouvelle fonctionnalité puisse aider à améliorer la qualité des services, c’est réjouissant :smiley:
Je vais tâcher d’apporter des réponses bientôt :blue_heart:

Oui, voilà exactement l’usage espéré. Top merci pour les mises à jour :smiley_cat:

Je confirme. Un curl me donne également une erreur. Cela t’inspire-t-il ?

curl -I  https://vps.arn-fai.net/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

Oui. Le principe a ses limites, seule la porte d’entrée est vérifiée, ça ne dit rien sur ce qu’il y a derrière. On peut se dire que dans un premier temps, c’est déjà ça. À voir par la suite comment améliorer, on pourrait envisager un champ property optionnel supplémentaire pour une URL plus pertinente…

Alors, en fait, tout le monde a raison :

curl -I -A "StatoolInfos" https://pastebin.zici.fr/
HTTP/1.1 200 OK
curl -I -A "StatoolInfos Bot" https://pastebin.zici.fr/
HTTP/1.1 403 Forbidden

Le fait est que pour tester la disponibilité des services, j’utilise la valeur de UserAgent « StatoolInfos Uptime Bot ». Pour ce site, la présence du mot clé « Bot » semble entraîner systématiquement un 403.
Il me semble poli d’indiquer dans le UserAgent que c’est une requête de bot. Et c’est information est très utile pour filtrer les logs HTTP quand on génère des métriques. Du coup, une possibilité simple de votre côté ?

Ça me semble une bonne idée. Nous sommes nombreux à être concernés par une indisponibilité passagère à cause des sauvegardes :smiley:
Je vais voir comment coder ça, mais ça va sûrement prendre un peu de temps :slight_smile:

Hooooooo, voilà une fonctionnalité à laquelle je n’avais pas du tout pensé. C’est tout à fait envisageable. Ça soulagerait le travail de revue des services indisponibles. Va falloir creuser les critères et évaluer la fréquence des faux-positifs mais ça semble très intéressant. Merci pour la proposition :smiley:

Une règle qui pourrait être appliquée :

  • si le test se solde par un échec --> loupiotte orange
  • au bout du 3ème échec consécutif --> loupiotte rouge + mail de service KO
  • si le test se solde par une réussite, juste après une loupiotte rouge --> loupiotte verte + mail de service OK

Voili, voilou…

Super idée :slight_smile:

Je ne sais pas si tu connais:

Plutot que de dev un nouveau logiciel, transformer le properties en fichier de conf pour celui ci me parait plus simple.

UptimeRobot va appliquer sa nouvelle grille tarifaire, il va falloit qu’on bouge :slight_smile:

Bon courage pour la suite!

Effectivement le 403 est proposé au UserAgent « bot », c’est pas défaut dans privatebin : https://github.com/PrivateBin/PrivateBin/blob/de8f40ac1a8b43fe6aa6a7a2fb1ab370ee62b438/.htaccess.disabled#L3

Désactivé de mon côté…

Bien vu. Et détecté à l’heure suivante :
image

Merci à toi :smiley_cat:

Génial outil
… Et merci pour le retour sur mon Mastermost : corrigé :slight_smile:

Une petite limitation à cette fonctionalité.
Cela marche très bien pour vérifier un outil mutualisé (ex: Mastermost justement).
Par contre, pour un outil proposé dédié à l’utisateur (ex: une instance WordPress), on a pas la possibilité d’indiquer l’ensemble des URL de toutes les instances hébergés
A réflechir donc pour pouvoir supporter (ou pas), ce cas

Et maintenant, l’indicateur est au vert. Merci à toi :smiley_cat:

Je confirme que ce cas n’est pas couvert par l’outil. Comme il s’agit d’instances dédiées, on pourrait dire que c’est une offre de services et non un service. Du coup le fichier service.properties n’est pas applicable et il faudrait un autre type de fichier properties, dédié. Cela a été évoqué également pour les offres d’hébergement matériel (baies…). Un ticket est ouvert.
Actuellement, l’objectif est d’arriver à terminer la couverture des services « simples ». Merci pour ta remontée du sujet car il y a plusieurs membres dans ce cas :cat2:

1 Like

Merci du retour,

Du coup le fichier service.properties n’est pas applicable et il faudrait un autre type de fichier properties, dédié.

Oui, en effet, dans ce cas, pour la property service.website (obligatoire), j’ai mis alors l’url de mon site web.
Peut-être dans ce cas, mettre l’url d’un fichier text balise indiquant que ce service est sous forme d’instances dédiés (et donc un nouveau status pour le statistiques).
La problématique pourra se résoudre avec les metrics d’usage des services: on pourrait alors avoir un nombre d’instance (total et en erreur).

Merci du travail en tout cas, je suis fan :slight_smile: