Eventuous Connector with EventStoreDB source needs to be hosted as a continuously running service because it must maintain a realtime gRPC subscription. When you deploy a projector, it can be deployed as a sidecar for the connector, or as a standalone service. It could be possible to deploy it as a serverless workload if the serverless solution supports gRPC streaming.
You can use the Connector container to available on Docker Hub in Kubernetes, Docker Compose, or serverless environment like Google CLoud Run or Amazon Fargate. If you want to use the Connector in projector mode, we recommend deploying your gRPC server as a sidecar for the connector.
When running the Connector in a serverless environment, you'd need to set the minimal and maximum container count to one. Remember that the Connector should run continuously, and if you run more than one instance simultaneously, you risk getting unexpected side effects.
More information will be available soon.
To configure the Connector, you need to have a
config.yaml file in the same directory as the Connector. The file consists of three sections:
connector: This section contains the configuration for the Connector.
source: This section contains the configuration for the EventStoreDB source database.
target: This section contains the configuration for the target database or broker.
The target configuration is specific to the target type. Find out more on the specific connector page in the left navigation menu.
Here's an example of a Cconnector section in the configuration file:
The connector id is used as the Eventuous subscription id. If the target is using a checkpoint store, this value will also be used as the checkpoint id. When running multiple connectors with different targets, make sure that each connector has its own unique id.
The assembly name is needed so the Connector can load the specific target implementation. All the target assemblies are included to the container by default, but only the specified assembly is loaded at runtime.
The connector is fully instrumented with traces and metrics. The following configuration parameters are supported:
enabled- if diagnostics are enabled
tracing- the tracing configuration
enabled- if tracing is enabled
exporters- the tracing exporters (zipkin, jaeger, otpl)
metrics- the metrics configuration
enabled- if metrics are enabled
exporters- the metrics exporters (prometheus, otpl)
otlp: Exports metrics using OpenTelemetry protocol. You need to configure the exporter using environment variables as described in the documentation.
prometheus: Adds the Prometheus metrics endpoint at
otlp: Exports traces using OpenTelemetry protocol. You need to configure the exporter using environment variables as described in the documentation.
zipkin: Exports traces to Zipkin. You can configure the exporter using environment variables as described in the documentation.
jaeger: Exports traces to Jaeger. You can configure the exporter using environment variables as described in the documentation.
The source configuration is used to connect to the EventStoreDB, as well as configure the subscription. At the moment, the connector will unconditionally subscribe to
The following configuration parameters are supported:
connectionString- EventStoreDB connection string using gRPC protocol. For example:
concurrencyLimit- the subscription concurrency limit. The default value is
When the subscription concurrency limit is higher than
1, the subscription will partition events between multiple Elasticsearch producer instances. As those producers will run in parallel, it will increase the overall throughput.