doc(kamelets): debugging simple notice
+[[debugging]]
= Debugging Camel K Integrations
Sometimes an Integration can fail or behave unexpectedly for unknown reasons, and a developer needs to investigate the cause of such behavior.
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which translates to an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting technique you would apply on an `Integration`.
