We tested Checkmk Enterprise Edition 2.4.0 and noticed that the debug function is missing. It now seems to be in the ccc package, but the README of the package says:
"Most of the code in this package will be deleted without replacement."
This is a serious problem for us! We’ve built many custom extensions using debug, and now they fail with errors like:
ImportError: cmk_addons.plugins.cisco_asa.agent_based.cisco_asa_pools: cannot import name 'debug' from 'cmk.utils'
We’ll need to touch and refactor a lot of code, and we’re also losing a valuable tool for development and training of working students and trainies (Azubis).
Will there be a replacement or official alternative for debug?
For what exactly do you need the debug function?
If it is really needed you can import from the ccc package or more easy - create it inside you own library folder of the plugin package.
I know the debug function can still be imported from the ccc package for now, but since the README clearly says “most of the code in this package will be deleted without replacement,” that doesn’t feel like something we can rely on long-term which we urgently need. Therfore we have, as a basic debugging standard, multiple debug outputs:
And heavly using cmk --debug --detect-plugins=template_plugin -IIvvvvv HOSTNAME
Also:
It’s been super useful to see how Checkmk handles input and output behind the scenes, which is a big help when developing or refactoring plugins. We’re currently migrating 171 CheckPlugins (and growing), so understanding the inner workings is critical.
It was very usefuel working on SNMP checks, especially when OIDs on switches change (which sometimes happend with firmware updates) . It helps us quickly understand what’s going wrong or what data is being pulled.
Since the Checkmk extension development workshops aren’t happening anymore, we’ve had to learn a lot by digging into things ourselves. Personally, the debug function helped me get a deeper understanding of how Checkmk works programmatically. It’s also something we use to train new team members like professionals, students and trainees.
We’re a team where multiple people develop plugins, so having a shared, simple way to inspect behavior and debug issues is important—especially for consistency and knowledge sharing.
We’ve tried to build our plugin structure for long-term maintainability, and it helps us solve internal tickets and issues faster
As a side note: We work in a big enterprise enviroment and most of us started out as sysadmins and only got into programming later, so going deep into the Checkmk core code isn’t always easy—especially without tools like debug.
You talked about own integration of the debug function. Does that mean i can reimplement the same functionality in my own extension?
Yes - the imported debug function is only some lines of code.
#!/usr/bin/env python3
# Copyright (C) 2019 Checkmk GmbH - License: GNU General Public License v2
# This file is part of Checkmk (https://checkmk.com). It is subject to the terms and
# conditions defined in the file COPYING, which is part of this source code package.
debug_mode = False
def enabled() -> bool:
return debug_mode
def enable() -> None:
global debug_mode
debug_mode = True
def disable() -> None:
global debug_mode
debug_mode = False
This you can put inside your plugin directory and can import from there.
It works as long as CMK itself uses it’s debug module for the “–debug” option. You are right as long as this is the case you don’t need to import this from somewhere else.
@physo If this import is removed at anytime in the future you need to import the “new” debug module than.
In the end I’m no fan of this debug function in own code. With all my work i use the breakpoints in VSCode or other IDEs more often for debugging than such an option.
Quick & dirty debug with normal print and remove all print statements before packaging i do also sometimes.
The “–debug” on command line is helpful to get errors that are normally ignored.
Why does it leads to false results? Checkmk use it in the offical docu for programming.
After your answer I dived into debugging with vscode which looks promising for bugs like changed OIDs in SNMP checks. And probably unitttest for some plugins.
I wrote a debug file that calls the functions like this:
import debugpy
import template_plugin as plugin
import inspect
from cmk.agent_based.v2 import (
Service,
Metric,
CheckPlugin
)
debugpy.listen(("localhost", 5678))
print("Waiting for debugger attach...")
debugpy.wait_for_client()
string_table = [['2', '2']]
section = plugin.parse_template_plugin(string_table)
discovery_service = plugin.discover_template_plugin(section)
discovery_service_obj = list(discovery_service)
for single_service_obj in discovery_service_obj:
print(single_service_obj)
check = plugin.check_template_plugin(discovery_service_obj[0].item, section)
check_obj = list(check)
for single_obj in check_obj:
print(single_obj)
Saadly we can’t use the remote_containers extension, like you did and described, because of our security regulations.
But we working our way to CI/CD for the extensions with testing and building in container. And then i will look again into your .vscode.
8.3. Custom debug output
In the examples shown above, we use the print() function to output the content of variables or the structure of objects for you as a developer. These functions for debug output must be removed from the finished check plug-in.
As an alternative to removal, you can also have your debug output displayed only when the check plug-in is called from the console in debug mode. To do this, import the debug object from the Checkmk toolbox and, if necessary, the pprint() formatting aid. You can now produce debug output depending on the value of the debug object:
Tip
The debug object changed its path between Checkmk 2.3.0 and 2.4.0. Instead of the previous location cmk.utils it can now be found in cmk.ccc. Portable code first attempts to import from the new path to fall back to the old path in case of an error.
We’ve built many custom extensions using debug, and now they fail with errors like:
