[[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.
Attaching a Java debugger to an integration is a common way to start the investigation.

Even if the Integration Pods run on a Kubernetes cluster, it's very easy to attach a Java debugger to the remote Integration container using the CLI.

== Debugging with VS Code

If you're a VS Code user, you can watch this link:https://www.youtube.com/watch?v=pFj21YvzZm0&t=53s[video].

== Debugging with IntelliJ IDEA

Suppose you've started an Integration using the following command:

[source,console]
----
$ kamel run examples/Sample.java
----

An Integration named `sample` should be running in the cluster.
You can use the `kamel debug` command to put it in _debug_ mode:

[source,console]
----
$ kamel debug sample
----

A possible output that you may find is the following:

[source,console]
----
$ kamel debug sample
Enabling debug mode on integration "sample"...
[1] Monitoring pod sample-8455c8b985-5cxvc
[1] exec java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005 -cp ./resources:[..omitted..] io.quarkus.runner.GeneratedMain
[1] Listening for transport dt_socket at address: 5005
Forwarding from 127.0.0.1:5005 -> 5005
Forwarding from [::1]:5005 -> 5005
----

As you can see in the logs, the CLI has configured the integration in debug mode (see option `-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005`) and started forwarding the local port 5005 on the workstation machine (local port can be changed using the `--port` option) to the container port 5005, where the JVM is waiting for a debugger.

The JVM is suspended and waits for a debugger to attach by default: this behavior can be turned off using the `--suspend=false` option.

Last thing to do is, to start a remote debugger on `localhost:5005` with the **integration file (if using Java, Groovy or Kotlin), the Apache Camel project, or the Camel K Runtime project**, opened on your IDE.

The following picture shows the configuration of a remote debugger in IntelliJ IDEA:

image::debugging/remote-debugger.png[Configuration of the remote debugger in IntelliJ IDEA]

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 `yaml` test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you in 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 that you would apply on an `Integration`.
