Unverified Commit 071990ca authored by Yoginth's avatar Yoginth 🌳

Fix Typos

parent b83c43a6
......@@ -70,7 +70,7 @@ task in the chef-repo with `rake -T`.
# Caveats when using `Gitlab::Vault`
Using the `Gitlab::Vault` to access secrets, may lead to confussion since
Using the `Gitlab::Vault` to access secrets, may lead to confusion since
it masks what it is [actually doing](https://gitlab.com/gitlab-cookbooks/gitlab-vault/blob/master/libraries/vault.rb).
## Mixing
......
......@@ -36,7 +36,7 @@ Typically, we're interested in locating project meta data in the `projects` tabl
#### Export project from database backup and import into GitLab
Here, we use the restored database instance with a GitLab install to export the project through the standard import/export mechanism. We want to avoid starting a full GitLab instance (to perform the export throught the UI) because this sits on a full-sized production database. Instead, we use a rails console to trigger the export.
Here, we use the restored database instance with a GitLab install to export the project through the standard import/export mechanism. We want to avoid starting a full GitLab instance (to perform the export throughout the UI) because this sits on a full-sized production database. Instead, we use a rails console to trigger the export.
1. Start Redis: `gitlab-ctl start redis` (Redis is not going to be used really, but it's a required dependency)
2. Start Rails: `gitlab-rails c`
......
......@@ -19,7 +19,7 @@ You have to be a GitLab employee to have access to it.
* ssh into the host
* turn into root
* run `ls -latr /var/opt/gitlab/gitlab-rails/upgrade-status`
* you will get an ouput like this:
* you will get an output like this:
```
-rw------- 1 root root 2 Jun 27 07:17 db-migrate-6acdf1f
-rw------- 1 root root 2 Jun 28 07:24 db-migrate-c9a4626
......
......@@ -108,7 +108,7 @@ internal projects. For more information see the
## Tooling
* There are helper scripts in [chef-repo](https://ops.gitlab.net/gitlab-cookbooks/chef-repo) to assist setting server statuses. In general, it is advised to always drain active connections from a server before rebooting.
* For controling traffic to canary there are chatops commands, for more
* For controlling traffic to canary there are chatops commands, for more
information see the
[canary chatops documentation](https://gitlab.com/gitlab-org/release/docs/blob/master/general/deploy/canary.md#canary-chatops)
......
......@@ -22,14 +22,14 @@ log messages are expired in SD, but remain in GCS.
## Using the UI
These instructions are similiar in both the new style (within `console.cloud.google.com`)
These instructions are similar in both the new style (within `console.cloud.google.com`)
and the old style (external page), but the screen shots may appear with
differing styles.
1. Create a dataset if necessary to group related tables.
2. Click on a control to "Add a new table".
3. Choose "Google Cloud Storage" with "JSON (Newline Delimted)" as the `Source data`.
4. Using the browse functionality to find an apropriate bucket is not always an option, as only buckets in the same project are listed and data is usually imported from,
4. Using the browse functionality to find an appropriate bucket is not always an option, as only buckets in the same project are listed and data is usually imported from,
for example, gitlab-production or gitlab-internal. Go to the ["Google Cloud Storage" browser](https://console.cloud.google.com/storage/browser/) and find the data you want to load.
5. Insert the bucket URI as follows: `bucket/folder/folder/myfile.JSON` for a single file or `bucket/folder/folder/*` for all files in that folder.
......
......@@ -17,7 +17,7 @@ During an incident there are at least 2 roles, and one more optional
* The point person will
* Handle updating the @gitlabstatus account explaining what is going on in a simple yet reassuring way.
* Synchronize efforts accross the production engineering team
* Synchronize efforts across the production engineering team
* Pull other people in when consultation is needed.
* Declare a major outage when we are meeting the definition.
* Post `@channel, we have a major outage and need help creating a live streaming war room, refer to [runbooks-production-incident]` into the #general slack channel.
......
......@@ -211,7 +211,7 @@ This includes the topology (who is a slave of whom), the replication slot names
Will also show a quick overview of this information.
repmgr keeps track of these things while repmgrd is responsible for ensuring the master is availible.
repmgr keeps track of these things while repmgrd is responsible for ensuring the master is available.
If it detects a failure, it will cause an internal election, promote one of the standby nodes, and
reconfigure the other nodes to follow the new master. On the new master, it will setup the
replication slots in accordance with the `slot_name` column above:
......
......@@ -97,7 +97,7 @@ Notice that:
- `fqdn` should contain only a domain name (without scheme, port or path parts that are present in URL) and be set
to the FQDN under which the application is accessible, e.g. `prometheus.gitlab.com`.
The last step is to update `run_list` array of the specifed role with `"recipe[gitlab-oauth2-proxy]"`:
The last step is to update `run_list` array of the specified role with `"recipe[gitlab-oauth2-proxy]"`:
```json
(...)
......
......@@ -10,7 +10,7 @@ gitlab-ops project for network peering.
## Reserving a new subnet
- Update this MR with a new allocation, pick a row that has `AVAILABE GCP`, if
- Update this MR with a new allocation, pick a row that has `AVAILABLE GCP`, if
needed we can start using previously allocated subnets for Azure
- Larger subnets can be split into smaller ones, if necessary
......
......@@ -279,7 +279,7 @@ time wait
```
> **NOTICE:**
Be aware, that gracefull restart of whole CI Runners fleet may take up to several hours!
Be aware, that graceful restart of whole CI Runners fleet may take up to several hours!
6-8 hours is the usual timing. Until we'll finish our plan to
[use K8S to deploy Runner Managers][k8s-deployment] anyone that needs to update/restart
Runner on our CI fleet should expect, that the operation will be **really long**.
......
......@@ -83,7 +83,7 @@ sudo apt-get purge osquery
Uptycs does offer a way to push updated packages directly to registered assets... but that only works for existing assets and we want new assets to get the same version as deployed across the environment so we should roll updates through Chef.
1. Download the latest `asset package` from the [Uptycs Configuration](https://gitlab.uptycs.io/ui/config) page, selecting the `Ubuntu, Debian` package type and the appropiate asset group (this will likely be `gitlab-production`). The file will appear as `osquery-<<VERSION>>-Uptycs.deb` making note of the version number for later. **NOTE:** Download both the `gitlab-staging` and `gitlab-production` packages (making sure to differentiate between the two) so there isn't an Uptycs version bump between staging and production deployment.
1. Download the latest `asset package` from the [Uptycs Configuration](https://gitlab.uptycs.io/ui/config) page, selecting the `Ubuntu, Debian` package type and the appropriate asset group (this will likely be `gitlab-production`). The file will appear as `osquery-<<VERSION>>-Uptycs.deb` making note of the version number for later. **NOTE:** Download both the `gitlab-staging` and `gitlab-production` packages (making sure to differentiate between the two) so there isn't an Uptycs version bump between staging and production deployment.
1. Upload the packages into the `gitlab-gstg-security\uptycs` and `gitlab-gprd-security\uptycs` buckets in the `gitlab-staging` and `gitlab-production` GCP projects.
1. Submit an MR to the [gstg-base.json](https://ops.gitlab.net/gitlab-cookbooks/chef-repo/blob/master/roles/gstg-base.json), updating the `version` number and sha256 `hash` values to reflect the new package. This will then deploy the updated Uptycs package to GSTG within 30 minutes.
1. Let the new Uptycs version bake for a time period (24hrs?).
......
......@@ -108,7 +108,7 @@ groups:
pager: pagerduty
severity: critical
annotations:
description: We are having a high rate of 5xx accross other backends (web(sockets)?/api/registry/etc, anything except https_git). It's likely that customers are impacted.
description: We are having a high rate of 5xx across other backends (web(sockets)?/api/registry/etc, anything except https_git). It's likely that customers are impacted.
runbook: troubleshooting/high-error-rate.md
title: Increased Error Rate Across Fleet
- alert: IncreasedBackendConnectionErrors
......
......@@ -300,7 +300,7 @@ groups:
channel: database
annotations:
description: Database on {{$labels.fqdn}} setting now {{$labels.__name__}}={{$value}}
title: Postgres Database configuration change has occured on "{{$labels.fqdn}}"
title: Postgres Database configuration change has occurred on "{{$labels.fqdn}}"
- alert: PostgreSQL_TooFewPrometheusScrapes
expr: rate(pg_exporter_scrapes_total[1m]) < 1 / 60
for: 5m
......
......@@ -35,7 +35,7 @@ def validate(service_catalog_path)
service_label = service["label"]
raise "'#{service_name}' | label field must be string" unless service_label.is_a? String
# Bussiness
# Business
# =========
# requirement
......
......@@ -31,6 +31,6 @@ request latency is a function of repository size and time since last GC. In norm
Including this in the apdex score is unhelpful and does not provide insight into the state of the service, so it is excluded from
the metric.
## Service Availablity Definitions
## Service Availability Definitions
The definitions of service availability are defined in https://gitlab.com/gitlab-com/runbooks/blob/master/rules/service_apdex.yml
......@@ -4,7 +4,7 @@ At GitLab, we define the availability of a service as a ratio of: `the number of
It is a measure of the health-check status of a service.
For example, if we expect there to be 20 `unicorn` processes in the `web` fleet and 15 are available and reporting as healthy, then the availablity of the `unicorn` _component_ of the `web` _service_ is 0.75, or 75%.
For example, if we expect there to be 20 `unicorn` processes in the `web` fleet and 15 are available and reporting as healthy, then the availability of the `unicorn` _component_ of the `web` _service_ is 0.75, or 75%.
## Determining availability
......@@ -16,6 +16,6 @@ This is usually done in one of three ways:
1. For services that provide neither a Prometheus exporter sidecar, nor an internal scrape endpoint, we may rely on an external service health check, for example, for services HAProxy metrics can provide an insight into the status of the service. This is the least desirable approach.
## Service Availablity Definitions
## Service Availability Definitions
The definitions of service availability are defined in https://gitlab.com/gitlab-com/runbooks/blob/master/rules/service_availability.yml
......@@ -10,6 +10,6 @@ This is probably best explained with an example: The `web` service is comprised
A single error in the `unicorn` component may bubble up and may be reported as three `500` errors - one in `unicorn`, one in `workhorse` and one in `nginx`. The
error rate of the service is the sum of these values, so would report 3 for a single error bubbling up through the layers.
## Service Availablity Definitions
## Service Availability Definitions
The definitions of service availability are defined in https://gitlab.com/gitlab-com/runbooks/blob/master/rules/service_error_rate.yml
......@@ -13,6 +13,6 @@ therefore reflect three requests, rather than one.
Since each component is reporting metrics separately, it's easier to handle things in this manner, than attempting to correlate multiple
sources to a single request.
## Service Availablity Definitions
## Service Availability Definitions
The definitions of service availability are defined in https://gitlab.com/gitlab-com/runbooks/blob/master/rules/service_ops_rate.yml
......@@ -18,7 +18,7 @@ Existing fields mappings [cannot be updated](https://www.elastic.co/guide/en/ela
but since [set our indexes name with the current day](https://gitlab.com/gitlab-cookbooks/gitlab-elk/blob/3cfa7707a99b8b23a795e4104c564b39e94e2c23/attributes/default.rb#L62)
the following day's index should create the mapping matching the new log
structure and logging should resume working correctly. If you need to fix the
issue before that you can override the index name on the appropiate pubsub
issue before that you can override the index name on the appropriate pubsub
node's `/opt/pubsubbeat/pubsubbeat.yml` (property `output.elasticsearch.index`)
and restart the pubsub service on that node. You should rollback that change
afterwards.
......@@ -21,7 +21,7 @@
* A S2 level incident lasting 3 days, led to disruption to git clones, in particular for the `www-gitlab-com`, `gitlab-ee`, `gitlab-ce`
although many others were affected to.
* Diagnosis went around in circles:
* Initially targetted abuse
* Initially targeted abuse
* High CI activity rates
* Workhorse throughput
* Network issues
......
......@@ -329,7 +329,7 @@ buggy web or api endpoint (or if it can't be determined at all.)
If the source is determined and it's necessary and expected that it
perform a high rate of updates or deletes on a table then it can be
accomodated by adjusting the autovacuum settings. Typically this is
accommodated by adjusting the autovacuum settings. Typically this is
necessary for small frequently updated state tables which are better
handled using Redis variables.
......
......@@ -20,5 +20,5 @@ The rules are expensive, and look over a large number of metrics and/or samples.
Reduce the load on the Prometheus server by:
* Reduce the number of executed rules in a rule group so that they can be executed in parallel.
* Reduce the number of series, or amount of smaples required to evaluate a rule.
* Reduce the number of series, or amount of samples required to evaluate a rule.
* Increase the memory or other node resources to speed up evaluations.
......@@ -11,7 +11,7 @@
### ReactiveCachingWorker
* This one likes to fire when end users might have misconfigured an integration
with thier project.
with their project.
* As a quick example, if they utilize the Bamboo CI Integration, they are
required to input a server fqdn. Should this be incorrect, or if their
Bamboo server is down, the integration might fail.
......@@ -23,7 +23,7 @@
Errno::EHOSTUNREACHSidekiq/ReactiveCachingWorker
Failed to open TCP connection to 192.0.2.188:8089 (No route to host -connect(2)...
```
* In this case we can quickly discern that some integration is not successfullly
* In this case we can quickly discern that some integration is not successfully
connecting to this IP address
* Browse into that error
* In the "additional data", subsection "sidekiq", you'll find something
......
......@@ -17,7 +17,7 @@
* A S2 level incident lasting 3 days, led to disruption to git clones, in particular for the `www-gitlab-com`, `gitlab-ee`, `gitlab-ce`
although many others were affected to.
* Diagnosis went around in circles:
* Initially targetted abuse
* Initially targeted abuse
* High CI activity rates
* Workhorse throughput
* Network issues
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment