Plugin Idea ...

[louislam]

Discussed in https://github.com/louislam/uptime-kuma/discussions/95

^{Originally posted by **0mni** July 13, 2021} So I had an idea, why not allow for plugins, very basic/simple. Have uptime-kuma look in a folder for specific scripts, executable. the name of the script can be the name in the drop down. You can put whatever you want in the script, and it just returns a value for success or failure.

[aslmx]

+1

can you allow for arbitrary environment variables to be passed to the shell scripts? THis way it would be easier to customize.

E.g. one could easily write a shell script that takes HOST and WARNDAYS as parameters/variables and then checks if HOST's TLS Cert expires in less than WARNDAYS and then give back either good or bad / success or fail so that Kuma can take care of the notification.

[larrybahr]

It would be ideal if it was not just limited to notification (though I would love a plugin for matter most), it would be cool to see plugins for monitor types. E.g. a website checker or webrtc checker.

[deefdragon]

Did some research after it was brought up in 892. It might be possible to define plugins via https://github.com/adaltas/node-plug-and-play, but also potentially something custom? not fully sure.

some questions:

• How are plugins loaded in?

• how will they be stored? (I'd recommend saving the plugins to a local directory so that the user could load them in by hand if they want)

• what updating/versioning will be available for them?

• will plugins have global settings?

• how will plugins present settings at all?

• How would plugins be discovered?

  • a wiki page with a list of plugins?
  • some discovery mechanism similar to package managers?

• What plugins do we want possible?

  • different pages/layouts to display data? (IE define custom status pages?)
  • monitors
  • notifications
  • data processing?

[jonhiggs]

You could draw inspiration from Nagios. Ideally you could support vanilla Nagios plugins. A plugin is just script/binary. By convention it takes -w <value> to set the warning threshold, and -c <value> for the critical threshold. A plugin does whatever it needs to, then reports back back to Nagios using the exit code.

Sometimes Nagios plugins hit a remote machine themselves, for example the check_http plugin. Othertimes, they only look at localhost, for example check_swap. If you wanted to check the swap on a remote machine -- one not running Nagios -- you are expected to run with with check_by_ssh. Initially, it might be sufficient to forego checks with check_by_ssh, but it could certainly be added later.

A quick skim of the standard plugins shows that you would be able to take advantage of these plugins right away:

• check_dhcp
• check_ftp
• check_ntp
• check_jabber
• check_snmp
• check_smtp

And of course, you could write your own.

You can see some more details about writing plugins here: http://nagios-plugins.org/doc/guidelines.html

And to answer your questions.

How are plugins loaded in?

Plugins would be loaded by users by making them available in the monitor type dropdown. Once selected, the arguments which will be suppled to the plugin will be provided by the user in a text box.

how will they be stored? (I'd recommend saving the plugins to a local directory so that the user could load them in by hand if they want)

Plugins would be stored as scripts/binaries on the local machine. You can run them by hand and check the exit code to know whether it was successful.

what updating/versioning will be available for them?

The standard Nagios Plugins are packaged and distributed in a versioned bundle. For custom or third-party plugins, you might be able to intergrate in some way with Nagios Exchange. More thought would need to go into this if it's important.

will plugins have global settings?

No

how will plugins present settings at all?

You would be asked to supply the plugin arguments as a string. Something like -c 10 -w 8 for the critical and warning value.

How would plugins be discovered? a wiki page with a list of plugins? some discovery mechanism similar to package managers?

https://exchange.nagios.org/ is already a thing. If you can remain compatible with Nagios plugins, then this problem has been solved for you.

What plugins do we want possible? different pages/layouts to display data? (IE define custom status pages?) monitors notifications data processing?

This proposal will only handle monitor plugins.

[rthidden]

I see there are plugins in the Wiki.

Do you know if the plugin architecture is documented somewhere?

[CommanderStorm]

Those are not plugins as discussed in this thread. Those are 3rd Party Addons Apps. This thread is about installing new monitors/notification providers/.. into uptime-kuma. In case you want to build an addon, there are unnoffical 3rd party apis. See #118 for further context.

We have experimented with plugins in the past, but https://github.com/louislam/uptime-kuma/security/advisories/GHSA-7grx-f945-mj96 has shown us that this is not as easy to implment. Expermients around that have been reverted as fix for that security vulnerability.

Additional discussions exist around https://github.com/louislam/uptime-kuma/issues/1117#issuecomment-2111111764