Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Design :: [Elasticsearch integration for one namespace]

Implementation Considerations

Infra epic

infra epic

Elastic Cloud

we'll be using a cluster in GCP so we shouldn't be hit by:

staging cluster


production cluster


Operational Considerations


do we need HA? yes:

how many zones should we use? at least two

Which zones the cluster should be in? as close to gitlab infra as possible (ideally in the same zone). At the moment of writing, majority of prod and stg infra is in us-east. However, doesn't allow you to create clusters in that zone.


See monitoring Elastic Cloud in runbooks repo


See alerting Elastic Cloud in runbooks repo

Resizing cluster

See runbooks repo


See runbooks repo

Initial indexing overloading Gitaly

This shouldn't occur since the number of simultaneous sidekiq jobs is limited. Gitaly fleet should already be sized to handle connections from the existing sidekiq nodes.

Initial indexing overloading sidekiq

During tests on staging, there were 2 machines, 8 sidekiq workers in total. They were able to process incoming jobs in real-time (queue = 0). The bottleneck was with network connection between indexer and gitaly