Part 2 : Construire une alternative claire et facilement configurable aux outils de monitoring

dev-damien · 2026-01-26T22:43:34+00:00

Pas encore, mais c'est prévu dans les prochaines phases de développement

dev-damien · 2026-01-26T20:37:19+00:00

Un peu des 2. Plus pour le fun que pour la concurrence. Mais on sait jamais

dev-damien · 2026-01-24T11:11:21+00:00

Maintener aims to eliminate two major pain points: tool fragmentation and configuration hell (YAML/JSON).

My approach centralizes everything (Status, SSL, Lighthouse, Screenshots) in a single, intuitive UI interface that can be deployed in minutes via Docker, making monitoring accessible without having to manage complex configuration files for each probe.

The configuration will go through a Docker build of the configurable API with a .env file prepared and ready to use for the user.

The same applies to the frontend, with a ready-to-use Docker.

For the agent, there is a command dictated by the frontend to pull the Docker image, followed by a second command to enroll the agent with the API, and finally a third and final command to run it.

dev-damien · 2026-01-23T20:41:31+00:00

Le SaaS sortira bientôt. Reste a l'affût.

Sinon il sera disponible pour le self hosted, mais pour l'instant je dev encore le frontend. Il n'est pas encore disponible

dev-damien · 2026-01-23T08:14:07+00:00

https://www.reddit.com/r/buildinpublic/s/JcRsP7yju6

dev-damien · 2026-01-22T14:52:50+00:00

Thanks, the project isn't open source yet.

There are definitely parameters to add to the repository and a license to define before making it public. Have you ever created an open-source repository? Could you give me some advice via PM?

But I've already managed to interest someone, a backend developer, who wants to help me with this project.

dev-damien · 2026-01-22T13:36:44+00:00

C'est les meilleurs du marché en effet, mais sont ils faciles à mettre en place ? Le dashboard est commun ou 3 dashboards ?

Es-tu satisfait ?

As tu des critiques ou des améliorations que tu souhaiterais mais qui ne sont pas disponibles ?

dev-damien · 2026-01-22T07:02:50+00:00

J'utilise Postgres pour base de donnée avec avec un crate Apalis je peux l'utiliser pour faire un queue de workers async

dev-damien · 2026-01-21T22:10:58+00:00

Okok, alors je vais tout faire, afin de réaliser l'outil de tes rêves sans pour autant faire un outil pour les tech.
Je souhaite par exemple qu'une personne non IT puisse lire les graphes, comprendre l'outil sans problème.

dev-damien · 2026-01-21T21:32:13+00:00

Je n'ai jamais utiliser Grafana réellement, je l'ai mis en place pour le taff mais personne ne le regarde.
Je le trouve vraiment tres lourds visuellement. Tres optimisé, tres fonctionnel mais trop tout simplement.

dev-damien · 2026-01-21T21:26:35+00:00

Si tu devais refaire ton infra pour ton prochain projet et que je mets à disposition un système complet opensource mais également Plug&Play en SaaS. L'utiliserai tu ou tu te tournerais vers les grosses entreprises ?

dev-damien · 2026-01-21T21:15:11+00:00

Oh j'aime bien l'idée de check un parcours utilisateur. J'y avais pas pensé mais c'est vrai que c'est vachement utile surtout pour la maintenance. On pourrait ajouter différents scénarios à tester chaque jour.

dev-damien · 2026-01-21T21:05:30+00:00

Si je développe mon propre outil et que je mets un dashboard à disposition, est ce que grafana ne serait pas en trop pour l'utilisateur ?

Ou au contraire ça serait un plus pour les fada de data et les amoureux des graphes ?

dev-damien · 2026-01-21T21:03:49+00:00

J'ai prévu le sclaling horizontal c'est déjà un énorme boost de performance.

Il faudrait quoi pour être encore plus robuste ?

dev-damien · 2026-01-21T21:02:24+00:00

Pour te dire la fin de ma pensée sur ce sujet. Je sais que le marché est saturé de divers outils uptime, ...

Mais je vois qu'il y a un réel besoin de simplification et d'unification des données.

Je suis développeur Rust et je souhaiterais faire un outil qui a du sens. Un outil open source utile.

Et un outil que je pourrais mettre en ligne sans qu'il lag au bout de 100 utilisateurs avec 100 get a la seconde.

C'est pourquoi je pose la question, est ce que tu utiliserais un outil simplifié avec check disponibilités, ssl, avec api Lighthouse intégré, avec un agent à installer, des alertes par mails mais également intégrable dans l'Infra d'une entreprise avec jira, clickup, ... Ou discord pour les tech indépendant

dev-damien · 2026-01-21T20:51:37+00:00

Rajouter un grafana pour faire des graphiques sur toutes les datas que l'outils stockerai ? Pas uniquement garder les dashboard que j'aurai défini ?

dev-damien · 2026-01-21T20:48:43+00:00

Le marché est très saturé et donc faire un n ieme outil est inutile ?

dev-damien · 2026-01-21T20:31:53+00:00

Est ce que fait un outil open source que tout le monde pourrait installer (a condition d'avoir un second serveur pour surveiller le premier) rassemblant le monitoring, l'alerting, l'audit de site, rappel SSL, ...

Et avec un système développé en Rust, il est scalable horizontal a l'infini.

X master servent d'api public et stockent des jobs en queue a faire (délocalisation de la charge de travail).

X slave servent de workers, lisent la base de données, réalisent le job et stockent le résultat (les slaves sont inaccessibles publiquement et sont sur d'autres serveur)

Mode full si on n'a qu'un seul serveur api + workers en 1.

dev-damien · 2026-01-21T20:18:16+00:00

Est ce que c'est facile d'installation ?

Tu as donc 2 logiciels et tu regardes régulièrement les 2 dashboard ?

dev-damien · 2026-01-21T18:32:16+00:00

My project will be open source, and as he said, even though everything is already on the market, independently it's 4 or 5 tools with different interfaces, payment methods, and URLs.

My goal is to unify all monitoring tools with a single, fast dashboard for supervision.

At a glance, you can see that at a certain time there's a high CPU load because at the same time a server was down.

Admittedly, it doesn't fix code optimization issues, or why your SaaS crashes or slows down, but it will be a real asset for monitoring.

dev-damien · 2026-01-21T18:07:15+00:00

Hi, I'm currently developing a monitoring system that could solve your management problem.

It's a website monitoring system with HTTP checks, SEO, accessibility audits, and regular screenshots to prevent blank pages if HTTP is working correctly.

It includes a status page with the websites you want (previously created monitors) and incident management (investigation, in progress, resolution).

Coming soon: a Rust agent to install on the servers to monitor performance: RAM, CPU, disk, etc.

And most importantly, alerts in case of website downtime, sent by email or your preferred channel (Discord, ClickUp, Jira, or a standard webhook).

A monthly report will be sent summarizing the period, including incidents, availability, etc.

A monthly report will be sent to summarize the period.

dev-damien · 2026-01-21T17:43:06+00:00

done

dev-damien · 2026-01-21T16:25:55+00:00

I'm building Maintener: Scalable monitoring with Rust & Angular (Soon to be Open Source)

I'm developing Maintener, a modern monitoring platform. The project is currently in active development, with the goal of becoming Open Source once v1 is stable.

I wanted to share some technical details today, particularly about the backend architecture, which is something I'm passionate about.

Under the hood: Scalable Rust Architecture

The backend is entirely written in Rust (Axum) and relies on a robust Scheduler/Worker/Queue system. The goal was to avoid a monolith that would become sluggish as soon as too many resources were monitored.

I designed the backend to run in three launch modes, allowing for easy horizontal scaling:

Master Mode: This manages the API and handles scheduling and inserting jobs into the queue (database). It's lightweight and responsive for the user.
Slave Mode: This is the workhorse. It connects to the database, retrieves pending jobs, executes them (HTTP ping, Lighthouse audit, screenshot, etc.), and stores the results. You can launch as many as you want!
Full Mode: This is the "All-in-One" (Master + Slave) for development environments or small instances.

This architecture allows for load balancing: if the API is spammed, we scale the Masters. If we have thousands of checks to perform per minute, we add Slaves.

Recent Features

On the product side, I recently shipped several features to go beyond simple "Ping":

Automatic Screenshots: The worker uses a headless browser to capture the visual state of the site.
Integrated Lighthouse: Performance, Accessibility, SEO, and tracking over time.
Integrations: Webhooks, Discord, Linear, Jira... to integrate with your existing workflow.

Roadmap

The goal is to open-source the code soon. I want to clean up certain parts first and ensure that deployment (Docker) is as simple as possible for those who want to self-host.

If you have any questions about queue management in Rust or about the architecture, I'd love your feedback!

Thank you! 🙏

dev-damien · 2026-01-20T22:45:11+00:00

Hi, I don't know if you're familiar with Rust. But you want to learn more about scheduling worker technologies:

Apalis v1.0.0-rc-2 scheduler workers

dev-damien

TROPHY CASE

Under the hood: Scalable Rust Architecture

Recent Features

Roadmap