Config templates

[MoBlockbuster]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

Possibility to create configtemplate for the checks
Example:
HTTP Monitoring Heartbeat Interval is per default 60 seconds.

It should be a option to change the defaultvalues.

✔️ Solution

• no solution

❓ Alternatives

No response

📝 Additional Context

No response

[newice]

Would love this.

I have different types of checks like for important services and not so important ones.
So choosing from an existing template when creating a new check would be great.
Preset values like:

• Monitor Type
• Keyword (if applicable)
• Heartbeat Interval
• Retries
• Heartbeat Retry Interval
• Upside Down Mode
• Tags

Maybe even better would be to kind of link the cheks to the template and when i update the template, all checks would be updated.

[xeruf]

I think the best way to realize that would be to associate specific settings with a tag, and whenever the settings for that tag are updated, all related monitors will be updated, i.e. Tag-based Configuration.
This would also allow easy updating of existing monitors - and anybody can decide for themselves whether to create special tags or the ones already in use.

I find this especially useful now with this added option:

Resend Notification if Down X times consequently

which I find highly useful but would like to set depending on the importance of the monitor.

I guess for now one can open the sqlite db in sqlitebrowser for bulk editing...

[etfz]

Well, I don't agree with the merging of #937, but I don't know that there's any use commenting here, as suggested, as this feature is something else entirely.

Not sure what "tangling to some different system" is supposed to mean, when notifications are set up the exact same way. Allowing for profiles gives much more flexibility, especially if the option to use individual configuration remains.

[CommanderStorm]

How should such a feature work precisely and what is the difference?
#937 is very vague: Configuring multiple montiors via the same settings is possible via config templates and bulk editing.

I think adding another subsystem for having shared configurations just adds complexity which can be avoided. Remember that the system has to stay testable and maintainable.

I see this issue and bulk editing as proposed in #455 as a simpler alternative to achieving the same goals.

[etfz]

Simpler for whom? I would disagree that it is simpler for the end user. Finding a single defined profile instead of scrolling through potentially hundreds of monitors trying to find and select the relevant ones is a clear benefit, as far as I'm concerned. Especially if it actually is important that my monitors are configured identically. It is essentially a "group" feature, which is very common and crucial for any system that involves more than a few items.

The difference is that any given monitor defers to its assigned profile for its configuration, instead of the configuration being assigned directly to the monitor. It is exactly the same as how notifications are currently configured. You would first configure a profile, similarly to how individual monitors are configured today, and then select this profile when configuring the monitor. You would probably want to still allow individual configuration, in order to make it easier for users who might have few and unique monitors, so they don't have to create a profile for each monitor. You might also have some kind of "Default" profile, which uses the same defaults as today, so that users don't have to create a new profile first thing, assuming they want to use the same configuration.

[CommanderStorm]

As stated above: Features need to be developed, tested and maintained.

What you are asking for is a MAJOR rewrite, this is incremental (possible to develop, test and maintain).
Adding a override monitors or a override montitors if not defined button to the config template may be possible in a future update, but not initially.