Do you ever need to reboot or do maintenance on your Windows Server? Then if the server is monitored by NetEye, you’ll surely want to mark it in downtime so as not to have notifications sent out for problems arising due to maintenance, and/or to be able to have the correct SLA marked for your Server Uptime and Service Availability.
You’ll have to make a few modifications to the script in order to get it to work:
Set the NetEye/Icinga 2 Hostname (or IP) [$icingaApiHost]
Set the NetEye/Icinga 2 API username [$icingaApiUser]
Set the NetEye/Icinga 2 API user-password [$icingaApiPassword]
Add the contents of the NetEye Root CA certificate (.crt ) to the script inside the BEGIN/END Certificate Lines indented as shown in the file. This needs to be the CA you made the API Certificate with.
DMIN: Downtime minutes starting from now COMMENT: The downtime comment to add HOSTNAME: If not given the script will use the local FQDN host name in lower case.
Now, calling the script manually or within a reboot or maintainance script will set the Host and ALL its services on the NetEye/Icinga2 API into Downtime.
I hope you can use and enjoy this script for your daily work.
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Juergen Vigna
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Processing Tree Rendering Issue We shipped a fix for a rendering bug in the Tornado UI Processing Tree. Under specific conditions, navigating back to the dashboard after expanding tree nodes caused the tree to render incorrectly nodes would appear collapsed, Read More
Role Search Now Works in Access Control We've fixed the search functionality in the Roles view under Configuration - Access Control, so you can now find roles instantly without any errors. List of updated packages To solve the issues mentioned Read More
Running Ollama locally or on dedicated hardware is straightforward until you need to know whether a model is actually loaded in RAM, how fast it generates tokens under load, or when memory consumption reaches a threshold that affects other workloads. Read More
Hi everyone! Today I'd like to share with you an investigation we undertook related to ingesting Open Telemetry data in Elasticsearch, while maintaining tenant segregation from start to end. The Scenario Let's imagine we have multiple customers, where in this Read More
SNMP monitoring is the standard method for obtaining information and metrics from network devices. Typically, we focus on extracting data from a single interface to monitor its status, traffic, or errors. But in many cases, we’re only interested in getting Read More