Enable performance monitoring for Bitbucket Mesh
This article describes how to enable performance monitoring in Bitbucket Mesh and export performance metrics to various backends.
Why would I want to enable performance monitoring within Bitbucket Mesh?
With performance monitoring, you can easily monitor the application resources consumed by Bitbucket Mesh, enabling you to make better decisions about maintaining and optimizing machine resources.
What can I monitor?
It is possible to monitor various statistics by enabling performance monitoring within Bitbucket Mesh. Below are some examples of some statistics that can be monitored.
gRPC calls statistics
|Number of failed gRPC calls since start
|Number of active gRPC calls
|Number of successful gRPC calls since start
|Total number of gRPC calls since start
Repair operation statistics
These statistics represent statistics of repair operations initiated by Mesh.
Repair operation duration
A repair operation for Mesh takes place in distinct phases, and statistics for each phase are available.
|Duration of the reflog comparison phase of repair
|Duration of the ref comparison phase of repair
|Duration of the fetch objects phase of repair
|Total time taken for repair operations
Repair operation calls
|Number of failed repair operations since start
|Number of active repair operations
|Number of successful repair operations since start
|Total number of repair operations since start
Mesh uses tickets as a mechanism for creating back pressure to prevent the system from being overloaded with requests. The following types of tickets are available:
Hosting tickets: Limits the number of SCM hosting operations, meaning pushes and pulls, which may be running concurrently.
Mirror Hosting tickets: Limits the number of SCM hosting operations served to mirrors, which may be running concurrently. This limit is intended to protect the system's CPU and memory from being consumed excessively by mirror operations.
Command tickets: Limits the number of SCM commands, such as:
git blame, or
git rev-list, which may be running concurrently.
Ref Advertisement tickets: Limits the number of SCM Ref Advertisement operations that may be running concurrently. These are throttled separately from hosting operations as they are much more lightweight and much shorter, so many more of them can run concurrently.
LFS tickets: Limits the number of Git LFS file transfer operations that may be running concurrently. This is primarily intended to prevent Git LFS requests from consuming all available connections, thereby degrading Git hosting operations.
Mesh supports the following metrics for each ticket type:
|Number of tickets currently available for use
|Number of tickets currently in use
|Total number of tickets configured
Expose performance metrics within Bitbucket Mesh
The above metrics above can be published to the following supported backends:
- JMX (Java Management Extensions)
- New Relic
You can publish metrics to a backend by setting the corresponding
management.metrics.export.<backend>.enabled property to
For example, to enable publishing of the metrics to SignalFX, the following property needs to be set in
management.metrics.export.signalfx.enabled = true
Further configuration may be required based on the backend you chose. Refer to the configuration properties for more information.
You can also attach tags to metrics published from a given node by specifying them as a suffix of the
For example, to attach a tag called
application=Mesh to the published metrics, set the the following property in