The server is configured by a YAML configuration file. The easiest way to start is by generating it with the CLI or by
downloading a sample configuration file, and then tweaking it to fit your needs.
listen_addr: 0.0.0.0:8900state_store_path: /tmp/indexify/stateblob_storage: backend: disk disk: path: /tmp/indexify/blobs
listen_addr: The interface on which the servers listens on. Typically you would want to listen on all interfaces. Default: 0.0.0.0:8900.
state_store_path: Path where the state store is stored. This is where the state of the graph is stored. This is needed for resuming the graph from where it left off in case of a failure. Default: indexify_storage.
blob_storage: Configuration for storing blobs. Blobs are raw bytes of data that are stored in the system. This is used for storing intermediate data between functions.
For S3 Storage, you’ll need to also ensure you have the two following environment variables configured. Once you’ve configured these environment variables, our S3 integration will take care of the rest
You can fetch the current Executor health status by issuing an HTTP GET request to its
monitoring endpoint, e.g.:
Copy
Ask AI
curl localhost:7000/monitoring/health{"status": "nok", "message": "A Function Executor health check failed", "checker": "GenericHealthChecker"}
An HTTP status 200 means that Executor is healthy, 503 means that health check failed. We recommend to automatically
restart the Executor if its health checks are failing because it helps to mitigate recurring bugs in functions,
OS drivers and etc.You can specify a different monitoring server and port for an Executor using its CLI arguments
--monitoring-server-host and --monitoring-server-port.