Integrating Kanzi Monitor into existing projects

You can integrate Kanzi Monitor into your Kanzi application project either as a prebuilt library or from source code. Choose the integration method that fits your development environment and project requirements.

Using prebuilt binaries

The prebuilt library method links your project against compiled binaries included in the Kanzi Monitor package. It requires minimal build configuration and suits most projects where prebuilt binaries are available for your target platform and Kanzi version.

See Integrating Kanzi Monitor as a prebuilt library

Using source code

The source code method compiles Kanzi Monitor as part of your project build. Use this method when you have a source-only Kanzi Monitor package, or when prebuilt binaries are not available for your specific Kanzi version or toolchain configuration.

See Integrating Kanzi Monitor from source code

What Kanzi Monitor adds to your application

Threads. Every thread Kanzi Monitor starts is named kzmon- plus its role, so a debugger or a system profiler shows it as Kanzi Monitor’s rather than as an anonymous thread of your application: kzmon-local for the local console, kzmon-serial and kzmon-serial-wr for the serial console, kzmon-accept, kzmon-rd-<id> and kzmon-wr-<id> for each remote console connection, and kzmon-perfetto for the in-process Perfetto capture, in a plugin built with -DKZMONITOR_PERFETTO_PRODUCER=ON.

Your own plugin on Linux. A plugin of your own that links libkzmonitor.so must export its own createModule. On a Linux shared build, the loader looks createModule up in the plugin library, and if the plugin does not export one, it finds the one in libkzmonitor.so and creates a second Kanzi Monitor module. That module fails to bind the remote console port. The remote console still accepts connections, but answers only the base commands, such as kzinfo, and none of the overwatch.*, trace, watcher, debug.* or capture.* commands.

Define createModule with C linkage in every shared build of your plugin, not only with MSVC, and export it:

extern "C"
{
MYPLUGIN_API kanzi::Module* createModule(uint32_t /*kanziVersionMajor*/, uint32_t /*kanziVersionMinor*/)
{
    return new MyPluginModule;
}
}

Here MYPLUGIN_API stands for your plugin’s export macro. On Linux it can be empty when the plugin is built with GCC’s default symbol visibility; a plugin built with -fvisibility=hidden needs __attribute__((visibility("default"))) in it. The example application’s plugin does this in examples/monitor_example/Application/src/plugin/src/customperformancetools_module.cpp, and its CMakeLists.txt defines the export macro for every shared build.