Monitoring of GitLab.com

On this page

Monitoring

Pingdom Statistics

For a quick view of the availability and performance history of GitLab.com, we use https://stats.pingdom.com. Specifically, this has the availability and latency of reaching

Main Monitoring Dashboards

We collect data using InfluxDB and Prometheus, leveraging available exporters like the node or the postgresql exporters, and we build whatever else is necessary. The data is visualized in graphs and dashboards that are built using Grafana. There are two interfaces to track this, as described in more detail below.

Public monitoring infrastructure

Private monitoring infrastructure

Adding Dashboards

To learn how to setup a new graph or dashboard using Grafana, take a look at the following resources

Selection of Useful Dashboards from the Monitoring

Blackbox Monitoring

Public Whitebox Monitoring

Private Whitebox Monitor

Logs

Network, System, and Application logs are processed, stored, and searched using the ELK stack. For monitoring system performance and metrics Grafana is still the preferred interface. However, for investigating errors and incidents raw logs are available via Kibana at https://log.gitlap.com.

Kibana dashboards are used to monitor application activity, spam events, transient errors, system and network authentication events, security events, etc. Commonly used dashboards are the Abuse, SSH, and Rack Attack dashboards.

Adding dashboards

To learn how to create Kibana dashboards use the following resources:

GitLab Profiler

GitLab profiler data, accessible using your GitLab Google credentials, is a dashboard with links to request profiles and SQL queries run when loading pages on GitLab.com.

To add a page to this dashboard, create a merge request to the gitlab-com/gitlab-profiler project.

Instrumenting Ruby to monitor performance

Blocks of Ruby code can be "instrumented" to measure performance.