Details
-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
-
None
Description
User story
We want to understand how many active Camunda projects[versions] are in use, and in what kind of technical environment they are used in so that we can make informed strategic decisions on how to improve the stability and performance of our products.
Background
Currently, we do not know how many active Camunda projects[product versions] are in use, and in what kind of technical environment they are used in.
We consider this to be essential telemetry as this information is crucial for us to further improve the stability and performance of our products, troubleshoot customer issues, increase customer success, and to make strategic decisions on how to best support our users in running successful Camunda projects.
AC
As PM/Engineer/Marketing, I can see
- how many Camunda projects[product versions] are active.
- Camunda version
- Webapps: Cockpit/Tasklist (if they are installed)
- in what technical environment they are used in
- app server vendor and version
- databases vendor and version
- JDK version (optional: vendor)
- how many process instances and decision tables these projects have executed (the pricing metrics we already collect)
- the count of the executed Java API commands per command
This information can be grouped by
- customer name (based on license key) to support our customers adopting Camunda projects successfully.
- Installation IDs (generated once and stored in the engine database, so that every subsequent telemetry call using that databases reuses the ID)
- timeframes (days, weeks, months..) (this does not need to be submitted by the client)
This information should be available for all supported Camunda versions.
Example ET Request
{
"installation": "b647de4d-e557-455a-a64f-feaecd55f53c",
"product": {
"name": "Camunda BPM Runtime",
"version": "7.12.0",
"edition": "community", (based on ee suffix in version)
"internals": {
"license-key": "key...",
"webapps": ["cockpit", "tasklist"],
"database": {"vendor": "postgres", "version": "12.2"},
"jdk": {"vendor": "Oracle", "version": "11"},
"application-server": {"vendor": "JBoss Wildfly", "version": "19"},
"metrics": {"root process instances": {"count": 5000}, "decision-instances": {"count": 10000}},
"commands": {"StartProcessInstanceCmd": {"count": 40}, "FetchExternalTasksCmd": {"count": 100}}
}
}
}
Technical requirements:
Requirements are ordered roughly by priority
First increment
- Implemented product scope
- Collected data: Camunda version, installation id
- Nice to have: Database vendor and version
- Telemetry is deactivated by default
- The telemetry endpoint is configurable in the engine configuration with our current endpoint as the default value
- Similar to the metrics reporter, the process engine has a thread that makes telemetry requests in a configurable interval (every 24 hours)
- Submitting the telemetry must be fail-safe. It should not interfere with other engine operations. Even if the telemetry endpoint is not available, no log outputs should be written on INFO or higher.
- If telemetry is activated is stored as a property in the database
- I can set that via an engine configuration property (is applied as the default value if the property does not exist yet)
- It can be set via Java and REST API (admin permissions)
- The telemetry reporter thread regularly re-checks the property to (de-)activate transmission
Later increments
- Product scope: Remaining data
- I can activate debug logging to debug the telemetry reporter and to inspect the data it submits
- When a license is submitted, the customer name is written into the database. The telemetry reporter uses that for any subsequent telemetry requests.
- A command interceptor is used to count the executed commands
- There is a REST API endpoint to determine if telemetry is enabled (for use in the webapps)
- consideration: telemetry reporter to be able to deal with HTTP redirects if and when it's necessary
- the pings (request) on engine stop (and only) will require to define a timeout (default value tbd) so that the engine stop is not affected by the sending of the telemetry
- consideration: the database driver information could be retrieved as well via DatabaseMetaData
- submits first data on the start of the reporter if the reporter hasn't run in a while
- if the submit fail X (3) times, log a short message that something is wrong without stacktrace.
mgm-controller-panel
This is the controller panel for Smart Panels app
Attachments
Issue Links
- depends on
-
CAM-12108 Fix httpclient shading in the engine jar
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
CAM-12022 Make telemetry submit a fail-safe
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is depended on by
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Done
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- mentioned in
-
Page Loading...