# Monitoring

En terme de monitoring de la High Availability, Muppy permet de:

* Visualiser le statut de la **High Availability** d'un RCS
* Inspecter les **daemons pglookout**
* D'inspecter le journal des évènements de la HA **(HA Event Log)**

## Statut de la High Availability

L'icone HA Active avec le Spinner vous informe que la High Availability est active sur un RCS.

![Indicateur du statut de la High Availability](/files/xUKK9QTdYPb6Q1cRy4RY)

Si la HA n'est pas active, l'indicateur de statut est le suivant: \
![](/files/J3L7Ku7LMbqguT1Mjvqn)

## Inspecter les daemons pglookout

Dans l'onglet High Availability, Muppy affiche la liste des daemons pglookout et permet de les inspecter.

![Liste des daemons pglookout d'un RCS](/files/NQCPDwwuFGG4c6CxKkIE)

Veuillez vous référer à la page [pglookout Heartbeat](/guides/postgresql/postgresql-ha/pglookout-heartbeat.md) pour la signification des colonnes State et ... cnx.

Lorsque vous cliquez sur une des lignes correspondante à un daemon pglookout, le formulaire suivant s'ouvre et donne accès à toutes les informations et opérations disponibles pour ce daemon:

### Formulaire d'un daemon pglookout

{% hint style="info" %}
Actuellement le daemon déployé sur chaque Cluster est un pglookout. A terme, il est possible qu'un autre type de daemon soit déployé ; une évolution de pglookout nommée mpypgd. C'est pour cette raison que vous verrez parfois le terme mpypgd.
{% endhint %}

![Formulaire d'un daemon pglookout](/files/dDsSqDO1SOHqUzDGcNM1)

Les informations suivantes sont disponibles sur le formulaire:

1. Le statut du daemon ; Ok ou Non installé
2. Le **Host** sur lequel le daemon est installé
3. **Owner PG Cluster** ; le Cluster dont le daemon est responsable.

   Il est possible d'installer des daemons dits "**observers**" qui ne sont responsables d'aucun Cluster mais uniquement présents pour alimenter l'algorithme de consensus avec des statistiques de réplication collecté depuis un autre point du réseau.
4. **State URL** ; le daemon contient un petit serveur http qui publie les statistiques sous forme de JSON. Ceci indique l'URL et le port qui publient les statistiques. Un clic sur l'URL ouvre les statistiques dans une nouvelle page.
5. **Systemd Service** ; Muppy déploie le daemon comme un Service Systemd. Cette ligne permet d'ouvrir l'objet Muppy Systemd Service qui permet de configurer et contrôler le service (Voir la page[Systemd Service Units](/guides/muppy-core/systemd-service-units.md))
6. La **Configuration** du daemon.&#x20;

Les commandes suivantes sont disponibles via le bandeau de boutons supérieur :

* <img src="/files/ByT42Uul3tTIKQhkbBOt" alt="" data-size="line"> ; lorsque vous cliquez sur ce bouton, Muppy récupère les statistiques de réplication en se connectant sur la **State URL** et les utilise pour mettre à jour les statistiques de réplication du RCS ( Voir [Suivre la Replication](/guides/postgresql/postgresql-replication/suivre-la-replication.md) ).
* <img src="/files/NOUT3Oq3buwTrZX0zeGx" alt="" data-size="line"> ; lorsque vous cliquez sur ce bouton, Muppy recalcule la configuration et l'injecte dans le **daemon**.
* <img src="/files/GAbRKWPi9jgtxx4cQ5Xh" alt="" data-size="line"> ; lance la réinstallation complète du daemon.
* <img src="/files/pSsxiixtrV23VBww38TD" alt="" data-size="line"> ; désinstalle le daemon et reconfigure tous les autres daemons. Comme chaque daemon se connecte à tous les autres Clusters, en cas de suppression d'un daemon, il est nécessaire de re-configurer tous les autres.

## HA Events Log

Dans Muppy, la plupart des évènements liés à la High Availability sont consignés dans le **HA Event logs**. Celui-ci est accessible en cliquant sur le bouton **"HA Event Log"** situé en entête du formulaire des RCS.

![Le bouton HA Event Log](/files/DgPEiGaMc6Y5RQuFhO1b)

Lorsque vous cliquez sur ce bouton, Muppy ouvre une table qui contient tous les évènements liés à la Haute Disponibilité. Vous pouvez utiliser cette table pour reconstituer - Post Mortem - la chronologie d'un Failover.

![Extrait d'un HA Event Log du warning au Failover](/files/zgDcgDs35OUL3MNlf0uT)

Les évènements **QUERY\_STATE** contiennent le détail des statistiques de Replication relevé à ce moment là. Sur l'exemple suivant, on remarque que le Primary ne répond plus et on peut déterminer le Standby avec le lag le plus faible.

![Exemple de HA Event Log de type QUERY\_STATE](/files/rZCOjuS97haf7EoZOrVp)

### Purge du HA Event Log

Muppy purge, automatiquement, toutes les 6 heures, les évènements du **HA Event Log** âgés de plus de 740 heures (31 jours environ).&#x20;

La purge est gérée par la Scheduled Action  **Worker**  **"Muppy: PostgreSQL - Purge Ha Event Log"** accessible via le menu **Settings / Technical / Automation / Scheduled Actions**.

Si vous avez Muppy Enterprise, vous pouvez modifier la période de rétention et la fréquence de la purge à partir du formulaire de la Scheduled Action:

![](/files/yUtEffccbxdTsruLjCfX)

1. permet d'ajuster la fréquence de la purge
2. permet de modifier la période de rétention

Cliquez sur le bouton <img src="/files/Nlcz6vMzfS6TLMP6vcpx" alt="" data-size="line"> pour enregistrer vos modifications. Elles s'appliqueront à la prochaine exécution (**Next Execution Date**). Vous pouvez cliquez sur ![](/files/3yXbJO2PhIvDiYJBRFzu) pour lancer *une* purge immédiatement.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.muppy.io/guides/postgresql/postgresql-ha/monitoring.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
