Naemon - Revision history

Dereckson: /* Step 3: Upstream Engagement */

2025-11-28T15:18:25Z

Step 3: Upstream Engagement

← Older revision		Revision as of 15:18, 28 November 2025
Line 43:		Line 43:

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

	Actions:		'''Actions:'''
	* Present the proof-of-concept FreeBSD patches to maintainers.		* Present the proof-of-concept FreeBSD patches to maintainers.
	* Highlight testing results, community interest, and potential benefits of FreeBSD support.		* Highlight testing results, community interest, and potential benefits of FreeBSD support.
	* Discuss minimal, low-risk upstream changes (e.g., POSIX-compliant scripts, shebang adjustments).		* 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.		'''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.		'''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:		Maintainer was totally OK with C correctness, merged, less OK with shebang adjustments everywhere, and interested:

Dereckson: /* Step 3: Upstream Engagement */

2025-11-28T15:18:03Z

Step 3: Upstream Engagement

← Older revision		Revision as of 15:18, 28 November 2025
Line 52:		Line 52:
	Outcome: Upstream may accept patches or provide guidance, while Nasqueron keeps a safe internal FreeBSD-compatible fork if necessary.		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).		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:
			# to have an overview of Thruk
			# 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 ==		== Advantages ==

Dereckson: /* Step 1: immediate monitoring */

2025-11-26T12:47:16Z

Step 1: immediate monitoring

← Older revision		Revision as of 12:47, 26 November 2025
Line 15:		Line 15:

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

	Actions:		'''Actions:'''
	* Spawn a Debian or Rocky VM dedicated to monitoring on hyper-001		* Spawn a Debian or Rocky VM dedicated to monitoring on hyper-001
	* Install Naemon on the VM		* Install Naemon on the VM
Line 23:		Line 23:
	* Configure notifications to IRC, e-mail, etc.		* Configure notifications to IRC, e-mail, etc.

	Outcome: Nasqueron services are monitored immediately with script-based alerts, without waiting for full FreeBSD compatibility.		'''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.		'''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.		'''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 ==		== Step 2: FreeBSD Patch / Proof-of-Concept ==

Dereckson at 12:46, 26 November 2025

2025-11-26T12:46:19Z

← Older revision		Revision as of 12:46, 26 November 2025
Line 3:		Line 3:
	Shinken and Sensu have been dismissed as open core solutions.		Shinken and Sensu have been dismissed as open core solutions.

	== Naemon deployment and FreeBSD porting plan =		= Naemon deployment and FreeBSD porting plan =

	== Overview ==		== Overview ==

Dereckson at 23:38, 25 September 2025

2025-09-25T23:38:24Z

← Older revision		Revision as of 23:38, 25 September 2025
Line 65:		Line 65:
	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.		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:Monitoring]]
			[[Category:Notes]]
	[[Category:Plan]]		[[Category:Plan]]
	~~[[Category:Notes]]~~

Dereckson: Created page with "'''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 sensibl..."

2025-09-25T23:35:16Z

Created page with "'''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 sensibl..."

New page

'''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]]