davsclaus commented on code in PR #1606: URL: https://github.com/apache/camel-website/pull/1606#discussion_r3349994741
########## content/blog/2026/05/camel-monitor-operator/index.md: ########## @@ -0,0 +1,82 @@ +--- +title: "Camel Monitor Operator" +date: 2026-05-30 +draft: false +authors: [squakez] +categories: ["Devops", "Camel K", "Howtos", "Observability"] +preview: "Build your Camel workload with Camel K operator and make advanced monitoring with Camel Monitor Operator" +--- + +During the last years we've worked hard to bring cloud native operations capabilities for your Camel workloads on Kubernetes. Camel K was the first historic initiative and it gave us the possibility to experiment several features that we've decided to move off into a brand new project: [**Camel Monitor Operator**](https://camel-tooling.github.io/camel-dashboard/docs/installation-guide/advanced/operator/) (formerly known as Camel Dashboard operator). + +Whilst Camel K will keep the focus and excel on the building and deploying part of a Camel application on the cloud, the goal of the new project is to focus on the monitoring part only. Separating the two major concerns (build/deploy and monitor) will give us the possibility to better deliver and maintain the projects. It will also give you the possibility to use both projects (or any of the two) in combination with other technologies (i.e., cicd, pipelines, ...) and provide a full operational flexibility. + +The Camel Monitor Operator was born from an experimental feature developed in Camel K (the *Synthtetic Integrations*) and is a great complement that will give you the possibility to maintain a full knowledge of what's going on at every moment on your fleet of Camel applications running on the cloud. The original scope of this project is to provide a lightweight monitoring layer (we'll see how this is exposed in a GUI dashboard) that can be further integrated with any advanced monitoring system automatically (for example, **Prometheus**). + +Last important point to highlight is that the Camel Monitor Operator does not require Camel K to work, neither Camel K needs the Camel Monitor Operator as they offer orthogonal features. + + + +> NOTE: the Camel Monitor Operator is not part of the Apache Foundation at this moment. + +Let's explore how the two operators cooperate to give you greater control of your Camel application operations in the cloud. + +## Build and deploy via Camel K + +The Camel K operator is the best and quickest choice to convert a Camel DSL into a running application in the cloud. The workflow is straightforward. The user creates an `Integration` custom resource containing the Camel DSL (any supported DSL) and any required configuration (properties, file mounting, resource tuning, ...). The Camel K operator do the needful to convert such an Camel route into a running application converting it into a Kubernetes `Deployment` (or `CronJob` or `KnativeService`). Beside that, Camel K knows how to label the deployment resource for the Camel Monitor Operator to discover it out of the box. + Review Comment: A few typos on this line: - "The Camel K operator do the needful" → "does what's needed" - "such an Camel route" → "such a Camel route" ```suggestion The Camel K operator is the best and quickest choice to convert a Camel DSL into a running application in the cloud. The workflow is straightforward. The user creates an `Integration` custom resource containing the Camel DSL (any supported DSL) and any required configuration (properties, file mounting, resource tuning, ...). The Camel K operator does what's needed to convert such a Camel route into a running application converting it into a Kubernetes `Deployment` (or `CronJob` or `KnativeService`). Beside that, Camel K knows how to label the deployment resource for the Camel Monitor Operator to discover it out of the box. ``` ########## content/blog/2026/05/camel-monitor-operator/index.md: ########## @@ -0,0 +1,82 @@ +--- +title: "Camel Monitor Operator" +date: 2026-05-30 +draft: false +authors: [squakez] +categories: ["Devops", "Camel K", "Howtos", "Observability"] +preview: "Build your Camel workload with Camel K operator and make advanced monitoring with Camel Monitor Operator" +--- + +During the last years we've worked hard to bring cloud native operations capabilities for your Camel workloads on Kubernetes. Camel K was the first historic initiative and it gave us the possibility to experiment several features that we've decided to move off into a brand new project: [**Camel Monitor Operator**](https://camel-tooling.github.io/camel-dashboard/docs/installation-guide/advanced/operator/) (formerly known as Camel Dashboard operator). + +Whilst Camel K will keep the focus and excel on the building and deploying part of a Camel application on the cloud, the goal of the new project is to focus on the monitoring part only. Separating the two major concerns (build/deploy and monitor) will give us the possibility to better deliver and maintain the projects. It will also give you the possibility to use both projects (or any of the two) in combination with other technologies (i.e., cicd, pipelines, ...) and provide a full operational flexibility. + +The Camel Monitor Operator was born from an experimental feature developed in Camel K (the *Synthtetic Integrations*) and is a great complement that will give you the possibility to maintain a full knowledge of what's going on at every moment on your fleet of Camel applications running on the cloud. The original scope of this project is to provide a lightweight monitoring layer (we'll see how this is exposed in a GUI dashboard) that can be further integrated with any advanced monitoring system automatically (for example, **Prometheus**). + +Last important point to highlight is that the Camel Monitor Operator does not require Camel K to work, neither Camel K needs the Camel Monitor Operator as they offer orthogonal features. + + + +> NOTE: the Camel Monitor Operator is not part of the Apache Foundation at this moment. + +Let's explore how the two operators cooperate to give you greater control of your Camel application operations in the cloud. + +## Build and deploy via Camel K + +The Camel K operator is the best and quickest choice to convert a Camel DSL into a running application in the cloud. The workflow is straightforward. The user creates an `Integration` custom resource containing the Camel DSL (any supported DSL) and any required configuration (properties, file mounting, resource tuning, ...). The Camel K operator do the needful to convert such an Camel route into a running application converting it into a Kubernetes `Deployment` (or `CronJob` or `KnativeService`). Beside that, Camel K knows how to label the deployment resource for the Camel Monitor Operator to discover it out of the box. + +There are several other features such as *Self Managed Integrations*, *GitOps*, *Serverless*, ... and tunings you can configure. However, the final link between the Camel K operator and the Camel Monitor Operator is a deployment resource. + +## Build and deploy via any other CICD tool + +Of course we know that Camel K is not the only way to build and deploy a Camel application in the cloud. For this reason, the Camel Monitor Operator was designed to pick any deployment resource, regardless who managed it. It can be a manual deployment or any CICD tool. What's important is that such a deployment is labelled in a way the operator can easily discover it. So, if you're planning to integrate a third party delivery tool you must make sure that any deployment resource is labelled with: `camel.apache.org/monitor` and the name you want to appear on the monitoring side. + +Notice that you can dynamically add or remove such a label, but whichever is the deployment technology you have in place, it makes sense to include it automatically as part of the deployment process. + +## Monitor via Camel Monitor Operator + +The Camel Monitor Operator is the consumer of the resources produced by any deployment technology you have in place. It discovers the applications via the `camel.apache.org/monitor` label (this can be configurable and changed if you need to). Once it discovers an application (`Deployment`, `CronJob` or any resource that finally provide a `Deployment` such as `KnativeService`) it creates a `CamelMonitor` custom resource (abbreviated `cmon`). Then it reconciles it periodically and scrape the applications metrics exposed in order to return the most important SLI you need to know in order to figure it out the health status of the application. + +You can get those information via regular CLI: + +```bash +kubectl get cmon Review Comment: Typo: `exchance SLI` → `exchange SLI` ```suggestion order-ms Quarkus - 3.30.8 (4.16.0) Running 1 True True True False Warning 1s ``` (The typo is in the `exchange SLI` column header on the line above this data — may need to fix in the header line as well.) ########## content/blog/2026/05/camel-monitor-operator/index.md: ########## @@ -0,0 +1,82 @@ +--- +title: "Camel Monitor Operator" +date: 2026-05-30 +draft: false +authors: [squakez] +categories: ["Devops", "Camel K", "Howtos", "Observability"] +preview: "Build your Camel workload with Camel K operator and make advanced monitoring with Camel Monitor Operator" +--- + +During the last years we've worked hard to bring cloud native operations capabilities for your Camel workloads on Kubernetes. Camel K was the first historic initiative and it gave us the possibility to experiment several features that we've decided to move off into a brand new project: [**Camel Monitor Operator**](https://camel-tooling.github.io/camel-dashboard/docs/installation-guide/advanced/operator/) (formerly known as Camel Dashboard operator). + +Whilst Camel K will keep the focus and excel on the building and deploying part of a Camel application on the cloud, the goal of the new project is to focus on the monitoring part only. Separating the two major concerns (build/deploy and monitor) will give us the possibility to better deliver and maintain the projects. It will also give you the possibility to use both projects (or any of the two) in combination with other technologies (i.e., cicd, pipelines, ...) and provide a full operational flexibility. + +The Camel Monitor Operator was born from an experimental feature developed in Camel K (the *Synthtetic Integrations*) and is a great complement that will give you the possibility to maintain a full knowledge of what's going on at every moment on your fleet of Camel applications running on the cloud. The original scope of this project is to provide a lightweight monitoring layer (we'll see how this is exposed in a GUI dashboard) that can be further integrated with any advanced monitoring system automatically (for example, **Prometheus**). + +Last important point to highlight is that the Camel Monitor Operator does not require Camel K to work, neither Camel K needs the Camel Monitor Operator as they offer orthogonal features. + + + +> NOTE: the Camel Monitor Operator is not part of the Apache Foundation at this moment. + +Let's explore how the two operators cooperate to give you greater control of your Camel application operations in the cloud. + +## Build and deploy via Camel K + +The Camel K operator is the best and quickest choice to convert a Camel DSL into a running application in the cloud. The workflow is straightforward. The user creates an `Integration` custom resource containing the Camel DSL (any supported DSL) and any required configuration (properties, file mounting, resource tuning, ...). The Camel K operator do the needful to convert such an Camel route into a running application converting it into a Kubernetes `Deployment` (or `CronJob` or `KnativeService`). Beside that, Camel K knows how to label the deployment resource for the Camel Monitor Operator to discover it out of the box. + +There are several other features such as *Self Managed Integrations*, *GitOps*, *Serverless*, ... and tunings you can configure. However, the final link between the Camel K operator and the Camel Monitor Operator is a deployment resource. + +## Build and deploy via any other CICD tool + +Of course we know that Camel K is not the only way to build and deploy a Camel application in the cloud. For this reason, the Camel Monitor Operator was designed to pick any deployment resource, regardless who managed it. It can be a manual deployment or any CICD tool. What's important is that such a deployment is labelled in a way the operator can easily discover it. So, if you're planning to integrate a third party delivery tool you must make sure that any deployment resource is labelled with: `camel.apache.org/monitor` and the name you want to appear on the monitoring side. + +Notice that you can dynamically add or remove such a label, but whichever is the deployment technology you have in place, it makes sense to include it automatically as part of the deployment process. + +## Monitor via Camel Monitor Operator + +The Camel Monitor Operator is the consumer of the resources produced by any deployment technology you have in place. It discovers the applications via the `camel.apache.org/monitor` label (this can be configurable and changed if you need to). Once it discovers an application (`Deployment`, `CronJob` or any resource that finally provide a `Deployment` such as `KnativeService`) it creates a `CamelMonitor` custom resource (abbreviated `cmon`). Then it reconciles it periodically and scrape the applications metrics exposed in order to return the most important SLI you need to know in order to figure it out the health status of the application. + +You can get those information via regular CLI: + +```bash +kubectl get cmon +NAME INFO PHASE REPLICAS HEALTHY MONITORED MEMORY PRESSURE CPU PRESSURE EXCHANGE SLI LAST EXCHANGE + +order-ms Quarkus - 3.30.8 (4.16.0) Running 1 True True True False Warning 1s +delivery-ms Spring-Boot - 3.4.3 (4.11.0) Running 2 True True False False Success 3s +emails-ms Quarkus - 3.30.8 (4.16.0) Paused 0 Unknown Unknown Success 61s +cart-ms Quarkus - 3.33.1 (4.18.0) Error 1 False True Error 0s Review Comment: Minor grammar: "how it would looks like" → "what it looks like" ```suggestion The goal of the Camel Dashboard Console is to provide a graphical view of what we've described in the previous chapter. Here a snapshot illustrating what it looks like: ``` ########## content/blog/2026/05/camel-monitor-operator/index.md: ########## @@ -0,0 +1,82 @@ +--- +title: "Camel Monitor Operator" +date: 2026-05-30 +draft: false +authors: [squakez] +categories: ["Devops", "Camel K", "Howtos", "Observability"] +preview: "Build your Camel workload with Camel K operator and make advanced monitoring with Camel Monitor Operator" Review Comment: Categories `"Devops"` and `"Observability"` are not in the consolidated category set (see commit `fa1a69c8`). The current approved categories are: `Releases`, `Tooling`, `Roadmap`, `Camel K`, `Howtos`, `AI`, `Camel`, `Events`, `Usecases`, `Camel Quarkus`, `Community`. ```suggestion categories: ["Camel K", "Howtos", "Tooling"] ``` ########## content/blog/2026/05/camel-monitor-operator/index.md: ########## @@ -0,0 +1,82 @@ +--- +title: "Camel Monitor Operator" +date: 2026-05-30 +draft: false +authors: [squakez] +categories: ["Devops", "Camel K", "Howtos", "Observability"] +preview: "Build your Camel workload with Camel K operator and make advanced monitoring with Camel Monitor Operator" +--- + +During the last years we've worked hard to bring cloud native operations capabilities for your Camel workloads on Kubernetes. Camel K was the first historic initiative and it gave us the possibility to experiment several features that we've decided to move off into a brand new project: [**Camel Monitor Operator**](https://camel-tooling.github.io/camel-dashboard/docs/installation-guide/advanced/operator/) (formerly known as Camel Dashboard operator). + +Whilst Camel K will keep the focus and excel on the building and deploying part of a Camel application on the cloud, the goal of the new project is to focus on the monitoring part only. Separating the two major concerns (build/deploy and monitor) will give us the possibility to better deliver and maintain the projects. It will also give you the possibility to use both projects (or any of the two) in combination with other technologies (i.e., cicd, pipelines, ...) and provide a full operational flexibility. + +The Camel Monitor Operator was born from an experimental feature developed in Camel K (the *Synthtetic Integrations*) and is a great complement that will give you the possibility to maintain a full knowledge of what's going on at every moment on your fleet of Camel applications running on the cloud. The original scope of this project is to provide a lightweight monitoring layer (we'll see how this is exposed in a GUI dashboard) that can be further integrated with any advanced monitoring system automatically (for example, **Prometheus**). + +Last important point to highlight is that the Camel Monitor Operator does not require Camel K to work, neither Camel K needs the Camel Monitor Operator as they offer orthogonal features. + + + +> NOTE: the Camel Monitor Operator is not part of the Apache Foundation at this moment. + +Let's explore how the two operators cooperate to give you greater control of your Camel application operations in the cloud. + +## Build and deploy via Camel K + +The Camel K operator is the best and quickest choice to convert a Camel DSL into a running application in the cloud. The workflow is straightforward. The user creates an `Integration` custom resource containing the Camel DSL (any supported DSL) and any required configuration (properties, file mounting, resource tuning, ...). The Camel K operator do the needful to convert such an Camel route into a running application converting it into a Kubernetes `Deployment` (or `CronJob` or `KnativeService`). Beside that, Camel K knows how to label the deployment resource for the Camel Monitor Operator to discover it out of the box. + +There are several other features such as *Self Managed Integrations*, *GitOps*, *Serverless*, ... and tunings you can configure. However, the final link between the Camel K operator and the Camel Monitor Operator is a deployment resource. + +## Build and deploy via any other CICD tool + +Of course we know that Camel K is not the only way to build and deploy a Camel application in the cloud. For this reason, the Camel Monitor Operator was designed to pick any deployment resource, regardless who managed it. It can be a manual deployment or any CICD tool. What's important is that such a deployment is labelled in a way the operator can easily discover it. So, if you're planning to integrate a third party delivery tool you must make sure that any deployment resource is labelled with: `camel.apache.org/monitor` and the name you want to appear on the monitoring side. + +Notice that you can dynamically add or remove such a label, but whichever is the deployment technology you have in place, it makes sense to include it automatically as part of the deployment process. + +## Monitor via Camel Monitor Operator + +The Camel Monitor Operator is the consumer of the resources produced by any deployment technology you have in place. It discovers the applications via the `camel.apache.org/monitor` label (this can be configurable and changed if you need to). Once it discovers an application (`Deployment`, `CronJob` or any resource that finally provide a `Deployment` such as `KnativeService`) it creates a `CamelMonitor` custom resource (abbreviated `cmon`). Then it reconciles it periodically and scrape the applications metrics exposed in order to return the most important SLI you need to know in order to figure it out the health status of the application. + +You can get those information via regular CLI: + +```bash +kubectl get cmon +NAME INFO PHASE REPLICAS HEALTHY MONITORED MEMORY PRESSURE CPU PRESSURE EXCHANGE SLI LAST EXCHANGE + Review Comment: Minor grammar: "expect" → "expects" ```suggestion > NOTE: the Camel Monitor Operator expects to scrape the metrics from the default endpoint provided by the `camel-observability-services` component. If you provide this component, then, you don't need to change any configuration. If you don't, it gets a bit more complex as you have to provide the endpoints yourself and likely change the operator configuration accordingly. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
