Recently, I’ve stumbled upon this interesting article and paired project about a Genetic Algorithm. Then, I’ve asked myself if somehow the features of Trusty PMML could be meaningfully used inside such context. I won’t go deep into technical details, but basically, the Genetic Algorithm classifies features as "genes", a set of genes is a "genoma",Read more →

Recently, I’ve stumbled upon this interesting article and paired project about a Genetic Algorithm. Then, I’ve asked myself if somehow the features of Trusty PMML could be meaningfully used inside such context.

I won’t go deep into technical details, but basically, the Genetic Algorithm classifies features as "genes", a set of genes is a "genoma", and that represents a unit of evaluation. A population is made of multiple instances of such units. Each individual has a fitness value, that is based on the values of its genes, and the scope of the algorithm is to select the individual with the fittest value, or the fitness value equal to the expected one.

During algorithm evaluation, new generations are created, where each new-born is the "combination" of two parents. The interesting feature is the "mutation" of such units, where some gene of one is exchanged with genes of another one. At each generation, fittest individuals replace older ones, and that will eventually lead to a "convergence", when the expected fitness value is obtained.

I’m always fascinated by technologies that mimic a biological behavior to obtain their results, and Genetic Algorithm should somehow mimic the genetic evolution through sexual reproduction. But in real life the genetic evolution is due to two factors:

1. genetic recombination (specific to sexual reproduction)
2. spontaneous genetic mutation.

In my implementation, I wanted to recreate both of them, and I wanted to demonstrate some cool features of Trusty PMML at the same time.

To start with, I forked the original project here and I begun to use PMML for gene representation.

The next step has been to try to figure out concrete, likely example. During a party meeting, a colleague started to talk about plants and crops at home, and that gives me the idea.

The Story of Gus the Farmer

One day, Gus decided to leave his work to make an agriculture business. He did not have an extensive area to cultivate, so he decided to crop apartment plants inside greenhouses. He made a market survey to find out which plants were the most looked after, and he also gathered historical weather information regarding water and light available on the place he was going to build in. Being wise enough, he also devised a plan to give flexibility to his business, to maintain his profit even when customer taste or environment conditions would change.

He finds out that people mostly like ferns, roses and cacti.

He builds three greenhouses, each of which has a slightly different configuration, specialized for one kind of plant. He then started a setup phase, with five harvests a week for each greenhouse (those are very extraordinary greenhouses, actually), and then, at each harvest, he slightly tweaked the configuration of each one so that, in the end, all of them would produce the most required plant. He then successfully started his business and, whenever people prefer different plants or environment variables mutate, all he has to do is go through the setup phase again to remain in business.

And the code ?

This story is represented inside the Greenhouses branch of my project. It is a standard maven-project and is written in Kotlin; there is no claim of being mathematically or theoretically accurate, but it shows how some Trusty PMML features may be applied to a Genetic Algorithm.

The setup phase is represented by the loop inside SimpleDemoGA class. Farm represents the overall installation, producing harvests at each iteration. Harvest is the product of greenhouses. And Greenhouse is the execution of a PMML model. The result of this execution may be fern, rose or cactus.

At startup there are three slightly different PMML files: Greenhouse_A.pmml, Greenhouse_B.pmml and Greenhouse_C.pmml.

Each of those PMMLs defines a Regression model with three RegressionTables, each of which targeting a specific plant:

<RegressionModel functionName="classification" modelName="..." targetFieldName="Species">
    <RegressionTable targetCategory="fern" ..,>
        ...
    </RegressionTable>
    <RegressionTable targetCategory="rose" ..,>
        ...
    </RegressionTable>
    <RegressionTable targetCategory="cactus" ..,>
        ...
    </RegressionTable>
</RegressionModel>

Each table has a different intercept value, and inside each of them a different coefficient is given to _water_ and _light_ variables

<RegressionTable targetCategory="..." intercept="1">
    <NumericPredictor name="water" exponent="1" coefficient="..."/>
    <NumericPredictor name="light" exponent="1" coefficient="..."/>
</RegressionTable>

and that made every greenhouse specific for a given plant.

When a greenhouse produce the required plant, its gene is set to "1", otherwise is "0".

The fitness of a harvest is the number of "1" genes. When all of them are "1", it means that all greenhouses are producing the required plant, and the target is obtained.

Trusty PMML in action

The mutation of the greenhouse configuration mimics the natural genetic "casual" mutation, and to achieve that a cool feature of Trusty PMML has been exploited, i.e. the ability to change and quick reload the underlying model itself at runtime. This is not standard procedure. Usually, predictive models are created, trained and tuned with different tools, and PMML is generated out of them.

This requires an overall company setup similar to the following one:

1. business analyst gather requirements
2. data scientists design and tune models
3. someone exports models in PMML format
4. developers write code that such PMML files (and a PMML engine) to actually return a value based on a given input.

There may be cases, though, where this setup does not fulfill the business requirement. One example could be a daily incremental fine-tuning of an already generated model. Another requirement could be the usage of the PMML model slightly beyond its specification, and I have a concrete example of that.

We received a request about the evaluation of the probability that a given string is similar to another one, both of which given as input by the user. This could be a particular use case of Levenshtein distance.

PMML defines an expression called TextIndex that actually uses that distance to evaluate if one string is similar to another one. The problem is that the maxLevenshteinDistance is a fixed attribute, so TextIndex could be used to evaluate if two strings are similar for a specific Levenshtein distance, while the request could be translated somehow to "how many Levenshtein distances there are from those two strings ?".

Of course it could be possible to write custom extension to solve that, and possibly even a really contrived PMML based on nested defined functions, replacement, regexp and what else.

Modify that maxLevenshteinDistance attribute on-the-fly could be another solution. I know it would be practically unfeasible if the requests are too frequent, but this gives you an idea of a possible use case.

Back to Gus

At each harvest Gus needs to tweak the greenhouses. In algorithmic terms, a gene mutation has to happen. In the actual implementation, a modification of the PMML is required. This is done inside PMMLManager.mutatePMMLFile() method:

1. the last version of the PMML file is loaded as PMML instance
2. the intercept value of the RegressionTable for the required specie is increased
3. the modified PMML is serialized back as PMML file, overwriting the previous version
4. for each greenhouse of each harvest, that modified versions of PMML files are loaded and actual evaluation is done on top of that

At the end of the cycle, when the target is obtained (i.e. an harvest with all three genes as "1") in the target/classes folder there will be the last versions of the PMML files, while the original ones are kept unmodified inside src/main/resources folder.

Setup in Action

The following is an exerpt of an actual execution of the program with the following input data

Required specie: rose Environment values {water=48, light=5}

During execution, the log will show the predicted values for each model while they are mutated:

...
Model Greenhouse_C 
results {Predicted_Species=fern, Probability_rose=66.9, Species=fern, Probability_fern=91.30000000000001, Probability_cactus=-157.20000000000002} 
Model Greenhouse_A 
results {Predicted_Species=fern, Probability_rose=54.0, Species=fern, Probability_fern=65.5, Probability_cactus=-118.5} 
Model Greenhouse_B 
results {Predicted_Species=fern, Probability_rose=51.7, Species=fern, Probability_fern=56.900000000000006, Probability_cactus=-107.60000000000001} 
Model Greenhouse_C 
results {Predicted_Species=fern, Probability_rose=66.9, Species=fern, Probability_fern=91.30000000000001, Probability_cactus=-157.20000000000002} 
Model Greenhouse_A 
results {Predicted_Species=fern, Probability_rose=54.0, Species=fern, Probability_fern=65.5, Probability_cactus=-118.5} 
...

At each cycle, an overall report is printed out, with the genomas of all the five harvests:

Population of 5 individual(s).
Required specie: rose Environment values {water=48, light=5}
Generation: 0 Fittest score: 0
==Genetic Pool==
> Harvest 0 | [genes=[0, 0, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: fern, Greenhouse_C: fern |
> Harvest 1 | [genes=[0, 0, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: fern, Greenhouse_C: fern |
> Harvest 2 | [genes=[0, 0, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: fern, Greenhouse_C: fern |
> Harvest 3 | [genes=[0, 0, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: fern, Greenhouse_C: fern |
> Harvest 4 | [genes=[0, 0, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: fern, Greenhouse_C: fern |
================

Progressively, some genes will switch from 0 to 1:

Generation: 38 Fittest score: 2
==Genetic Pool==
> Harvest 0 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 1 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 2 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 3 | [genes=[0, 1, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 4 | [genes=[0, 1, 0]] | [features= Greenhouse_A: fern, Greenhouse_B: rose, Greenhouse_C: fern |
================

until the conclusion of the setup:

Generation: 75 Fittest score: 3
==Genetic Pool==
> Harvest 0 | [genes=[1, 1, 1]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: rose |
> Harvest 1 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 2 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 3 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
> Harvest 4 | [genes=[1, 1, 0]] | [features= Greenhouse_A: rose, Greenhouse_B: rose, Greenhouse_C: fern |
================

Solution found in generation 75
Fitness: 3
Genes: 111

Process finished with exit code 0

Last, as comparison, here’s a snipppet from the original Greenhouse_B.pmml

<RegressionTable targetCategory="fern" intercept="1">
   <NumericPredictor name="water" exponent="1" coefficient="1.3"/>
   <NumericPredictor name="light" exponent="1" coefficient="-1.3"/>
</RegressionTable>
<RegressionTable targetCategory="rose" intercept="2">
   <NumericPredictor name="water" exponent="1" coefficient="0.9"/>
   <NumericPredictor name="light" exponent="1" coefficient="1.1"/>
</RegressionTable>
<RegressionTable targetCategory="cactus" intercept="1">
   <NumericPredictor name="water" exponent="1" coefficient="-1.3"/>
   <NumericPredictor name="light" exponent="1" coefficient="1.3"/>
</RegressionTable>

and here’s the mutated one after successful completion of setup:

<RegressionTable intercept="1" targetCategory="fern">
   <NumericPredictor name="water" exponent="1" coefficient="1.3"/>
   <NumericPredictor name="light" exponent="1" coefficient="-1.3"/>
</RegressionTable>
<RegressionTable intercept="29" targetCategory="rose">
   <NumericPredictor name="water" exponent="1" coefficient="0.9"/>
   <NumericPredictor name="light" exponent="1" coefficient="1.1"/>
</RegressionTable>
<RegressionTable intercept="1" targetCategory="cactus">
   <NumericPredictor name="water" exponent="1" coefficient="-1.3"/>
   <NumericPredictor name="light" exponent="1" coefficient="1.3"/>
</RegressionTable>

Conclusion

The code used in the example may be retrieved here. The scope of this article and the companion project is to illustrate a possible usage of Trusty PMML for a Genetic Algorithm implementation. It has no claim at all about theoretical nor mathematical integrity. Any comment or suggestion is more than welcome. I hope you enjoyed it!

Introduction PMML is an XML standard whose scope is to define different kinds of predictive models (Regression, Scorecard, Tree, Neural Network, etc) in a system-agnostic way, so that it may be used and shared by different systems/implementations. The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computersRead more →

Introduction

PMML is an XML standard whose scope is to define different kinds of predictive models (Regression, Scorecard, Tree, Neural Network, etc) in a system-agnostic way, so that it may be used and shared by different systems/implementations.

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

Beginning in January 2020 a new initiative, PMML-Trusty, has started to provide a fast, reliable implementation natively available inside Drools and Kogito.

Recently, a new feature has been added to implement OpenAPI usage in PMML-specific rest-endpoints created by the Kogito framework, for both Quarkus and Springboot environments.

Predictions in Kogito

The PMML-Trusty engine is exposed in Kogito through rest endpoints. This allows an extremely easy way to create a PMML executor that, at the same time, is available through easy-to-use, standard, language agnostic rest endpoints.

A bare-minimum Kogito project requires some PMML files in the resources folder and a configuration yaml. Here are Quarkus and Springboot example projects.

During Kogito code generation, engine-specific classes are created out of the models found in the given PMML files. 

Then, for each model a Rest class is created, whose root path is derived from the model name. Inside this class there are two specific endpoints:

1. result (“{root_path}/”)
2. descriptive (“{root_path}/descriptive”)

The first endpoint will return only the raw result of model evaluation, while the second one will return a complex object containing additional information and metadata.

OpenAPI Rest endpoints

The generated endpoints are further enriched with OpenAPI metadata. 

For each model a json-schema file is created, containing the descriptive representation of:

1. requested input (InputSet)
2. (raw) result output (ResultSet)
3. descriptive output (OutputSet)

Here’s the overall skeleton of a generated json schema:

{
  "definitions": {
    "OutputSet": {
      "type": "object",
      "properties": {
        ...
      }
    },
    "InputSet": {
      "type": "object",
      ...
      }
    },
    "ResultSet": {
      "type": "object",
      "properties": {
        ...
      }
    }
  }
}

An extremely useful feature is the ability to propagate the model requirements/constraints to the final consumer, for example, the valid values for a string field or the allowed ranges for numeric values. The following snippet shows a couple of example about that

 "resultCode": {
          "type": "string",
          "enum": [
            "OK",
            "FAIL"
          ]
        }

"temperature": {
          "type": "number",
          "format": "double",
          "intervals": [
            "-∞ -10",
            "-10 10",
            "10 ∞"
          ]
        }

When rendered inside the html page, such metadata will be shown, providing help on endpoint usage to the final end user. 

A couple of images will give an idea on how the pages would look like for PMML endpoints:

Conclusion

OpenAPI-enriched Rest-endpoints provides a useful feature to help end users in the rest-endpoint usage and, at the same time, to write more robust program-driven consumers.

Exposing input and output schemas in json format allows the developer to write code that

1. retrieves the required fields and formats
2. submit data for evaluation
3. analyze or manage returned values in the light of the expected output

In the second part of the blog series https://blog.kie.org/2020/12/how-to-integrate-your-kogito-application-with-trustyai-part-2.html we showed how to setup the OpenShift cluster that will host the TrustyAI infrastructure and the Kogito application we created in the first part https://blog.kie.org/2020/12/how-to-integrate-your-kogito-application-with-trustyai-part-1.html . In this third and last part of our journey, we are going to demonstrate how to deploy the TrustyAI infrastructureRead more →

In the second part of the blog series https://blog.kie.org/2020/12/how-to-integrate-your-kogito-application-with-trustyai-part-2.html we showed how to setup the OpenShift cluster that will host the TrustyAI infrastructure and the Kogito application we created in the first part https://blog.kie.org/2020/12/how-to-integrate-your-kogito-application-with-trustyai-part-1.html .

In this third and last part of our journey, we are going to demonstrate how to deploy the TrustyAI infrastructure and the Kogito application we created so far.

Let’s have a look at the TrustyAI infrastructure, just to have an high level overview of the services that we are going to deploy.

In the yellow box the Kogito application is represented: it contains our DMN model and every time a decision is evaluated, a new tracing event is generated. This event contains all the information that the TrustyAI services need to calculate the explainability and keep track of inputs/outputs of each decision.

The tracing events are then consumed by the Trusty Service, which stores all the data and makes it available for the frontend (alias the AuditUI). It also communicates with the Explainability Service: in a nutshell, starting from the decision taken by the Kogito application, it creates many different new decisions perturbing the original one. Once all of the new decisions have been evaluated by the Kogito application, a machine learning model is trained to figure out the most relevant features that contributed to the original outcome.

Deployment of the Trusty Service

Let’s deploy first of all the Trusty service using the Kogito Operator: go to Operators -> Installed Operators -> Kogito -> Kogito Service -> Create KogitoSupportingService.

Create a new resource named trusty-service, select the Resource Type TrustyAI and in the Infra section add the two KogitoInfra resource names that we created so far: kogito-kafka-infra and kogito-infinispan-infra.

Deployment of the AuditUI

The frontend, i.e. the AuditUI, consumes some API exposed by the Trusty Service: by consequence it needs to know what is the URL of the Trusty Service. This information has to be injected using an environment variable called KOGITO_TRUSTY_ENDPOINT.

On OpenShift, it is possible to get the URL of the Trusty Service we have just deployed under Networking -> Routes. Copy the URL.

On the Kogito Operator console, create a new KogitoSupportingService named trustyui-service, select the Resource Type TrustyUI and add the environment variable KOGITO_TRUSTY_ENDPOINT with the URL of the Trusty Service you’ve just copied.

Deployment of the Explainability Service

On the Kogito Operator console, once again create a new KogitoSupportingService named explainability-service with Resource Type Explainability. The KogitoInfra to be linked is only kogito-kafka-infra.

Deployment of the Kogito Application

The TrustyAI infrastructure has been deployed, and we’re ready to deploy the Kogito application finally.

Create a new Kogito Service custom resource with name my-kogito-application-service and label app=my-kogito-application-service. The Image should be the tag you used for the docker image that contains your Kogito application (the one that we created in the first video/blogpost). If you have used https://quay.io/, it should be something like quay.io/<your_username>/my-kogito-application:1.0.
The last step is to add the string kogito-kafka-infra in the Infra section.

Execute, Audit, Explain

We’re ready to play with the Kogito application, look at the AuditUI and investigate the explainability results!

Under Networking -> Routes click on the URL of the Kogito Application: a new tab should be opened.

Let’s execute a request to the /LoanEligibility endpoint to evaluate our DMN model. If you’d like, you can use the swagger ui at http://<your_kogito_application_url>/swagger-ui .
A sample payload is the following:

{"Bribe": 1000,"Client": {"age": 43,"existing payments": 100,"salary": 1950},"Loan": {"duration": 15,"installment": 180}, "SupremeDirector": "Yes"}

From the OpenShift console under Networking -> Routes, open the AuditUI URL. You should be able to see the executions, the explainability results and all the inputs/outputs of each decision. Enjoy!

New to Kogito? Check out our “get started” page and get up to speed! 😉 This post presents the decision tracing addon: a component of the Kogito runtime quite relevant for the TrustyAI initiative (introduced here and here). One of the key goals of TrustyAI is to enable advanced auditing capabilities, which, as written inRead more →

New to Kogito? Check out our “get started” page and get up to speed! 😉

This post presents the decision tracing addon: a component of the Kogito runtime quite relevant for the TrustyAI initiative (introduced here and here).

One of the key goals of TrustyAI is to enable advanced auditing capabilities, which, as written in the second introductory post, “enables a compliance officer to trace the decision making of the system and ensure it meets regulations”.

The capability to export auditable information whenever a key event occurs is the first mandatory feature that such a system must provide in order to achieve this goal. This is exactly the purpose of the decision tracing addon.

Key concepts

The addon focuses on Kogito applications exposing DMN models (hence the “decision” in the name). Every time a model is executed, it emits a TraceEvent containing all the relevant information about the execution.

Here are some key concepts:

• It works for Kogito applications based on both Quarkus and Spring Boot.
• The TraceEvent is wrapped in a CloudEvent envelope.
• TraceEvents are sent as JSON to a Kafka topic.

The Trusty Service is the designated component of TrustyAI that consumes these events. With Kafka acting as a decoupler, however, custom consumers can be written to match any specific need.

How to use it

The addon has been available as part of Kogito since v0.17.0. It leverages the code generation capabilities of Kogito to minimize the effort required to enable it. There are only two steps:

1. Add it to the dependencies of your project. Make sure to pick the flavour that matches the underlying framework of your Kogito service.
2. Add some properties to configure the connection to Kafka. They currently differ depending on the flavour, so pick the right ones (check the examples below).

Note: be aware that API changes may still occur in the next releases. Also, bugs may be there (that’s code after all, isn’t it?). If you find one, let us know via Kogito Jira.

Usage with Quarkus

1. Here is the dependency to add to your pom.xml (version is automatically taken from kogito-bom):

<dependency>
  <groupId>org.kie.kogito</groupId>
  <artifactId>tracing-decision-quarkus-addon</artifactId>
</dependency>

2. The Quarkus addon uses MicroProfile Reactive Messaging under the hood, so the configuration follows the same rules. Here are the properties:

# Where to find the Kafka broker
kafka.bootstrap.address=localhost:9092

# These two properties must be set with these exact values
mp.messaging.outgoing.kogito-tracing-decision.connector=smallrye-kafka
mp.messaging.outgoing.kogito-tracing-decision.value.serializer=org.apache.kafka.common.serialization.StringSerializer

# These values can be changed with your kafka group ID and topic
# If the topic doesn't exist, the addon tries to create it automatically
mp.messaging.outgoing.kogito-tracing-decision.group.id=kogito-runtimes
mp.messaging.outgoing.kogito-tracing-decision.topic=kogito-tracing-decision

Example with Quarkus

A detailed example on how to use the decision tracing addon with Quarkus can be found here in our kogito-examples repository.

Usage with Spring Boot

1. Here is the dependency to add to your pom.xml (version is automatically taken from kogito-springboot-starter):

<dependency>
  <groupId>org.kie.kogito</groupId>
  <artifactId>tracing-decision-springboot-addon</artifactId>
</dependency>

2. Here are the properties:

# Where to find the Kafka broker
kogito.addon.tracing.decision.kafka.bootstrapAddress=localhost:9092

# The topic name
kogito.addon.tracing.decision.kafka.topic.name:kogito-tracing-decision

# If the topic doesn't exist, the addon tries to create it automatically
# These two additional properties can configure the auto generation
kogito.addon.tracing.decision.kafka.topic.partitions=1
kogito.addon.tracing.decision.kafka.topic.replicationFactor=1

Example with Spring Boot

A detailed example on how to use the decision tracing addon with Spring Boot can be found here in our kogito-examples repository.

Next steps

We’re only at the beginning of the TrustyAI journey. If you want to be part of it with us, stay tuned for more news!

Thanks for reading. 

In this article, we introduce the metrics monitoring add-on for Kogito. This add-on is part of the TrustyAI initiative already introduced in the previous article https://blog.kie.org/2020/06/trusty-ai-introduction.html . Like Quarkus extensions, the Kogito add-ons are modules that can be imported as dependencies and add capabilities to the application. For example, another add-on is the infinispan-persistence-addon thatRead more →

In this article, we introduce the metrics monitoring add-on for Kogito. This add-on is part of the TrustyAI initiative already introduced in the previous article https://blog.kie.org/2020/06/trusty-ai-introduction.html .

Like Quarkus extensions, the Kogito add-ons are modules that can be imported as dependencies and add capabilities to the application. For example, another add-on is the infinispan-persistence-addon that enables the Infinispan persistence.

The add-on we introduce in this post was already available but now with version 0.11 of Kogito new features related to decision monitoring have been added:

1. Export of domain specific monitoring metrics with Prometheus.
2. Generate operational and domain specific grafana dashboards.

In the article cited above, we introduced three personas: the devops engineer, the case worker and the compliance officer. The current version of the add-on exports one or more dashboards for each DMN and DRL resource. In particular, two types of dashboards might be generated depending on the type of the resource: one with operational metrics more oriented for the devops engineer and one with domain specific metrics, oriented to the case worker and the compliance worker needs.

Operational dashboard: this kind of dashboard is generated for each DMN and DRL endpoint and it contains useful information to monitor the status of the applications so as to have a fast reaction in case something goes wrong. The available graphs are about:

• The total number of requests on the endpoint.
• The average number of requests on the endpoint per minute.
• The quantiles on the elapsed time to evaluate the requests.
• Exception details.

Domain specific dashboard: currently this dashboard is exported only for each DMN endpoint. In particular, the domain specific dashboard contains a graph for each type of decision in the DMN model. At the moment, the types number, boolean and string are supported, all the other time-based builtin types will be covered in the next Kogito release. In particular

• if the output of the decision is a number, the graph contains the quantiles for that metric (on a sliding window of 3 minutes).
• If the output is a boolean or a string, the graph contains the number of occurrences for each output (10 minutes average).
• if the output is time-based, a graph containing the quantiles is generated (with different scales and measurement unit depending on the type).

The plan for the next versions of the add-on is to also support complex structures and lists. 

The devops engineer can directly use the dashboards that the add-on generates, or create custom ones manually based on the metrics exported by the application.

How To Use It

There are a few steps to follow to start using this add-on:

• In your kogito project, assuming that you have imported the kogito bom to manage properly the versions of the kogito modules, import the monitoring-prometheus-addon in your pom.xml:

<dependency>
<groupId>org.kie.kogito</groupId>
 <artifactId>monitoring-prometheus-addon</artifactId>
</dependency>

•  In case you are interested about the number of requests on the endpoints and the status code of the responses, add the following class to your project

import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.ext.Provider;

import org.kie.addons.monitoring.system.interceptor.MetricsInterceptor;

@Provider
public class MyInterceptor extends MetricsInterceptor {
    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) {
        super.filter(requestContext, responseContext);
    }
}

At this point, once the application is packaged 

mvn clean package

the dashboards are generated under the path target/generated-resources/kogito/dashboards and the devops engineer can easily inject them during the deployment of the grafana container. 
For the grafana provisioning, we suggest having a look at the official Grafana documentation https://grafana.com/docs/grafana/latest/administration/provisioning/ . The steps to deploy the dashboards will be integrated with Kogito Operator in a future release. 

That’s it! The Kogito application is ready to export operational and domain specific metrics on the endpoint /metrics.

A complete example can be found here https://github.com/kiegroup/kogito-examples/tree/stable/dmn-drools-quarkus-metrics.