View source for Naemon

'''Naemon''' has been identified as a simple and maintained solution for a Nagios-compatible monitoring system.

Shinken and Sensu have been dismissed as open core solutions.

== Naemon deployment and FreeBSD porting plan =

== Overview ==
To improve Nasqueron infrastructure monitoring, we propose a three-step approach using Naemon, a Nagios-compatible monitoring system.

Our 2024 test showed compatibility with FreeBSD is a reasonable middle-term goal, but need a sensible amount of work, especially for Thruk.

As we would like to seriously introduce monitoring in Fall 2025, we would suggest to start with a Linux solution, and carefully check and document what's working and what's not working on FreeBSD.

Hence a plan to ensure immediate monitoring coverage while preparing a long-term FreeBSD-compatible solution and potential upstream contributions.

=== Step 1: immediate monitoring ===
*Goal:* Deploy a working monitoring system immediately.  

*Actions:*
* Spawn a Debian or Rocky VM dedicated to monitoring on hyper-001
* Install Naemon on the VM
* Deploy critical check scripts returning exit codes 0 = OK, 1 = WARNING, 2 = CRITICAL
* Configure notifications to IRC, e-mail, etc.

*Outcome:* Nasqueron services are monitored immediately with script-based alerts, without waiting for full FreeBSD compatibility.

*Who to involve?* Dorian is currently busy with DNS and acme certificates, that's a good opportunity to write and submit checks for those core critical systems. Philectro starts to be interested by automation, it's probably a good idea to create a binome Philecto / Dereckson for the deployment.

*Note:* We know to maintain a monitoring solution is not "Baguette magique ! All is monitored" but takes time. By "immediately" we state our intent to focus on create a solid monitoring role on rOPS to deploy naemon, livestatus and Thruk, have a documentation/plan to add checks and be able to run the checks we already have in the repository.

== Step 2: FreeBSD Patch / Proof-of-Concept ==
*Goal:* Make Naemon suite fully functional on FreeBSD and create a working proof-of-concept.

*Actions:*
* Apply minimal portability patches locally (e.g., using `#!/usr/bin/env bash`, adjusting paths, POSIX compliance).
* Test the patches in a FreeBSD VM or jail environment.
* Organize a short hackathon (e.g., one week-end) on Naemon and FreeBSD IRC channels to:
** Test patches on different FreeBSD versions.
** Improve portability and compatibility.
** Encourage community participation in maintenance.  

*Outcome:* A working FreeBSD-compatible Naemon suite, with volunteer feedback and testing, forming the basis for potential upstream contribution.

== Step 3: Upstream Engagement ==
*Goal:* Collaborate with Naemon maintainers to upstream FreeBSD compatibility improvements.

*Actions:*
* Present the proof-of-concept FreeBSD patches to maintainers.
* Highlight testing results, community interest, and potential benefits of FreeBSD support.
* Discuss minimal, low-risk upstream changes (e.g., POSIX-compliant scripts, shebang adjustments).  

*Outcome:* Upstream may accept patches or provide guidance, while Nasqueron keeps a safe internal FreeBSD-compatible fork if necessary.

*Note:* During the 2024 test, Dereckson has contributed upstream 3 fixes to ensure naemon and livestatus can be built with llvm/Clang and against FreeBSD headers. Maintainer was totally OK with C correctness, merged, less OK with shebang adjustments everywhere, and interested (1) to have an overview of Thruk (2) to work on FreeBSD compatibility for NRPE replacement, SNClient (probably a more interesting point than a web UI that could run on a dedicated VM and so on Linux, because NRPE must run on every machine, including other OSes).

== Advantages ==
* Immediate monitoring coverage for critical services.
* Limited maintenance burden with local FreeBSD patching and volunteer testing.
* Potential for upstream contribution, increasing project portability and sustainability.
* Aligns with previous Nasqueron strategies of isolating legacy dependencies while modernizing infrastructure.

== Notes ==
This plan emphasizes community engagement and practical progress. Steps 2 and 3 ensure that FreeBSD compatibility is addressed in a collaborative, low-risk manner without delaying production monitoring.

We consider a solution like Naemon a real need for "alerts", life in monitoring is not only timeseries. For us, Prometheus time series and Nagios-like alerts are not alternatives, but complete each other. Yes, CPU usage can be tracked as a time series easily, but a certificate expiration or a text warning perhaps less.

[[Category:Plan]]
[[Category:Notes]]