diff --git a/docs/apis-tools/java-client-examples/cluster-topology-request.md b/docs/apis-tools/java-client-examples/cluster-topology-request.md index ac1a9a952fc..31a4108466e 100644 --- a/docs/apis-tools/java-client-examples/cluster-topology-request.md +++ b/docs/apis-tools/java-client-examples/cluster-topology-request.md @@ -11,7 +11,7 @@ This example shows which broker is leader and follower for which partition. This ## Prerequisites -Run the Zeebe broker with endpoints, `localhost:8080` (default REST) and `localhost:26500` (default gRPC). +Run the Zeebe Broker with endpoints `localhost:8080` (default REST) and `localhost:26500` (default gRPC). ## TopologyViewer.java diff --git a/docs/apis-tools/java-client-examples/data-pojo.md b/docs/apis-tools/java-client-examples/data-pojo.md index b73b7bece7c..fc3e9e792f9 100644 --- a/docs/apis-tools/java-client-examples/data-pojo.md +++ b/docs/apis-tools/java-client-examples/data-pojo.md @@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to handle variables as PO ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 2. Run the [deploy a process example](process-deploy.md). ## HandleVariablesAsPojo.java diff --git a/docs/apis-tools/java-client-examples/decision-evaluate.md b/docs/apis-tools/java-client-examples/decision-evaluate.md index b500b4da8b4..c6302c35694 100644 --- a/docs/apis-tools/java-client-examples/decision-evaluate.md +++ b/docs/apis-tools/java-client-examples/decision-evaluate.md @@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to evaluate a decision." ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoDecision.dmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoDecision.dmn) instead of `demoProcess.bpmn`. ## EvaluateDecisionCreator.java diff --git a/docs/apis-tools/java-client-examples/job-worker-open.md b/docs/apis-tools/java-client-examples/job-worker-open.md index 9471c7072a3..8d4c2392038 100644 --- a/docs/apis-tools/java-client-examples/job-worker-open.md +++ b/docs/apis-tools/java-client-examples/job-worker-open.md @@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to open a job worker." ## Prerequisites -- Run the Zeebe broker with endpoint `localhost:26500` (default). +- Run the Zeebe Broker with endpoint `localhost:26500` (default). - Run the [deploy a process example](process-deploy.md). - Run the [create a process instance example](process-instance-create.md) a few times. diff --git a/docs/apis-tools/java-client-examples/process-deploy.md b/docs/apis-tools/java-client-examples/process-deploy.md index 34ae1c4542d..373844a46be 100644 --- a/docs/apis-tools/java-client-examples/process-deploy.md +++ b/docs/apis-tools/java-client-examples/process-deploy.md @@ -11,7 +11,7 @@ description: "Let's analyze the prerequisites and code to deploy a process using ## Prerequisites -Run the Zeebe broker with endpoint `localhost:26500` (default). +Run the Zeebe Broker with endpoint `localhost:26500` (default). ## ProcessDeployer.java diff --git a/docs/apis-tools/java-client-examples/process-instance-create-nonblocking.md b/docs/apis-tools/java-client-examples/process-instance-create-nonblocking.md index 531191dc7b5..aae09cf30e3 100644 --- a/docs/apis-tools/java-client-examples/process-instance-create-nonblocking.md +++ b/docs/apis-tools/java-client-examples/process-instance-create-nonblocking.md @@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create non-blocking pr ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 2. Run the [deploy a process example](process-deploy.md). ## NonBlockingProcessInstanceCreator.java diff --git a/docs/apis-tools/java-client-examples/process-instance-create-with-result.md b/docs/apis-tools/java-client-examples/process-instance-create-with-result.md index 1c9d0c22e4d..e2fbe45d708 100644 --- a/docs/apis-tools/java-client-examples/process-instance-create-with-result.md +++ b/docs/apis-tools/java-client-examples/process-instance-create-with-result.md @@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create a process insta ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoProcessSingleTask.bpmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoProcessSingleTask.bpmn) instead of `demoProcess.bpmn`. ## ProcessInstanceWithResultCreator.java diff --git a/docs/apis-tools/java-client-examples/process-instance-create.md b/docs/apis-tools/java-client-examples/process-instance-create.md index b12e0c0d562..1408e781deb 100644 --- a/docs/apis-tools/java-client-examples/process-instance-create.md +++ b/docs/apis-tools/java-client-examples/process-instance-create.md @@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to create a process instance ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). ## ProcessInstanceCreator.java diff --git a/docs/components/best-practices/architecture/sizing-your-environment.md b/docs/components/best-practices/architecture/sizing-your-environment.md index 5863e9689ab..9dca69ca8cd 100644 --- a/docs/components/best-practices/architecture/sizing-your-environment.md +++ b/docs/components/best-practices/architecture/sizing-your-environment.md @@ -120,7 +120,7 @@ Using your throughput and retention settings, you can now calculate the required ## Understanding sizing and scalability behavior -Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources. +Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe Broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources. All components are clustered to provide high-availability, fault-tolerance and resiliency. diff --git a/docs/components/zeebe/technical-concepts/architecture.md b/docs/components/zeebe/technical-concepts/architecture.md index 8921c856a4d..18487a401ed 100644 --- a/docs/components/zeebe/technical-concepts/architecture.md +++ b/docs/components/zeebe/technical-concepts/architecture.md @@ -52,7 +52,7 @@ The gateway is stateless and sessionless, and gateways can be added as necessary ## Brokers -The Zeebe broker is the distributed workflow engine that tracks the state of active process instances. +The Zeebe Broker is the distributed workflow engine that tracks the state of active process instances. Brokers can be partitioned for horizontal scalability and replicated for fault tolerance. A Zeebe deployment often consists of more than one broker. diff --git a/docs/guides/getting-started-java-spring.md b/docs/guides/getting-started-java-spring.md index b6fe074f3f5..57991df165c 100644 --- a/docs/guides/getting-started-java-spring.md +++ b/docs/guides/getting-started-java-spring.md @@ -125,7 +125,7 @@ Add the following Maven dependency to your Spring Boot Starter project, replacin ### Configure the Zeebe client -Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe broker: +Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe Broker: ```yaml camunda: diff --git a/docs/guides/migrating-from-camunda-7/conceptual-differences.md b/docs/guides/migrating-from-camunda-7/conceptual-differences.md index fa6375d3f8f..96fa8a44d71 100644 --- a/docs/guides/migrating-from-camunda-7/conceptual-differences.md +++ b/docs/guides/migrating-from-camunda-7/conceptual-differences.md @@ -58,7 +58,7 @@ There are several differences between how [multi-tenancy](/self-managed/concepts 2. In Camunda 7, users can deploy shared resources (processes, decisions, and forms) available to all tenants. In Camunda 8, there are no shared resources. This will be added in the future. 3. In Camunda 7, data is mapped to a `null` tenant identifier, meaning by default resources are shared. In Camunda 8, data is mapped to the `` tenant identifier when multi-tenancy is disabled. 4. [Tenant checks in Camunda 7](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#disable-the-transparent-access-restrictions) can be disabled to perform admin/maintenance operations. This can't be done in Camunda 8, but an admin user can be authorized to all tenants, which would result in the same thing. -5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly. +5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe Broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly. ## Process solutions using Spring Boot @@ -123,7 +123,7 @@ With Camunda 7 a typical deployment includes: With Camunda 8 you deploy: - Your Spring Boot application with all custom code and the Zeebe client embedded. This application is typically scaled to at least two instances (for resilience) -- The Zeebe broker, typically scaled to at least three instances (for resilience) +- The Zeebe Broker, typically scaled to at least three instances (for resilience) - An elastic database (for Operate, Tasklist, and Optimize) - Optimize, Operate, and Tasklist (each one is a Java application). You can scale those applications to increase availability if you want. diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md index f546cfe931b..486cd1eb278 100644 --- a/docs/reference/glossary.md +++ b/docs/reference/glossary.md @@ -10,13 +10,13 @@ Synonym to "[Connector](#connector)". ### Broker -A broker is an instance of a Zeebe installation which executes processes and manages process state. A single broker is installed on a single machine. +The [Zeebe Broker](#zeebe-broker) is the distributed workflow engine that tracks the state of active process instances. However, a Zeebe deployment often consists of more than one broker. Brokers can be partitioned for horizontal scalability and replicated for fault tolerance. -- [Architecture](/components/zeebe/technical-concepts/architecture.md#brokers) +- [Architecture](/components/zeebe/technical-concepts/architecture.md) ### Client -A client interacts with the Zeebe broker on behalf of the business application. Clients poll for work from the broker. +A client interacts with the Zeebe Broker on behalf of the business application. Clients poll for work from the broker. - [Architecture](/components/zeebe/technical-concepts/architecture.md#clients) @@ -82,12 +82,6 @@ In a clustered environment, a broker which is not a leader is a follower of a gi - [Clustering](/components/zeebe/technical-concepts/clustering.md#raft-consensus-and-replication-protocol) -### Gateway - -Clients communicate with the Zeebe cluster through a gateway. The gateway provides a REST and gRPC API and forwards client commands to the cluster. Depending on the setup, a gateway can be embedded in the broker or can be configured to be standalone. - -- [Architecture](/components/zeebe/technical-concepts/architecture.md#gateways) - ### Human task Camunda 8 allows you to orchestrate processes with human tasks, which may be [user tasks](#user-task) or [manual tasks](#manual-task). @@ -175,7 +169,7 @@ Outbound [Connectors](#connector) in Camunda 8 allow workflows to trigger with e ### Partition -A partition represents a logical grouping of data in a Zeebe broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration. +A partition represents a logical grouping of data in a Zeebe Broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration. - [Partitions](/components/zeebe/technical-concepts/partitions.md) @@ -293,3 +287,13 @@ See [process instance](#process-instance). ### Workflow instance variable See [process instance variable](#process-instance-variable). + +## Zeebe Broker + +The [Zeebe Broker](/components/zeebe/technical-concepts/architecture.md#brokers) is the distributed workflow engine that tracks the state of active process instances. The Zeebe Broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. + +### Zeebe Gateway + +The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. + +- [Zeebe Gateway overview](/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md) diff --git a/docs/self-managed/about-self-managed.md b/docs/self-managed/about-self-managed.md index 1ee25e43bf4..a1d1f7eae1e 100644 --- a/docs/self-managed/about-self-managed.md +++ b/docs/self-managed/about-self-managed.md @@ -38,4 +38,4 @@ In this configuration, Camunda 8 Self-Managed can be accessed as follows: - Identity, Operate, Optimize, Tasklist, Modeler: `https://camunda.example.com/[identity|operate|optimize|tasklist|modeler]` - Web Modeler also exposes a WebSocket endpoint on `https://camunda.example.com/modeler-ws`. This is only used by the application itself and should not be accessed by users directly. - Keycloak authentication: `https://camunda.example.com/auth` -- Zeebe gateway: `grpc://zeebe.camunda.example.com` +- Zeebe Gateway: `grpc://zeebe.camunda.example.com` diff --git a/docs/self-managed/concepts/multi-region/dual-region.md b/docs/self-managed/concepts/multi-region/dual-region.md index 7d44cadefb3..bfd03c4e5e0 100644 --- a/docs/self-managed/concepts/multi-region/dual-region.md +++ b/docs/self-managed/concepts/multi-region/dual-region.md @@ -98,11 +98,11 @@ Amazon OpenSearch is **not supported** in dual-region configurations. - Required open ports between the two regions: - **9200** for Elasticsearch (for cross-region data pushed by Zeebe). - **26500** for communication to the Zeebe Gateway from clients/workers. - - **26501** and **26502** for communication between Zeebe brokers and Zeebe Gateway. + - **26501** and **26502** for communication between Zeebe brokers and the Zeebe Gateway. ### Zeebe cluster configuration -The following Zeebe brokers and replication configuration is supported: +The following Zeebe brokers and replication configuration are supported: - `clusterSize` must be a multiple of **2** and at least **4** to evenly distribute brokers across the two regions. - `replicationFactor` must be **4** to ensure even partition distribution across regions. diff --git a/docs/self-managed/connectors-deployment/connectors-configuration.md b/docs/self-managed/connectors-deployment/connectors-configuration.md index 3e9eca4acd4..b9aab6d2bb4 100644 --- a/docs/self-managed/connectors-deployment/connectors-configuration.md +++ b/docs/self-managed/connectors-deployment/connectors-configuration.md @@ -54,8 +54,8 @@ Zeebe: | Environment variable | Purpose | | :-------------------------------------------------- | :----------------------------------------------------------------------------- | -| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required) | The base URL of the Zeebe broker (HTTPS) | -| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe broker | +| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required) | The base URL of the Zeebe Broker (HTTPS) | +| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe Broker | ```bash ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS=127.0.0.1:26500 diff --git a/docs/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md b/docs/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md index a06f1b6898b..0e6313d149c 100644 --- a/docs/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md +++ b/docs/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md @@ -21,7 +21,7 @@ Depending on your infrastructure, the default timeouts configured may be too sho You can pass custom timeouts in milliseconds for Web Modeler's Zeebe client to `modeler-restapi` via three individual environment variables: ```shell -ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe gateway +ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe Gateway ZEEBE_AUTH_CONNECT_TIMEOUT=60000 # limit the time to wait for a connection to the OAuth server ZEEBE_AUTH_READ_TIMEOUT=60000 # limits the time to wait for a response from the OAuth server ``` diff --git a/docs/self-managed/operate-deployment/operate-configuration.md b/docs/self-managed/operate-deployment/operate-configuration.md index d5ce349a785..ef22cf4c196 100644 --- a/docs/self-managed/operate-deployment/operate-configuration.md +++ b/docs/self-managed/operate-deployment/operate-configuration.md @@ -209,9 +209,9 @@ camunda.operate: selfSigned: true ``` -## Zeebe broker connection +## Zeebe Broker connection -Operate needs a connection to the Zeebe broker to start the import and execute user operations. +Operate needs a connection to the Zeebe Broker to start the import and execute user operations. ### Settings to connect diff --git a/docs/self-managed/operational-guides/configure-flow-control/configure-flow-control.md b/docs/self-managed/operational-guides/configure-flow-control/configure-flow-control.md index 08cbf734eae..22514755159 100644 --- a/docs/self-managed/operational-guides/configure-flow-control/configure-flow-control.md +++ b/docs/self-managed/operational-guides/configure-flow-control/configure-flow-control.md @@ -21,7 +21,7 @@ A static write rate limit can prevent throughput peaks, and write rate throttlin These write limits are enabled by default in SaaS and disabled in Self-Managed. For most use cases, write rate limits can be enabled as needed if an issue arises. ::: -Flow control is configured in your Zeebe broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates. +Flow control is configured in your Zeebe Broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe Broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates. ```yaml zeebe: diff --git a/docs/self-managed/operational-guides/multi-region/dual-region-ops.md b/docs/self-managed/operational-guides/multi-region/dual-region-ops.md index 722de513fbe..ce7e32aa3b7 100644 --- a/docs/self-managed/operational-guides/multi-region/dual-region-ops.md +++ b/docs/self-managed/operational-guides/multi-region/dual-region-ops.md @@ -147,7 +147,7 @@ Start with creating a port-forward to the `Zeebe Gateway` in the surviving regio The following alternatives to port-forwarding are possible: -- if Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly +- If the Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly - [`exec`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) into an existing pod (such as Elasticsearch), and execute `curl` commands from inside of the pod - [`run`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/) an Ubuntu pod in the cluster to execute `curl` commands from inside the Kubernetes cluster diff --git a/docs/self-managed/setup/deploy/local/local-kubernetes-cluster.md b/docs/self-managed/setup/deploy/local/local-kubernetes-cluster.md index 158da8cc6f8..12c17d7da69 100644 --- a/docs/self-managed/setup/deploy/local/local-kubernetes-cluster.md +++ b/docs/self-managed/setup/deploy/local/local-kubernetes-cluster.md @@ -91,7 +91,7 @@ First, port-forward each of the components. Use a separate terminal for each com ## Connecting to the workflow engine -To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe gateway as follows: +To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: ```sh kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 diff --git a/docs/self-managed/setup/deploy/local/manual.md b/docs/self-managed/setup/deploy/local/manual.md index 053d9b8454b..d03b18b592c 100644 --- a/docs/self-managed/setup/deploy/local/manual.md +++ b/docs/self-managed/setup/deploy/local/manual.md @@ -70,7 +70,7 @@ For **Windows users**, take the following steps: 4. Navigate to the `bin` folder. 5. Start the broker by double-clicking on the `broker.bat` file. -Once the Zeebe broker has started, it should produce the following output: +Once the Zeebe Broker has started, it should produce the following output: ```log 23:39:13.246 [] [main] INFO io.camunda.zeebe.broker.system - Scheduler configuration: Threads{cpu-bound: 2, io-bound: 2}. diff --git a/docs/self-managed/setup/guides/accessing-components-without-ingress.md b/docs/self-managed/setup/guides/accessing-components-without-ingress.md index 706b4293756..07615294c12 100644 --- a/docs/self-managed/setup/guides/accessing-components-without-ingress.md +++ b/docs/self-managed/setup/guides/accessing-components-without-ingress.md @@ -18,7 +18,7 @@ To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 ``` -Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe broker. +Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe Broker. :::note Accessing the Zeebe cluster directly using `kubectl port-forward` is recommended for development purposes. diff --git a/docs/self-managed/setup/install.md b/docs/self-managed/setup/install.md index d34179ca5fe..42cfc4b19d7 100644 --- a/docs/self-managed/setup/install.md +++ b/docs/self-managed/setup/install.md @@ -418,5 +418,5 @@ For upgrading the Camunda Helm chart from one release to another, perform a [Hel ## General notes -- **Zeebe gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe. +- **Zeebe Gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe. - **Zeebe broker nodes** need to be deployed as a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) to preserve the identity of cluster nodes. StatefulSets require persistent storage, which must be allocated in advance. Depending on your cloud provider, the persistent storage differs as it is provider-specific. diff --git a/docs/self-managed/tasklist-deployment/tasklist-configuration.md b/docs/self-managed/tasklist-deployment/tasklist-configuration.md index c2c7dd029af..ffb2b6b4f35 100644 --- a/docs/self-managed/tasklist-deployment/tasklist-configuration.md +++ b/docs/self-managed/tasklist-deployment/tasklist-configuration.md @@ -136,9 +136,9 @@ camunda.tasklist: selfSigned: true ``` -## Zeebe broker connection +## Zeebe Broker connection -Tasklist needs a connection to Zeebe broker to start the import. +Tasklist needs a connection to the Zeebe Broker to start the import. ### Settings to connect diff --git a/docs/self-managed/zeebe-deployment/configuration/broker.md b/docs/self-managed/zeebe-deployment/configuration/broker.md index 395fac66fba..c1df53bf42d 100644 --- a/docs/self-managed/zeebe-deployment/configuration/broker.md +++ b/docs/self-managed/zeebe-deployment/configuration/broker.md @@ -2,7 +2,7 @@ id: broker-config title: "Broker configuration" sidebar_label: "Broker configuration" -description: "Let's analyze how to configure the Zeebe broker" +description: "Let's analyze how to configure the Zeebe Broker" --- A complete broker configuration template is available in the [Zeebe repo](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template). diff --git a/docs/self-managed/zeebe-deployment/configuration/gateway.md b/docs/self-managed/zeebe-deployment/configuration/gateway.md index 583361d09ad..05871704477 100644 --- a/docs/self-managed/zeebe-deployment/configuration/gateway.md +++ b/docs/self-managed/zeebe-deployment/configuration/gateway.md @@ -2,7 +2,7 @@ id: gateway-config title: "Gateway configuration" sidebar_label: "Gateway configuration" -description: "Analyze how to configure the Zeebe gateway, including byte sizes, time units, paths, and sample YAML snippets." +description: "Analyze how to configure the Zeebe Gateway, including byte sizes, time units, paths, and sample YAML snippets." --- The Zeebe Gateway can be configured similarly to the broker via the `application.yaml` file or environment variables. A complete gateway configuration template is available in the [Zeebe repository](https://github.com/camunda/camunda/blob/main/dist/src/main/config/gateway.yaml.template). diff --git a/docs/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md b/docs/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md index fc621c0a837..52a2ab7516c 100644 --- a/docs/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md +++ b/docs/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md @@ -40,7 +40,7 @@ env: ``` This example is downloading the exporters' JAR from a URL and adding the JAR to the `exporters` directory, -which will be scanned for JARs and added to the Zeebe broker classpath. Then, with `environment variables`, +which will be scanned for JARs and added to the Zeebe Broker classpath. Then, with `environment variables`, you can configure the exporter parameters. :::note diff --git a/docs/self-managed/zeebe-deployment/operations/backpressure.md b/docs/self-managed/zeebe-deployment/operations/backpressure.md index 377d12a7492..d32366d5f96 100644 --- a/docs/self-managed/zeebe-deployment/operations/backpressure.md +++ b/docs/self-managed/zeebe-deployment/operations/backpressure.md @@ -34,7 +34,7 @@ The limit and inflight count are calculated per partition. Zeebe uses adaptive algorithms from [concurrency-limits](https://github.com/Netflix/concurrency-limits) to dynamically calculate the limit. Configure Zeebe with one of the backpressure algorithms in the following sections. -The default values can be found in the [Zeebe broker standalone configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) or in the [Zeebe broker configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) in the `# backpressure` section. +The default values can be found in the [Zeebe Broker standalone configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) or in the [Zeebe Broker configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) in the `# backpressure` section. #### Fixed limit diff --git a/docs/self-managed/zeebe-deployment/operations/disk-space.md b/docs/self-managed/zeebe-deployment/operations/disk-space.md index 12cdff52389..d3496d8ce9e 100644 --- a/docs/self-managed/zeebe-deployment/operations/disk-space.md +++ b/docs/self-managed/zeebe-deployment/operations/disk-space.md @@ -4,7 +4,7 @@ title: "Disk space" description: "Understand how Zeebe uses the local disk for storage of its persistent data, and configuring Zeebe settings for the disk usage watermarks." --- -Zeebe uses the local disk for storage of its persistent data. Therefore, if the Zeebe broker runs out of disk space, the system is in an invalid state as the broker cannot update its state. +Zeebe uses the local disk for storage of its persistent data. Therefore, if the Zeebe Broker runs out of disk space, the system is in an invalid state as the broker cannot update its state. To prevent the system from reaching an unrecoverable state, Zeebe expects a minimum size of free disk space available. If this limit is violated, the broker rejects new requests to allow the operations team to free more disk space, and allows the broker to continue to update its state. diff --git a/docs/self-managed/zeebe-deployment/operations/health.md b/docs/self-managed/zeebe-deployment/operations/health.md index b550b8e4325..9ad212e1cdf 100644 --- a/docs/self-managed/zeebe-deployment/operations/health.md +++ b/docs/self-managed/zeebe-deployment/operations/health.md @@ -6,7 +6,7 @@ description: "This document analyzes health status checks and responses." ## Broker -Zeebe broker exposes three HTTP endpoints to query its health status: +The Zeebe Broker exposes three HTTP endpoints to query its health status: - Startup check - Ready check @@ -62,7 +62,7 @@ When a broker becomes unhealthy, it's recommended to check the logs to see what ## Gateway -Zeebe gateway exposes three HTTP endpoints to query its health status: +The Zeebe Gateway exposes three HTTP endpoints to query its health status: - Health status - `http://{zeebe-gateway}:9600/actuator/health` - Startup probe - `http://{zeebe-gateway}:9600/actuator/health/startup` diff --git a/docs/self-managed/zeebe-deployment/operations/management-api.md b/docs/self-managed/zeebe-deployment/operations/management-api.md index 66a49949710..dce07ca6696 100644 --- a/docs/self-managed/zeebe-deployment/operations/management-api.md +++ b/docs/self-managed/zeebe-deployment/operations/management-api.md @@ -1,13 +1,13 @@ --- id: management-api title: "Management API" -description: "Zeebe Gateway also exposes an HTTP endpoint for cluster management operations." +description: "The Zeebe Gateway also exposes an HTTP endpoint for cluster management operations." --- import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; -Besides the [REST](/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md) and [gRPC API](/apis-tools/zeebe-api/grpc.md) for process instance execution, Zeebe Gateway also exposes an HTTP endpoint for cluster management operations. This API is not expected to be used by a typical user, but by a privileged user such as a cluster administrator. It is exposed via a different port and configured using configuration `management.server.port` (or via environment variable `MANAGEMENT_SERVER_PORT`). By default, this is set to `9600`. +Besides the [REST](/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md) and [gRPC API](/apis-tools/zeebe-api/grpc.md) for process instance execution, the Zeebe Gateway also exposes an HTTP endpoint for cluster management operations. This API is not expected to be used by a typical user, but by a privileged user such as a cluster administrator. It is exposed via a different port and configured using configuration `management.server.port` (or via environment variable `MANAGEMENT_SERVER_PORT`). By default, this is set to `9600`. The API is a custom endpoint available via [Spring Boot Actuator](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints). For additional configurations such as security, refer to the Spring Boot documentation. diff --git a/docs/self-managed/zeebe-deployment/operations/network-ports.md b/docs/self-managed/zeebe-deployment/operations/network-ports.md index 45512e7e298..3b3946c2ace 100644 --- a/docs/self-managed/zeebe-deployment/operations/network-ports.md +++ b/docs/self-managed/zeebe-deployment/operations/network-ports.md @@ -19,7 +19,7 @@ Additionally, it will need to communicate with other nodes (mostly brokers) in t To join the cluster, it will also need at least one initial contact point, typically a broker, configured via `zeebe.gateway.cluster.initialContactPoints: [127.0.0.1:26502]`. :::note -You can use all broker connections instead of one to make the startup process of the Zeebe gateway more resilient. +You can use all broker connections instead of one to make the startup process of the Zeebe Gateway more resilient. ::: The relevant [configuration](../configuration/configuration.md) settings are: diff --git a/docs/self-managed/zeebe-deployment/operations/update-zeebe.md b/docs/self-managed/zeebe-deployment/operations/update-zeebe.md index a5d76e5e024..a8d66b7481b 100644 --- a/docs/self-managed/zeebe-deployment/operations/update-zeebe.md +++ b/docs/self-managed/zeebe-deployment/operations/update-zeebe.md @@ -19,7 +19,7 @@ Refer to the [update guide](/self-managed/operational-guides/update-guide/introd A **rolling update** ensures the Zeebe cluster stays available by updating brokers and gateways one by one instead of all at once. -There are three parties to a rolling update: the Zeebe brokers, Zeebe gateways, and the clients. +There are three parts to a rolling update: the Zeebe Broker, Zeebe Gateway, and clients. We recommend updating brokers first, then gateways, and finally clients. This ensures clients don't use new APIs that are not yet supported by the brokers or gateways. @@ -49,7 +49,7 @@ The snapshot period is five minutes by default but is [configurable via `snapsho If your Zeebe deployment is managed by our [Helm charts](/self-managed/setup/install.md), the rolling update procedure is already automated. :::note -Zeebe brokers are managed by a [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). Zeebe gateways are managed by a []`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment). +Zeebe brokers are managed by a [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). Zeebe Gateways are managed by a [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment). ::: #### Updating brokers diff --git a/docs/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md b/docs/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md index 9671048eb13..58cc4817d6b 100644 --- a/docs/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md +++ b/docs/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md @@ -155,7 +155,7 @@ When compiling your class, you need to make sure all compile-time dependencies are provided. In the example above, that means we need the `grpc-api` and `slf4j-api` libraries available when compiling. -Since the interceptor will be running inside the Zeebe gateway, the language +Since the interceptor will be running inside the Zeebe Gateway, the language level of the compiled code must be the same as Zeebe's (i.e. currently JDK 21) or lower. This example thus assumes you're using version 21 of `javac`. ```sh diff --git a/docs/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md b/docs/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md index b3175754810..f67d92f1467 100644 --- a/docs/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md +++ b/docs/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md @@ -8,11 +8,11 @@ description: "Learn about this component and contact point of the Zeebe cluster import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; -The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. For more information about the Zeebe broker, visit our [additional documentation](../../../components/zeebe/technical-concepts/architecture.md#brokers). +The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. For more information about the Zeebe Broker, visit our [additional documentation](../../../components/zeebe/technical-concepts/architecture.md#brokers). -To summarize, the Zeebe broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. The Zeebe Gateway acts as a load balancer and router between Zeebe’s processing partitions. +To summarize, the Zeebe Broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. The Zeebe Gateway acts as a load balancer and router between Zeebe’s processing partitions. -![Zeebe gateway overview](assets/zeebe-gateway-overview.png) +![Zeebe Gateway overview](assets/zeebe-gateway-overview.png) To interact with the Zeebe cluster, the Zeebe client sends a command to the gateway either as a gRPC message (to port `26500` by default), or a plain HTTP request to its REST API (to port `8080` by default). Given the gateway supports gRPC as well as an OpenAPI spec, the user can use several clients in different languages to interact with the Zeebe cluster. For more information, read our [overview](../../../apis-tools/working-with-apis-tools.md). @@ -42,7 +42,7 @@ The Zeebe Gateway can be run in two different ways: embedded and standalone. -Running the gateway in embedded mode means it will run as part of the Zeebe broker. The broker will accept gRPC client messages via the embedded gateway and distribute the translated requests inside the cluster. This means the request accepted by the embedded gateway does not necessarily go to the same broker, where the embedded gateway is running. +Running the gateway in embedded mode means it will run as part of the Zeebe Broker. The broker will accept gRPC client messages via the embedded gateway and distribute the translated requests inside the cluster. This means the request accepted by the embedded gateway does not necessarily go to the same broker, where the embedded gateway is running. The embedded gateway is useful for development and testing purposes, and to reduce the burden of deploying and running multiple applications. For example, in [zeebe-process-test](https://github.com/camunda/zeebe-process-test) an embedded gateway is used to accept the client commands and write directly to the engine. diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/cluster-topology-request.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/cluster-topology-request.md index ac1a9a952fc..31a4108466e 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/cluster-topology-request.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/cluster-topology-request.md @@ -11,7 +11,7 @@ This example shows which broker is leader and follower for which partition. This ## Prerequisites -Run the Zeebe broker with endpoints, `localhost:8080` (default REST) and `localhost:26500` (default gRPC). +Run the Zeebe Broker with endpoints `localhost:8080` (default REST) and `localhost:26500` (default gRPC). ## TopologyViewer.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/data-pojo.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/data-pojo.md index b73b7bece7c..fc3e9e792f9 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/data-pojo.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/data-pojo.md @@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to handle variables as PO ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 2. Run the [deploy a process example](process-deploy.md). ## HandleVariablesAsPojo.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/decision-evaluate.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/decision-evaluate.md index b500b4da8b4..c6302c35694 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/decision-evaluate.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/decision-evaluate.md @@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to evaluate a decision." ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoDecision.dmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoDecision.dmn) instead of `demoProcess.bpmn`. ## EvaluateDecisionCreator.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/job-worker-open.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/job-worker-open.md index 9471c7072a3..8d4c2392038 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/job-worker-open.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/job-worker-open.md @@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to open a job worker." ## Prerequisites -- Run the Zeebe broker with endpoint `localhost:26500` (default). +- Run the Zeebe Broker with endpoint `localhost:26500` (default). - Run the [deploy a process example](process-deploy.md). - Run the [create a process instance example](process-instance-create.md) a few times. diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-deploy.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-deploy.md index 34ae1c4542d..373844a46be 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-deploy.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-deploy.md @@ -11,7 +11,7 @@ description: "Let's analyze the prerequisites and code to deploy a process using ## Prerequisites -Run the Zeebe broker with endpoint `localhost:26500` (default). +Run the Zeebe Broker with endpoint `localhost:26500` (default). ## ProcessDeployer.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-nonblocking.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-nonblocking.md index 531191dc7b5..aae09cf30e3 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-nonblocking.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-nonblocking.md @@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create non-blocking pr ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 2. Run the [deploy a process example](process-deploy.md). ## NonBlockingProcessInstanceCreator.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-with-result.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-with-result.md index 1c9d0c22e4d..e2fbe45d708 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-with-result.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create-with-result.md @@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create a process insta ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoProcessSingleTask.bpmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoProcessSingleTask.bpmn) instead of `demoProcess.bpmn`. ## ProcessInstanceWithResultCreator.java diff --git a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create.md b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create.md index b12e0c0d562..1408e781deb 100644 --- a/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create.md +++ b/versioned_docs/version-8.6/apis-tools/java-client-examples/process-instance-create.md @@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to create a process instance ## Prerequisites -1. Run the Zeebe broker with endpoint `localhost:26500` (default). +1. Run the Zeebe Broker with endpoint `localhost:26500` (default). 1. Run the [deploy a process example](process-deploy.md). ## ProcessInstanceCreator.java diff --git a/versioned_docs/version-8.6/components/best-practices/architecture/sizing-your-environment.md b/versioned_docs/version-8.6/components/best-practices/architecture/sizing-your-environment.md index 5863e9689ab..9dca69ca8cd 100644 --- a/versioned_docs/version-8.6/components/best-practices/architecture/sizing-your-environment.md +++ b/versioned_docs/version-8.6/components/best-practices/architecture/sizing-your-environment.md @@ -120,7 +120,7 @@ Using your throughput and retention settings, you can now calculate the required ## Understanding sizing and scalability behavior -Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources. +Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe Broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources. All components are clustered to provide high-availability, fault-tolerance and resiliency. diff --git a/versioned_docs/version-8.6/components/zeebe/technical-concepts/architecture.md b/versioned_docs/version-8.6/components/zeebe/technical-concepts/architecture.md index 8921c856a4d..18487a401ed 100644 --- a/versioned_docs/version-8.6/components/zeebe/technical-concepts/architecture.md +++ b/versioned_docs/version-8.6/components/zeebe/technical-concepts/architecture.md @@ -52,7 +52,7 @@ The gateway is stateless and sessionless, and gateways can be added as necessary ## Brokers -The Zeebe broker is the distributed workflow engine that tracks the state of active process instances. +The Zeebe Broker is the distributed workflow engine that tracks the state of active process instances. Brokers can be partitioned for horizontal scalability and replicated for fault tolerance. A Zeebe deployment often consists of more than one broker. diff --git a/versioned_docs/version-8.6/components/zeebe/technical-concepts/internal-processing.md b/versioned_docs/version-8.6/components/zeebe/technical-concepts/internal-processing.md index b1ffabbdc74..53a00f92d5a 100644 --- a/versioned_docs/version-8.6/components/zeebe/technical-concepts/internal-processing.md +++ b/versioned_docs/version-8.6/components/zeebe/technical-concepts/internal-processing.md @@ -64,7 +64,7 @@ To avoid such problems, Zeebe employs [flow control](/self-managed/operational-g In the case of backpressure when the broker receives more requests than it can process with an acceptable latency, it rejects some requests. For flow control, it can be used with static write rate limits or throttling which prevents the partition from building an excessive backlog of records not exported. -Backpressure is indicated to the client by throwing a **resource exhausted** exception. If a client sees this exception, it can retry the requests with an appropriate retry strategy. If the rejection rate is high, it indicates the broker is constantly under high load and you need to reduce the rate of requests. Alternatively, you can also increase broker resources to adjust to your needs. In high-load scenarios, it is recommended to [benchmark](https://camunda.com/blog/2022/05/how-to-benchmark-your-camunda-platform-8-cluster/) your Zeebe broker up front to size it correctly. +Backpressure is indicated to the client by throwing a **resource exhausted** exception. If a client sees this exception, it can retry the requests with an appropriate retry strategy. If the rejection rate is high, it indicates the broker is constantly under high load and you need to reduce the rate of requests. Alternatively, you can also increase broker resources to adjust to your needs. In high-load scenarios, it is recommended to [benchmark](https://camunda.com/blog/2022/05/how-to-benchmark-your-camunda-platform-8-cluster/) your Zeebe Broker up front to size it correctly. The maximum rate of requests that can be processed by a broker depends on the processing capacity of the machine, the network latency, current load of the system, etc. There is no fixed limit configured in Zeebe for the maximum rate of requests it accepts. Instead, Zeebe uses an adaptive algorithm to dynamically determine the limit of the number of in-flight requests (the requests that are accepted by the broker, but not yet processed). diff --git a/versioned_docs/version-8.6/guides/getting-started-java-spring.md b/versioned_docs/version-8.6/guides/getting-started-java-spring.md index fc92c742325..c4a964fc92c 100644 --- a/versioned_docs/version-8.6/guides/getting-started-java-spring.md +++ b/versioned_docs/version-8.6/guides/getting-started-java-spring.md @@ -125,7 +125,7 @@ Add the following Maven dependency to your Spring Boot Starter project, replacin ### Configure the Zeebe client -Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe broker: +Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe Broker: ```yaml camunda: diff --git a/versioned_docs/version-8.6/guides/migrating-from-camunda-7/conceptual-differences.md b/versioned_docs/version-8.6/guides/migrating-from-camunda-7/conceptual-differences.md index fa6375d3f8f..96fa8a44d71 100644 --- a/versioned_docs/version-8.6/guides/migrating-from-camunda-7/conceptual-differences.md +++ b/versioned_docs/version-8.6/guides/migrating-from-camunda-7/conceptual-differences.md @@ -58,7 +58,7 @@ There are several differences between how [multi-tenancy](/self-managed/concepts 2. In Camunda 7, users can deploy shared resources (processes, decisions, and forms) available to all tenants. In Camunda 8, there are no shared resources. This will be added in the future. 3. In Camunda 7, data is mapped to a `null` tenant identifier, meaning by default resources are shared. In Camunda 8, data is mapped to the `` tenant identifier when multi-tenancy is disabled. 4. [Tenant checks in Camunda 7](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#disable-the-transparent-access-restrictions) can be disabled to perform admin/maintenance operations. This can't be done in Camunda 8, but an admin user can be authorized to all tenants, which would result in the same thing. -5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly. +5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe Broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly. ## Process solutions using Spring Boot @@ -123,7 +123,7 @@ With Camunda 7 a typical deployment includes: With Camunda 8 you deploy: - Your Spring Boot application with all custom code and the Zeebe client embedded. This application is typically scaled to at least two instances (for resilience) -- The Zeebe broker, typically scaled to at least three instances (for resilience) +- The Zeebe Broker, typically scaled to at least three instances (for resilience) - An elastic database (for Operate, Tasklist, and Optimize) - Optimize, Operate, and Tasklist (each one is a Java application). You can scale those applications to increase availability if you want. diff --git a/versioned_docs/version-8.6/reference/glossary.md b/versioned_docs/version-8.6/reference/glossary.md index f546cfe931b..486cd1eb278 100644 --- a/versioned_docs/version-8.6/reference/glossary.md +++ b/versioned_docs/version-8.6/reference/glossary.md @@ -10,13 +10,13 @@ Synonym to "[Connector](#connector)". ### Broker -A broker is an instance of a Zeebe installation which executes processes and manages process state. A single broker is installed on a single machine. +The [Zeebe Broker](#zeebe-broker) is the distributed workflow engine that tracks the state of active process instances. However, a Zeebe deployment often consists of more than one broker. Brokers can be partitioned for horizontal scalability and replicated for fault tolerance. -- [Architecture](/components/zeebe/technical-concepts/architecture.md#brokers) +- [Architecture](/components/zeebe/technical-concepts/architecture.md) ### Client -A client interacts with the Zeebe broker on behalf of the business application. Clients poll for work from the broker. +A client interacts with the Zeebe Broker on behalf of the business application. Clients poll for work from the broker. - [Architecture](/components/zeebe/technical-concepts/architecture.md#clients) @@ -82,12 +82,6 @@ In a clustered environment, a broker which is not a leader is a follower of a gi - [Clustering](/components/zeebe/technical-concepts/clustering.md#raft-consensus-and-replication-protocol) -### Gateway - -Clients communicate with the Zeebe cluster through a gateway. The gateway provides a REST and gRPC API and forwards client commands to the cluster. Depending on the setup, a gateway can be embedded in the broker or can be configured to be standalone. - -- [Architecture](/components/zeebe/technical-concepts/architecture.md#gateways) - ### Human task Camunda 8 allows you to orchestrate processes with human tasks, which may be [user tasks](#user-task) or [manual tasks](#manual-task). @@ -175,7 +169,7 @@ Outbound [Connectors](#connector) in Camunda 8 allow workflows to trigger with e ### Partition -A partition represents a logical grouping of data in a Zeebe broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration. +A partition represents a logical grouping of data in a Zeebe Broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration. - [Partitions](/components/zeebe/technical-concepts/partitions.md) @@ -293,3 +287,13 @@ See [process instance](#process-instance). ### Workflow instance variable See [process instance variable](#process-instance-variable). + +## Zeebe Broker + +The [Zeebe Broker](/components/zeebe/technical-concepts/architecture.md#brokers) is the distributed workflow engine that tracks the state of active process instances. The Zeebe Broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. + +### Zeebe Gateway + +The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. + +- [Zeebe Gateway overview](/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md) diff --git a/versioned_docs/version-8.6/self-managed/about-self-managed.md b/versioned_docs/version-8.6/self-managed/about-self-managed.md index 1ee25e43bf4..a1d1f7eae1e 100644 --- a/versioned_docs/version-8.6/self-managed/about-self-managed.md +++ b/versioned_docs/version-8.6/self-managed/about-self-managed.md @@ -38,4 +38,4 @@ In this configuration, Camunda 8 Self-Managed can be accessed as follows: - Identity, Operate, Optimize, Tasklist, Modeler: `https://camunda.example.com/[identity|operate|optimize|tasklist|modeler]` - Web Modeler also exposes a WebSocket endpoint on `https://camunda.example.com/modeler-ws`. This is only used by the application itself and should not be accessed by users directly. - Keycloak authentication: `https://camunda.example.com/auth` -- Zeebe gateway: `grpc://zeebe.camunda.example.com` +- Zeebe Gateway: `grpc://zeebe.camunda.example.com` diff --git a/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md b/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md index 7d44cadefb3..d8962662cfd 100644 --- a/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md +++ b/versioned_docs/version-8.6/self-managed/concepts/multi-region/dual-region.md @@ -98,7 +98,7 @@ Amazon OpenSearch is **not supported** in dual-region configurations. - Required open ports between the two regions: - **9200** for Elasticsearch (for cross-region data pushed by Zeebe). - **26500** for communication to the Zeebe Gateway from clients/workers. - - **26501** and **26502** for communication between Zeebe brokers and Zeebe Gateway. + - **26501** and **26502** for communication between Zeebe brokers and the Zeebe Gateway. ### Zeebe cluster configuration diff --git a/versioned_docs/version-8.6/self-managed/connectors-deployment/connectors-configuration.md b/versioned_docs/version-8.6/self-managed/connectors-deployment/connectors-configuration.md index eeb75470595..00dc699e291 100644 --- a/versioned_docs/version-8.6/self-managed/connectors-deployment/connectors-configuration.md +++ b/versioned_docs/version-8.6/self-managed/connectors-deployment/connectors-configuration.md @@ -54,8 +54,8 @@ Zeebe: | Environment variable | Purpose | | :-------------------------------------------------- | :----------------------------------------------------------------------------- | -| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required) | The base URL of the Zeebe broker (HTTPS) | -| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe broker | +| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required) | The base URL of the Zeebe Broker (HTTPS) | +| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe Broker | ```bash ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS=127.0.0.1:26500 diff --git a/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md b/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md index a06f1b6898b..0e6313d149c 100644 --- a/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md +++ b/versioned_docs/version-8.6/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md @@ -21,7 +21,7 @@ Depending on your infrastructure, the default timeouts configured may be too sho You can pass custom timeouts in milliseconds for Web Modeler's Zeebe client to `modeler-restapi` via three individual environment variables: ```shell -ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe gateway +ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe Gateway ZEEBE_AUTH_CONNECT_TIMEOUT=60000 # limit the time to wait for a connection to the OAuth server ZEEBE_AUTH_READ_TIMEOUT=60000 # limits the time to wait for a response from the OAuth server ``` diff --git a/versioned_docs/version-8.6/self-managed/operate-deployment/operate-configuration.md b/versioned_docs/version-8.6/self-managed/operate-deployment/operate-configuration.md index d5ce349a785..ef22cf4c196 100644 --- a/versioned_docs/version-8.6/self-managed/operate-deployment/operate-configuration.md +++ b/versioned_docs/version-8.6/self-managed/operate-deployment/operate-configuration.md @@ -209,9 +209,9 @@ camunda.operate: selfSigned: true ``` -## Zeebe broker connection +## Zeebe Broker connection -Operate needs a connection to the Zeebe broker to start the import and execute user operations. +Operate needs a connection to the Zeebe Broker to start the import and execute user operations. ### Settings to connect diff --git a/versioned_docs/version-8.6/self-managed/operational-guides/configure-flow-control/configure-flow-control.md b/versioned_docs/version-8.6/self-managed/operational-guides/configure-flow-control/configure-flow-control.md index 08cbf734eae..22514755159 100644 --- a/versioned_docs/version-8.6/self-managed/operational-guides/configure-flow-control/configure-flow-control.md +++ b/versioned_docs/version-8.6/self-managed/operational-guides/configure-flow-control/configure-flow-control.md @@ -21,7 +21,7 @@ A static write rate limit can prevent throughput peaks, and write rate throttlin These write limits are enabled by default in SaaS and disabled in Self-Managed. For most use cases, write rate limits can be enabled as needed if an issue arises. ::: -Flow control is configured in your Zeebe broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates. +Flow control is configured in your Zeebe Broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe Broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates. ```yaml zeebe: diff --git a/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md b/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md index fe18d7ab6c1..8b55692c578 100644 --- a/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md +++ b/versioned_docs/version-8.6/self-managed/operational-guides/multi-region/dual-region-ops.md @@ -147,7 +147,7 @@ Start with creating a port-forward to the `Zeebe Gateway` in the surviving regio The following alternatives to port-forwarding are possible: -- if Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly +- If the Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly - [`exec`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) into an existing pod (such as Elasticsearch), and execute `curl` commands from inside of the pod - [`run`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/) an Ubuntu pod in the cluster to execute `curl` commands from inside the Kubernetes cluster diff --git a/versioned_docs/version-8.6/self-managed/operational-guides/troubleshooting/troubleshooting.md b/versioned_docs/version-8.6/self-managed/operational-guides/troubleshooting/troubleshooting.md index 1ce88c46cc0..62e4ec95e6d 100644 --- a/versioned_docs/version-8.6/self-managed/operational-guides/troubleshooting/troubleshooting.md +++ b/versioned_docs/version-8.6/self-managed/operational-guides/troubleshooting/troubleshooting.md @@ -34,7 +34,7 @@ global: ## Zeebe Ingress (gRPC) -Zeebe requires an Ingress controller that supports `gRPC` which is built on top of `HTTP/2` transport layer. Therefore, to expose Zeebe Gateway externally, you need the following: +Zeebe requires an Ingress controller that supports `gRPC` which is built on top of `HTTP/2` transport layer. Therefore, to expose the Zeebe Gateway externally, you need the following: 1. An Ingress controller that supports `gRPC` ([ingress-nginx controller](https://github.com/kubernetes/ingress-nginx) supports it out of the box). 2. TLS (HTTPS) via [Application-Layer Protocol Negotiation (ALPN)](https://www.rfc-editor.org/rfc/rfc7301.html) enabled in the Zeebe Gateway Ingress object. diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md b/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md index 158da8cc6f8..9ccb19cb3a0 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/local/local-kubernetes-cluster.md @@ -91,7 +91,7 @@ First, port-forward each of the components. Use a separate terminal for each com ## Connecting to the workflow engine -To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe gateway as follows: +To interact with the Camunda workflow engine via the Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows: ```sh kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 @@ -169,7 +169,7 @@ Make sure all pods are running with the `kubectl get pods --namespace ingress-ng ## Ingress configuration in Camunda 8 Helm charts -In this document, we will use the combined Ingress configuration. However, there is one quirk with this particular setup to be aware of - Zeebe Gateway uses gRPC, which uses HTTP/2. This means the Zeebe Gateway has to use its own subdomain `zeebe.camunda.local` instead of context path (such as `/zeebe`). +In this document, we will use the combined Ingress configuration. However, there is one quirk with this particular setup to be aware of - the Zeebe Gateway uses gRPC, which uses HTTP/2. This means the Zeebe Gateway has to use its own subdomain `zeebe.camunda.local` instead of context path (such as `/zeebe`). Add the following values to `camunda-platform-core-kind-values.yaml` to allow Camunda 8 components to be discovered by the Ingress controller. diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md b/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md index 053d9b8454b..d03b18b592c 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/local/manual.md @@ -70,7 +70,7 @@ For **Windows users**, take the following steps: 4. Navigate to the `bin` folder. 5. Start the broker by double-clicking on the `broker.bat` file. -Once the Zeebe broker has started, it should produce the following output: +Once the Zeebe Broker has started, it should produce the following output: ```log 23:39:13.246 [] [main] INFO io.camunda.zeebe.broker.system - Scheduler configuration: Threads{cpu-bound: 2, io-bound: 2}. diff --git a/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md b/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md index 706b4293756..0051b6f00d6 100644 --- a/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md +++ b/versioned_docs/version-8.6/self-managed/setup/guides/accessing-components-without-ingress.md @@ -12,13 +12,13 @@ You need to keep `port-forward` running all the time to communicate with the rem ## Accessing workflow engine -To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using [zbctl](/apis-tools/community-clients/cli-client/index.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: +To interact with Camunda workflow engine via the [Zeebe Gateway](/self-managed/zeebe-deployment/configuration/gateway.md) using [zbctl](/apis-tools/community-clients/cli-client/index.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe cluster as following: ``` kubectl port-forward svc/camunda-zeebe-gateway 26500:26500 ``` -Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe broker. +Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe Broker. :::note Accessing the Zeebe cluster directly using `kubectl port-forward` is recommended for development purposes. diff --git a/versioned_docs/version-8.6/self-managed/setup/guides/ingress-setup.md b/versioned_docs/version-8.6/self-managed/setup/guides/ingress-setup.md index 1292157fb9f..ed13861bf1c 100644 --- a/versioned_docs/version-8.6/self-managed/setup/guides/ingress-setup.md +++ b/versioned_docs/version-8.6/self-managed/setup/guides/ingress-setup.md @@ -13,7 +13,7 @@ The separated Ingress configuration has been deprecated in version 8.6. To ensur Camunda 8 Self-Managed has multiple web applications and gRPC services. Both can be accessed externally using Ingress. There are two ways to do this: -1. **Combined setup:** In this setup, there are two Ingress objects: one Ingress object for all Camunda 8 web applications using a single domain. Each application has a sub-path e.g. `camunda.example.com/operate`, and `camunda.example.com/optimize` and another Ingress which uses gRPC protocol for Zeebe Gateway e.g. `zeebe.camunda.example.com`. +1. **Combined setup:** In this setup, there are two Ingress objects: one Ingress object for all Camunda 8 web applications using a single domain. Each application has a sub-path e.g. `camunda.example.com/operate`, and `camunda.example.com/optimize` and another Ingress which uses gRPC protocol for the Zeebe Gateway e.g. `zeebe.camunda.example.com`. 2. **Separated setup:** In this setup, each component has its own Ingress/host e.g. `operate.camunda.example.com`, `optimize.camunda.example.com`, `zeebe.camunda.example.com`, etc. There are no significant differences between the two setups. Rather, they both offer flexibility for different workflows. @@ -38,7 +38,7 @@ Camunda 8 Helm chart doesn't manage or deploy Ingress controllers, it only deplo -In this setup, a single Ingress/domain is used to access Camunda 8 web applications, and another for Zeebe Gateway. By default, all web applications use `/` as a base, so we just need to set the context path, Ingress configuration, and authentication redirect URLs. +In this setup, a single Ingress/domain is used to access Camunda 8 web applications, and another for the Zeebe Gateway. By default, all web applications use `/` as a base, so we just need to set the context path, Ingress configuration, and authentication redirect URLs. ![Camunda 8 Self-Managed Architecture Diagram - Combined Ingress](../../assets/camunda-platform-8-self-managed-architecture-diagram-combined-ingress.png) diff --git a/versioned_docs/version-8.6/self-managed/setup/install.md b/versioned_docs/version-8.6/self-managed/setup/install.md index d34179ca5fe..42cfc4b19d7 100644 --- a/versioned_docs/version-8.6/self-managed/setup/install.md +++ b/versioned_docs/version-8.6/self-managed/setup/install.md @@ -418,5 +418,5 @@ For upgrading the Camunda Helm chart from one release to another, perform a [Hel ## General notes -- **Zeebe gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe. +- **Zeebe Gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe. - **Zeebe broker nodes** need to be deployed as a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) to preserve the identity of cluster nodes. StatefulSets require persistent storage, which must be allocated in advance. Depending on your cloud provider, the persistent storage differs as it is provider-specific. diff --git a/versioned_docs/version-8.6/self-managed/tasklist-deployment/tasklist-configuration.md b/versioned_docs/version-8.6/self-managed/tasklist-deployment/tasklist-configuration.md index c2c7dd029af..ffb2b6b4f35 100644 --- a/versioned_docs/version-8.6/self-managed/tasklist-deployment/tasklist-configuration.md +++ b/versioned_docs/version-8.6/self-managed/tasklist-deployment/tasklist-configuration.md @@ -136,9 +136,9 @@ camunda.tasklist: selfSigned: true ``` -## Zeebe broker connection +## Zeebe Broker connection -Tasklist needs a connection to Zeebe broker to start the import. +Tasklist needs a connection to the Zeebe Broker to start the import. ### Settings to connect diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/broker.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/broker.md index b1313205331..dbb450c9371 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/broker.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/broker.md @@ -2,7 +2,7 @@ id: broker-config title: "Broker configuration" sidebar_label: "Broker configuration" -description: "Let's analyze how to configure the Zeebe broker" +description: "Let's analyze how to configure the Zeebe Broker" --- A complete broker configuration template is available in the [Zeebe repo](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template). diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/gateway.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/gateway.md index 6bc31704616..3134d68b085 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/gateway.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/configuration/gateway.md @@ -2,7 +2,7 @@ id: gateway-config title: "Gateway configuration" sidebar_label: "Gateway configuration" -description: "Analyze how to configure the Zeebe gateway, including byte sizes, time units, paths, and sample YAML snippets." +description: "Analyze how to configure the Zeebe Gateway, including byte sizes, time units, paths, and sample YAML snippets." --- The Zeebe Gateway can be configured similarly to the broker via the `application.yaml` file or environment variables. A complete gateway configuration template is available in the [Zeebe repository](https://github.com/camunda/camunda/blob/main/dist/src/main/config/gateway.yaml.template). diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md index fc621c0a837..52a2ab7516c 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/exporters/install-zeebe-exporters.md @@ -40,7 +40,7 @@ env: ``` This example is downloading the exporters' JAR from a URL and adding the JAR to the `exporters` directory, -which will be scanned for JARs and added to the Zeebe broker classpath. Then, with `environment variables`, +which will be scanned for JARs and added to the Zeebe Broker classpath. Then, with `environment variables`, you can configure the exporter parameters. :::note diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/backpressure.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/backpressure.md index 377d12a7492..d32366d5f96 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/backpressure.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/backpressure.md @@ -34,7 +34,7 @@ The limit and inflight count are calculated per partition. Zeebe uses adaptive algorithms from [concurrency-limits](https://github.com/Netflix/concurrency-limits) to dynamically calculate the limit. Configure Zeebe with one of the backpressure algorithms in the following sections. -The default values can be found in the [Zeebe broker standalone configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) or in the [Zeebe broker configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) in the `# backpressure` section. +The default values can be found in the [Zeebe Broker standalone configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) or in the [Zeebe Broker configuration template](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) in the `# backpressure` section. #### Fixed limit diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/disk-space.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/disk-space.md index 12cdff52389..d3496d8ce9e 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/disk-space.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/disk-space.md @@ -4,7 +4,7 @@ title: "Disk space" description: "Understand how Zeebe uses the local disk for storage of its persistent data, and configuring Zeebe settings for the disk usage watermarks." --- -Zeebe uses the local disk for storage of its persistent data. Therefore, if the Zeebe broker runs out of disk space, the system is in an invalid state as the broker cannot update its state. +Zeebe uses the local disk for storage of its persistent data. Therefore, if the Zeebe Broker runs out of disk space, the system is in an invalid state as the broker cannot update its state. To prevent the system from reaching an unrecoverable state, Zeebe expects a minimum size of free disk space available. If this limit is violated, the broker rejects new requests to allow the operations team to free more disk space, and allows the broker to continue to update its state. diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/health.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/health.md index b550b8e4325..9ad212e1cdf 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/health.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/health.md @@ -6,7 +6,7 @@ description: "This document analyzes health status checks and responses." ## Broker -Zeebe broker exposes three HTTP endpoints to query its health status: +The Zeebe Broker exposes three HTTP endpoints to query its health status: - Startup check - Ready check @@ -62,7 +62,7 @@ When a broker becomes unhealthy, it's recommended to check the logs to see what ## Gateway -Zeebe gateway exposes three HTTP endpoints to query its health status: +The Zeebe Gateway exposes three HTTP endpoints to query its health status: - Health status - `http://{zeebe-gateway}:9600/actuator/health` - Startup probe - `http://{zeebe-gateway}:9600/actuator/health/startup` diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/management-api.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/management-api.md index 66a49949710..dce07ca6696 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/management-api.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/management-api.md @@ -1,13 +1,13 @@ --- id: management-api title: "Management API" -description: "Zeebe Gateway also exposes an HTTP endpoint for cluster management operations." +description: "The Zeebe Gateway also exposes an HTTP endpoint for cluster management operations." --- import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; -Besides the [REST](/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md) and [gRPC API](/apis-tools/zeebe-api/grpc.md) for process instance execution, Zeebe Gateway also exposes an HTTP endpoint for cluster management operations. This API is not expected to be used by a typical user, but by a privileged user such as a cluster administrator. It is exposed via a different port and configured using configuration `management.server.port` (or via environment variable `MANAGEMENT_SERVER_PORT`). By default, this is set to `9600`. +Besides the [REST](/apis-tools/zeebe-api-rest/zeebe-api-rest-overview.md) and [gRPC API](/apis-tools/zeebe-api/grpc.md) for process instance execution, the Zeebe Gateway also exposes an HTTP endpoint for cluster management operations. This API is not expected to be used by a typical user, but by a privileged user such as a cluster administrator. It is exposed via a different port and configured using configuration `management.server.port` (or via environment variable `MANAGEMENT_SERVER_PORT`). By default, this is set to `9600`. The API is a custom endpoint available via [Spring Boot Actuator](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.endpoints). For additional configurations such as security, refer to the Spring Boot documentation. diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/network-ports.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/network-ports.md index 45512e7e298..3b3946c2ace 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/network-ports.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/network-ports.md @@ -19,7 +19,7 @@ Additionally, it will need to communicate with other nodes (mostly brokers) in t To join the cluster, it will also need at least one initial contact point, typically a broker, configured via `zeebe.gateway.cluster.initialContactPoints: [127.0.0.1:26502]`. :::note -You can use all broker connections instead of one to make the startup process of the Zeebe gateway more resilient. +You can use all broker connections instead of one to make the startup process of the Zeebe Gateway more resilient. ::: The relevant [configuration](../configuration/configuration.md) settings are: diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/update-zeebe.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/update-zeebe.md index a5d76e5e024..a8d66b7481b 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/update-zeebe.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/operations/update-zeebe.md @@ -19,7 +19,7 @@ Refer to the [update guide](/self-managed/operational-guides/update-guide/introd A **rolling update** ensures the Zeebe cluster stays available by updating brokers and gateways one by one instead of all at once. -There are three parties to a rolling update: the Zeebe brokers, Zeebe gateways, and the clients. +There are three parts to a rolling update: the Zeebe Broker, Zeebe Gateway, and clients. We recommend updating brokers first, then gateways, and finally clients. This ensures clients don't use new APIs that are not yet supported by the brokers or gateways. @@ -49,7 +49,7 @@ The snapshot period is five minutes by default but is [configurable via `snapsho If your Zeebe deployment is managed by our [Helm charts](/self-managed/setup/install.md), the rolling update procedure is already automated. :::note -Zeebe brokers are managed by a [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). Zeebe gateways are managed by a []`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment). +Zeebe brokers are managed by a [`StatefulSet`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). Zeebe Gateways are managed by a [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment). ::: #### Updating brokers diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md index 9671048eb13..58cc4817d6b 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md @@ -155,7 +155,7 @@ When compiling your class, you need to make sure all compile-time dependencies are provided. In the example above, that means we need the `grpc-api` and `slf4j-api` libraries available when compiling. -Since the interceptor will be running inside the Zeebe gateway, the language +Since the interceptor will be running inside the Zeebe Gateway, the language level of the compiled code must be the same as Zeebe's (i.e. currently JDK 21) or lower. This example thus assumes you're using version 21 of `javac`. ```sh diff --git a/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md b/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md index b3175754810..f67d92f1467 100644 --- a/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md +++ b/versioned_docs/version-8.6/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md @@ -8,11 +8,11 @@ description: "Learn about this component and contact point of the Zeebe cluster import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; -The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. For more information about the Zeebe broker, visit our [additional documentation](../../../components/zeebe/technical-concepts/architecture.md#brokers). +The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster. For more information about the Zeebe Broker, visit our [additional documentation](../../../components/zeebe/technical-concepts/architecture.md#brokers). -To summarize, the Zeebe broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. The Zeebe Gateway acts as a load balancer and router between Zeebe’s processing partitions. +To summarize, the Zeebe Broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions. The Zeebe Gateway acts as a load balancer and router between Zeebe’s processing partitions. -![Zeebe gateway overview](assets/zeebe-gateway-overview.png) +![Zeebe Gateway overview](assets/zeebe-gateway-overview.png) To interact with the Zeebe cluster, the Zeebe client sends a command to the gateway either as a gRPC message (to port `26500` by default), or a plain HTTP request to its REST API (to port `8080` by default). Given the gateway supports gRPC as well as an OpenAPI spec, the user can use several clients in different languages to interact with the Zeebe cluster. For more information, read our [overview](../../../apis-tools/working-with-apis-tools.md). @@ -42,7 +42,7 @@ The Zeebe Gateway can be run in two different ways: embedded and standalone. -Running the gateway in embedded mode means it will run as part of the Zeebe broker. The broker will accept gRPC client messages via the embedded gateway and distribute the translated requests inside the cluster. This means the request accepted by the embedded gateway does not necessarily go to the same broker, where the embedded gateway is running. +Running the gateway in embedded mode means it will run as part of the Zeebe Broker. The broker will accept gRPC client messages via the embedded gateway and distribute the translated requests inside the cluster. This means the request accepted by the embedded gateway does not necessarily go to the same broker, where the embedded gateway is running. The embedded gateway is useful for development and testing purposes, and to reduce the burden of deploying and running multiple applications. For example, in [zeebe-process-test](https://github.com/camunda/zeebe-process-test) an embedded gateway is used to accept the client commands and write directly to the engine.