Scheduling maintenance via API

Feature Requests
1

Hi,

Is it possible to schedule maintenance via the API?
I was unable to find it in the documentation.

Thanks!

2 Likes
2

Hi Jim,

This isnā€™t something in the API currently, but I can see the value in this.

Can I suggest that you re-tag this as a feature request.

Regards,
Gary

3

Hi Gary,

Thanks, I re-tagged it.
Whatā€™s another way to disable notifications of a system, I guess disabling it?

4

You can set it to ā€˜ignoreā€™ I think that should do it.

Either that or filter in the actual alert (you could create a group for ā€˜all devicesā€™ and then only add the devices you want alerts for.

5

Hi,

I mean ignore yes.
We have about 100 devices, and we do maintenance on the servers connected to those, so if they reboot, or need hardware something, we get a ton of alerts, hence I was hoping to automate this via the API as we currently do with Icinga for the servers themselves.

6

I havenā€™t tried this myself, but you could possibly use update_device_field to set ignore?
https://docs.librenms.org/API/Devices/#update_device_field

And have an @reboot job to set this to false, may be an option?

7

Is there a timeline for this, or is there a workaround?

8

@JimKlapwijk

iā€™m thinking about an API Call which has ā€˜notesā€™ and ā€˜durationā€™ as Options, similar to the ā€œMaintenance Modeā€ Button, what do you think?

1 Like
9

I would like this feature as well, any timeline on this?

10
11

Old topic, but I was exactly looking for this. Placing a device in maintenance works perfect via the API, but I missed the following which would be a good addition to this, imhoā€¦

  • Placing a device group in maintenance
    Motivation: The automation tooling does not have to have device level knowledge. I.e. when there is power maintenance on a specific rack, the rack could be placed in maintenance without the automation tooling having to know which devices are in that rack, or the automation tooling does not have to be modified when the contents of the rack change.

  • Ending a maintenance schedule before the actual requested end time has been reached
    Motivation: When actual maintenance work is completed in 1hour and the schedule was set for 2 hours, the maintenance can be ended early automatically, so monitoring and alerting can continue without having the risk missing events the last hour.

Use case: I have a group of devices that do not run 24/7 but only during testing phases. These devices can be shut down automatically when no longer needed to save power. Whenever the tester shuts them down (using a single command in a controller app), the group of devices should go into maintenance mode. Whenever the tester needs the environment, he can enable the devices by using a single command in a controller app, and the maintenance mode is ended automatically, so alerts are working and can be included in the testcases as well.