- 17 Aug, 2016 1 commit
-
-
Yorick Peterse authored
GitLab Performance Monitoring is now able to track custom events not directly related to application performance. These events include the number of tags pushed, repositories created, builds registered, etc. The use of these events is to get a better overview of how a GitLab instance is used and how that may affect performance. For example, a large number of Git pushes may have a negative impact on the underlying storage engine. Events are stored in the "events" measurement and are not prefixed with "rails_" or "sidekiq_", this makes it easier to query events with the same name triggered from different parts of the application. All events being stored in the same measurement also makes it easier to downsample data. Currently the following events are tracked: * Creating repositories * Removing repositories * Changing the default branch of a repository * Pushing a new tag * Removing an existing tag * Pushing a commit (along with the branch being pushed to) * Pushing a new branch * Removing an existing branch * Importing a repository (along with the URL we're importing) * Forking a repository (along with the source/target path) * CI builds registered (and when no build could be found) * CI builds being updated * Rails and Sidekiq exceptions Fixes gitlab-org/gitlab-ce#13720
-
- 01 Aug, 2016 1 commit
-
-
Paco Guzman authored
-
- 28 Jul, 2016 1 commit
-
-
Yorick Peterse authored
This reduces the overhead of the method instrumentation code primarily by reducing the number of method calls. There are also some other small optimisations such as not casting timing values to Floats (there's no particular need for this), using Symbols for method call metric names, and reducing the number of Hash lookups for instrumented methods. The exact impact depends on the code being executed. For example, for a method that's only called once the difference won't be very noticeable. However, for methods that are called many times the difference can be more significant. For example, the loading time of a large commit (nrclark/dummy_project@81ebdea5df2fb42e59257cb3eaad671a5c53ca36) was reduced from around 19 seconds to around 15 seconds using these changes.
-
- 19 Jul, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 20 Apr, 2016 1 commit
-
-
Yorick Peterse authored
Merely setting the "action" tag will only result in the transaction itself containing a value for this tag. To ensure other metrics also contain this tag we must set the action using Transaction#action= instead.
-
- 19 Apr, 2016 1 commit
-
-
Yorick Peterse authored
This allows users to configure the number of points stored in a single UDP packet. This in turn can be used to reduce the number of UDP packets being sent at the cost of these packets being somewhat larger. The default setting is 1 point per packet so nothing changes for existing users.
-
- 13 Apr, 2016 1 commit
-
-
Yorick Peterse authored
One use case for this is manually setting the "action" tag for Grape API calls. Due to Grape running blocks there are no human readable method names that can be used for the "action" tag, thus we have to set these manually on a case by case basis.
-
- 11 Apr, 2016 3 commits
-
-
Yorick Peterse authored
If the measure method uses Transaction.current directly the SQL subscriber (Subscribers::ActiveRecord) will add timings of queries triggered by DB cleaner.
-
Yorick Peterse authored
-
Yorick Peterse authored
This makes it easier to query, simplifies the code, and makes it possible to figure out what transaction the data belongs to (simply because it's now stored _in_ the transaction). This new setup keeps track of both the real/wall time _and_ CPU time spent in a block, both measured using milliseconds (to keep all units the same).
-
- 06 Apr, 2016 1 commit
-
-
Yorick Peterse authored
This allows measuring of timings of arbitrary Ruby blocks, this allows for more fine grained performance monitoring. Custom values and tags can also be attached to a block.
-
- 13 Jan, 2016 1 commit
-
-
Yorick Peterse authored
-
- 12 Jan, 2016 1 commit
-
-
Yorick Peterse authored
Where a vew is called from doesn't matter as much. We already know what action they belong to and this is more than enough information. By removing the file/line number from the list of tags we should also be able to reduce the number of series stored in InfluxDB.
-
- 06 Jan, 2016 1 commit
-
-
Yorick Peterse authored
InfluxDB over UDP doesn't use authentication, thus there's no need for these settings.
-
- 31 Dec, 2015 2 commits
-
-
Yorick Peterse authored
This isn't hugely useful and mostly wastes InfluxDB space. We can re-add this whenever needed (but only once we really need it).
-
Yorick Peterse authored
This ensures we don't need to load anything from either PostgreSQL or the Rails cache whenever creating new InfluxDB connections.
-
- 29 Dec, 2015 2 commits
-
-
Yorick Peterse authored
This ensures we can still start up even when not connecting to a database.
-
Yorick Peterse authored
This removes the need for Sidekiq and any overhead/problems introduced by TCP. There are a few things to take into account: 1. When writing data to InfluxDB you may still get an error if the server becomes unavailable during the write. Because of this we're catching all exceptions and just ignore them (for now). 2. Writing via UDP apparently requires the timestamp to be in nanoseconds. Without this data either isn't written properly. 3. Due to the restrictions on UDP buffer sizes we're writing metrics one by one, instead of writing all of them at once.
-
- 28 Dec, 2015 3 commits
-
-
Yorick Peterse authored
This ensures we can still boot, even when the "application_settings" table doesn't exist.
-
Yorick Peterse authored
-
Yorick Peterse authored
-
- 17 Dec, 2015 4 commits
-
-
Yorick Peterse authored
This allows us to track the counts of actual classes instead of "T_XXX" nodes. This is only enabled on CRuby as it uses CRuby specific APIs.
-
Yorick Peterse authored
This ensures we don't end up wasting resources by tracking method calls that only take a few microseconds. By default the threshold is 10 milliseconds but this can be changed using the gitlab.yml configuration file.
-
Yorick Peterse authored
The previous setup wasn't exactly fast, resulting in instrumented method calls taking about 600 times longer than non instrumented calls (including any ActiveSupport code involved). With this commit this slowdown has been reduced to around 185 times.
-
Yorick Peterse authored
This adds the ability to write application metrics (e.g. SQL timings) to InfluxDB. These metrics can in turn be visualized using Grafana, or really anything else that can read from InfluxDB. These metrics can be used to track application performance over time, between different Ruby versions, different GitLab versions, etc. == Transaction Metrics Currently the following is tracked on a per transaction basis (a transaction is a Rails request or a single Sidekiq job): * Timings per query along with the raw (obfuscated) SQL and information about what file the query originated from. * Timings per view along with the path of the view and information about what file triggered the rendering process. * The duration of a request itself along with the controller/worker class and method name. * The duration of any instrumented method calls (more below). == Sampled Metrics Certain metrics can't be directly associated with a transaction. For example, a process' total memory usage is unrelated to any running transactions. While a transaction can result in the memory usage going up there's no accurate way to determine what transaction is to blame, this becomes especially problematic in multi-threaded environments. To solve this problem there's a separate thread that takes samples at a fixed interval. This thread (using the class Gitlab::Metrics::Sampler) currently tracks the following: * The process' total memory usage. * The number of file descriptors opened by the process. * The amount of Ruby objects (using ObjectSpace.count_objects). * GC statistics such as timings, heap slots, etc. The default/current interval is 15 seconds, any smaller interval might put too much pressure on InfluxDB (especially when running dozens of processes). == Method Instrumentation While currently not yet used methods can be instrumented to track how long they take to run. Unlike the likes of New Relic this doesn't require modifying the source code (e.g. including modules), it all happens from the outside. For example, to track `User.by_login` we'd add the following code somewhere in an initializer: Gitlab::Metrics::Instrumentation. instrument_method(User, :by_login) to instead instrument an instance method: Gitlab::Metrics::Instrumentation. instrument_instance_method(User, :save) Instrumentation for either all public model methods or a few crucial ones will be added in the near future, I simply haven't gotten to doing so just yet. == Configuration By default metrics are disabled. This means users don't have to bother setting anything up if they don't want to. Metrics can be enabled by editing one's gitlab.yml configuration file (see config/gitlab.yml.example for example settings). == Writing Data To InfluxDB Because InfluxDB is still a fairly young product I expect the worse. Data loss, unexpected reboots, the database not responding, you name it. Because of this data is _not_ written to InfluxDB directly, instead it's queued and processed by Sidekiq. This ensures that users won't notice anything when InfluxDB is giving trouble. The metrics worker can be started in a standalone manner as following: bundle exec sidekiq -q metrics The corresponding class is called MetricsWorker.
-