Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

Check_MK Werk 4813: All recipents of an email are visible in notifications

by Tom Baerwinkel

ID: 4813 Title: All recipents of an email are visible in notifications Component: Notifications Level: 2 Class: New feature Version: 1.5.0i1 Notification multiplexing can now be used for HTML and ASCII emails. By default it is enabled on new and existing Check_MK installations. If notification multiplexing is enabled only one notification is generated even if multiple recipients are going to be notified. Therefore, a user can see and reply to all recipients of a notification. Furthermore, the notification system will be more performant if graphs are present in the notification the since only one notification is generated. The notification multiplexing can be disabled in the section Notification Method of a notification rule.

7 years

Check_MK Werk 4643: Added special agent and checks for HPE StoreOnce

by Marcel Arentz

ID: 4643 Title: Added special agent and checks for HPE StoreOnce Component: Checks & agents Level: 2 Class: New feature Version: 1.5.0i1 This special agent requires username and password. The matching host will be used as target and the following services will be created: - HPE StoreOnce xx00 Backup - Appliance Status - Total Capacity - Uptime - ServiceSet x Capacity - ServiceSet x Status - ServiceSet x Store y Further information will be in the manpages.

7 years, 1 month

Check_MK Werk 4989: Added handling of host downtimes during event creation

by Lars Michelsen

ID: 4989 Title: Added handling of host downtimes during event creation Component: Event Console Level: 2 Class: New feature Version: 1.5.0i1 The Event Console is now saving whether or not a host that can be found in the core was in downtime or not. Based on this information the event handling can be influenced in different ways. The idea is: In the moment a host is in downtime all events generated by the host are "handled problems". The events should be created and be visible during the downtime to assist during maintenance. After maintenance the events that have been created in the downtime are not interesting anymore. What has changed: <ul> <li>Each event has a new attribute <tt>event_host_in_downtime</tt>. Assuming <i>0</i> (no) for existing events.</li> <li>It is possible to filter event views by this information</li> <li>Separate counting events are created for in downtime / not in downtime</li> <li>Events are added during downtime and visible in the default events views<li> <li>The tactical overview does not count events created in host downtime in the "handled problems" column</li> <li>Events created during downtime will be archived automatically after the host left the downtime</li> <li>Actions are handled independent of the downtime by default. But you have the option to only execute actions when the host was not in downtime</li> </ul> Events that are not associated with a monitoring host in the local site are not affected by the changes mentioned above.

7 years, 2 months

Check_MK Werk 4921: Users can be limited to a list of authorized sites now

by Lars Michelsen

ID: 4921 Title: Users can be limited to a list of authorized sites now Component: Multisite Level: 2 Class: New feature Version: 1.5.0i1 It is now possible to configure a list of authorized sites for each user. This is especially useful when having a huge number of sites configured, like several hundred, in a distributed setup. In case you have users that have their hosts on only some of these sites, you can set the new authorized sites option for these users. For the users that have authorized sites configured the GUI will only contact these sites instead of all sites to build up their views. In large environments this will be a huge performance improvement.

7 years, 2 months

Check_MK Werk 4901: Reworked Livestatus Proxy to be more scalable

by Lars Michelsen

ID: 4901 Title: Reworked Livestatus Proxy to be more scalable Component: Livestatus Proxy Level: 2 Class: New feature Version: 1.5.0i1 The livestatus proxy daemon has been reworked to use a multi process architecture. It now has a master process that mainly cares about monitoring the site processes. Each connected site has an own subprocess that manages all channels to this site and the clients that use these channels to communicate with the sites. When you have a look at ps/top you should see something like this: C+: OMD[heute]:~$ ps -ef | grep liveproxyd UID PID PPID C STIME TTY TIME CMD heute 9261 1 0 11:40 ? 00:00:00 liveproxyd[master] heute 9262 9261 0 11:40 ? 00:00:00 liveproxyd[heute_slave_1] heute 9263 9261 0 11:40 ? 00:00:00 liveproxyd[heute_slave_2] C-: As you can may see there is the master process that has the process <tt>1</tt> as parent process. The site processes have the master as parent. When one site process terminates for some reason the master will restart it. When the master is terminated all site processes will terminate too. In case of a restart or config reload the master will restart itself and stop all site processes and restart them again. With this change the load of the livestatus proxy will now spread over multiple CPUs. Side note: There is a new global setting <i>Logging of the Livestatus Proxy</i> that can be used to control the detail level of the log entries written to the <tt>var/log/liveproxyd.log</tt> log file. In case you experience any issues with the livestatus proxy daemon take a look at this log file and maybe increase the log level to get more details.

7 years, 2 months

Check_MK Werk 4708: Windows Agent/Agent Updater: Fixed race condition which removed the windows service

by Andreas Boesl

ID: 4708 Title: Windows Agent/Agent Updater: Fixed race condition which removed the windows service Component: Checks & agents Level: 2 Class: Bug fix Version: 1.5.0i1 The agent updater could kill itself during an update, because the MSI installation process sent a shutdown signal to the windows service. This shutdown also killed any plugins, including the agent updater... This has been fixed by detaching the cmk-update-agent.exe file from the process group of the windows agent.

7 years, 3 months

Check_MK Werk 4761: Fixed multisite setups with sites using Check_MK/Livestatus < 1.4

by Lars Michelsen

ID: 4761 Title: Fixed multisite setups with sites using Check_MK/Livestatus < 1.4 Component: Multisite Level: 2 Class: Bug fix Version: 1.5.0i1 When updating the central site of a distributed setup to Check_MK 1.4.* and leaving the slave sites on older versions the other sites were marked as dead sites while rendering the page. This issue was caused by the tactical overview snapin that tried to calculate the numbers for the "Events" of the Event Console. The slave sites using older Check_MK versions do not support that kind of query. Once this query is made the sites are marked as dead and are also not shown correctly in the master control and site status snapin. A possible workaround would be to update all involved sites to Check_MK 1.4. Also affected are sites that use the Nagios core and have the Event Console disabled. They still report an error to the GUI. This will be fixed soon.

7 years, 3 months

Check_MK Werk 4758: Fixed site status and master control snapin not displaying states of sites

by Lars Michelsen

ID: 4758 Title: Fixed site status and master control snapin not displaying states of sites Component: Multisite Level: 2 Class: Bug fix Version: 1.5.0i1 The master control snapin was hiding sites with communication errors completely. It is now displaying a box with the occured error message. The site status snapin was showing the site, but displaying a site as "online" while it was reported as "dead" by the livestatus connection. This appeared when an error was found in a query, for example when a queried table does not exist.

7 years, 3 months

Check_MK Werk 4757: Fixed possible reflected XSS in webapi.py

by Lars Michelsen

ID: 4757 Title: Fixed possible reflected XSS in webapi.py Component: Multisite Level: 2 Class: Security fix Version: 1.5.0i1 In the Check_MK 1.4 branch URLs like this could be used for a reflected XSS attack: <tt>http://<test host>/<site>/check_mk/webapi.py?_username=<script>alert("XSS")</script>&_secret=AnythingHere The error message was interpreted as HTML while it should be a plain text error message. This has been fixed now.

7 years, 3 months

Check_MK Werk 4858: omd_apache data collection: fixed issues caused by missing newline at the end of statsfile(s)

by Marcel Schulte

ID: 4858 Title: omd_apache data collection: fixed issues caused by missing newline at the end of statsfile(s) Component: Checks & agents Level: 2 Class: Bug fix Version: 1.5.0i1 Sometimes the apache statsfile(s) can miss a newline at the end of the file. This caused the following known issues: * missing agent section directly after omd_apache section - because the section header was starting in the same line as the omd_apache section's last line * crashed omd_apache check because of missing data

7 years, 3 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2