---
tags: fsd@EPFL, fsd
---

[TOC]

# WP-OPS notes and todos

# Backlog

## WP-Manager

- [ ] Se débarasser de wp-manager : nécessite le fait de pouvoir lister la liste des plugins et leurs versions installées + disponibles pour savoir s'il faut mettre à jour. Exemple: wp-media-folder, version installé = 2, version disponible = 3 → il faut le mettre à jour.
- [ ] Les nouvelles versions sont affichées sous le nom du plugin dans la liste sur wp-admin
- [ ] Les versions des plugins hebergé sur wordpress.org sont disponibles via l'API (https://codex.wordpress.org/WordPress.org_API#Plugins), par exemple https://api.wordpress.org/plugins/info/1.0/polylang.json. WP Media Folder n'est PAS hébergé sur wordpress.org mais sur joomunited...

## Openshift / infra

- [x] Déplacer le monitoring interne sur wp-infra, du moins préparer le terrain

## Alert-tg-bot et alertmanager

- [ ] Remettre des alertes par mail et les tester, dans le but de pouvoir utiliser [e-mail] avec le NOC
- [] Recevoir une alerte par mail pour les backups.
Mais les sites supprimés ont encore présent dans la pushgateway
Que faire? Proposition: lors de la suppression du site,
on fait un dernier backup (à vérifier), on en profite pour ajouter/modifier la valeur d'un label pour exprimer le fait que le site est supprimé. Ainsi nous pourrons filtrer les sites supprimés dans la requete prometheus du printscreen => (time() - restic_success{job="backup",wp_env!="sandbox"}) / 3600 > 48 => donne moi tous les sites sont les backups ont plus de 48h.

- [ ] Dans le but d'alerter les utilisateurs, utiliser les alertes mail et les groupes https://cadiwww.epfl.ch/listes/viewlist?list=[e-mail] ou https://cadiwww.epfl.ch/listes/viewlist?list=[e-mail] en fonction de l'unité de rattachement des sites.

### Nouvelles métriques (blocs, plugins, etc.)

De manière générales, certaines métriques sont encore nécessaires et non accessible via l'API de wordpress. Voici une liste de métrics que nous pourrions avoir à moyen termes :

- [x] Coming soon → on doit savoir si le comimg soon est actif/armé.
- [x] Checker si le plugin est présent
- [x] Checker si le plugin est activé ou non
- [x] Si le plugin est activé, checker si le coming soon (ou la maintenance) sont armé
- [x] ...
- [x] Liste des plugins installés sur un site (trouver le bon format de métriques)
`wp_site_plugin{url="http://www.epfl.ch/",plugin="eww"} 1/0`
→ status, version ?
- [x] Blocks list : savoir quels sites (et quels posts/pages ?) utilistent tel ou tel blocks.
- [ ] Au même titre que les plugins, lister les thèmes présents et celui qui est actif
- [ ] Comme pour les pages, mettre les posts ?

### Amélioration du bot Telegram

- [x] `/silences` ne fonctionne plus sur la prod
- [ ] Lorsqu'on reçoit une alerte, il faudrait pouvoir identifier le site dans le pop-up de notification :
- [ ] comprendre la différence en Alerting et Firing
- [ ] checker le temps par défaut entre les alertes (est-il possible de recevoir les alertes toutes les 8 heures plutôt que le défaut à 3 ou 4 heures)
- [ ] améliorer les boutons:
- [ ] silence jusqu'au lendemain matin / lundi matin
- [ ] silence 1h pas utile
- [x] lien vers le silence de l'alerte
- [ ] et lien vers les silences du groupe de l'alerte
- [ ] Améliorer les alertes, par exemple site is not 200 n'est pas très parlant, il faudrait mieux être explicite: site status code = 404
- [x] Trouver une solution pour que le bot de test soit actif que lorsque nous en avons besoin, c'est à dire, ne pas envoyer de notification le reste du temps.

## Probers (WWP) (wpprobe / disk-size-usage)

Les metrics du prober sont actuellement des informations concernant les menus et les langues des sites wordpress.
- [x] Question : est-ce que tous les sites unmanaged sont des wordpress ? Si oui, on pourrait les remettre dans le configurator et les exclure du check des menus.
> Oui mais ils sont voués à disparaitre. Est-ce que cela vaut la peine d'améliorer le prober pour qu'il sonde les unmanaged sans les menus ?
- [x] Creuser les containers "disque size" et remonter des infos, par exemple taille de wp-content de chaque site, etc...

## Pushgateway (WWP)

Pour le moment, le pushgateway "wwp" reçoit des metrics via un curl uniquement lorsque les commandes Ansible -t wp.backup sont lancées.

- [x] Confirmer qu'une tâche "AWX" fera cela de manière journalière
- [x] Ajouter des metrics, tels que l'espaces disques ou des informations qui ne pourraient pas être recueillies via site/wp-json/..., par exemple des informations sur les plugins.

## Blackbox exporter (NOC)

- [ ] Checker les règles du blackbox exporter pour éviter des alertes inutiles ou des faux positifs, par exemple un site retourne HTTP 200 alors qu'il ne devrait pas, etc...
- [ ] Le blackbox exporter devrait "remonter" les sites en "coming soon"
- [ ] Trouver un moyen de traiter correctement les nouveaux sites ajoutés dans wp-veritas mais qui n'ont pas encore été créés: par exemple, si site pas créé après X jours, alerter.

## Grafana (NOC)

- [ ] Tester un panel "alerting" : https://grafana.com/docs/grafana/latest/panels/visualizations/alert-list-panel/
- [ ] Faire une PR pour https://github.com/grafana/grafana/issues/2908
- [ ] Faire des aggrégations par préfix dans prometheus ou grafana ? (arbre dunombre de pages en partant de www.epfl.ch)

## Cloud-flare

- [ ] Trouver une solution pour monitorer les sites sans cloud-flare et sans mettre down l'infra (c.f. [§Problèmes](#Probl%C3%A8me-cache-cloud-flare)) / module `http_head` ?
- [x] Laisser canari en 200 et voir si uptime robot le voit un jour → non
- [ ] Cloudflare cache les page → le blackbox exporter ne peut donc pas les sonder correctement
- [ ] Solution 1: activer le `Origin Cache Contol` dans cloud-flare : problème: un attaquant peut l'utiliser.
- [ ] Solution 2: modifier le module http_get du blackbox exporter pour ajouter des cookies → \o/ Cookie:
- [x] curl -H "Cookie: wordpress_logged_in_test=on" -I https://www.epfl.ch/campus/service/canari/ versus curl -I https://www.epfl.ch/campus/service/canari/
- /!\ infra fragile !!!
- [ ] Solution 3: modifier les targets de prometheus pour ajouter un hash aux urls sondées, e.g. ?toto=tutu
- [ ] Solution 4: utiliser le prometheus-wwp (interne au cluster) pour prober les sites et utiliser le federate déjà en place. Cela sous-entend que le prober du NOC (externe) mesure cloudflare et que le prober wwp (interne) mesure en interne sans cloud-flare. Signifie également que nous pouvons voir les éventuelles différences entre les deux prober. Problème: le prometheus-wwp (interne) n'a pas actuellement de blackbox exporter.
→ Approcher c2c ?
→ Déplacer sur wp-infra
- [ ] Solution 5: créer un nouveau prober, e.g. en node.js, pour sonder les sites avec un cookie
- [-] comprendre pourquoi uptime-robot peut voir les status 500 (e.g. servir la debugapi sur idev-fsd.ml et voir les requêtes uptime robot. Hypothèse: un ?hash est ajouté à l'URL)
En fait il ne peux pas, c'était à cause du bypass cache de cloudflare.
- [ ] Faire un graph des caches MISS de cloudflare ?
* https://github.com/cloudflare/cloudflare-grafana-app/issues/2
* https://developers.cloudflare.com/analytics/graphql-api/tutorials/build-your-own-analytics
* https://grafana.com/grafana/plugins/cloudflare-app
* Voir aussi: https://github.com/vanadium23/cf-metrics et https://github.com/vanadium23/cf-metrics
* 💡 Faire une PR sur https://github.com/cloudflare/cloudflare-grafana-app pour ajouter ces metrics
* 💡 Faire notre propre exporter (DOJO)

# Objectifs généraux

- [x] POC : un graph grafana qui reprend des infos depuis prometheus qu'il aura récupérées depuis le prober wwp.
- [x] Encore pousser la modif `epfl-functions.php` ce jeudi
- [ ] Monitoring des backups : en tant que service manager je veux être avertis lorsqu'un site n'a pas été backupé depuis plus d'un jour.
- [~] Créer une alerte dans prometheus qui se base sur la différence entre les metrics `restic_start` et `restic_success` pour un même site. Ou de manière plus générale, lister tous les sites qui n'ont pas un `restic_success` depuis plus d'un jour.
- [x] Automatiser (depuis AWX?), le backup des sites
- [ ] Monitoring d'un site : en tant webmaster d'un site je veux recevoir un mail lorsque mon site est down pendant plus de 5 minutes.
- [x] En tant que wwp-members ou service manager, j'aimerais avoir un dashboard de l'état des 700 sites wordpress :
- [x] Nombre de sites UP / DOWN
- [x] Status des langues
- [x] Status des backups
- [ ] etc...

# Requêtes "utilisateurs" lors de la présentation
- [ ] Dans grafana, obtenir le nombre de pages accrochés au menu qui sont des custom links et/ou des liens vers un site enfants (nb de pages réélement actives) (demandeur Luc)
- [ ] Dans grafana, santé générale de la flotte => histogramme des points (les points sont attribués en fonction des métriques bonnes ou mauvaises). (demandeur Dominique)
- [ ] A discuter: comment créer de manière intelligente les points de santé ? Mélange de métrics: Site avec problème, vieux backups, etc. => créer une formule par site.
- [x] Blocs utilisés par site et inversement savoir qu'un site utilise tels ou tels blocs (demandeur Luc)
- [x] Plugins utilisés par site et inversement savoir qu'un site utilise tels ou tels plugins (demandeur Luc)
- [ ] Savoir quels liens "customs" d'un menu retourne un 404