docs: Fix links master -> main (#2138)

There are a few repos which have migrated from `master` to `main` this
reflects that change for the ones which have made the transition.

Additionally cleanup some End of Line whitespace.

Signed-off-by: Harold Dost <[email protected]>

Author: hdost

MAINTAINERS.md

@@ -1,12 +1,12 @@
 Documentation that refers to a specific project within the Prometheus ecosystem
 is maintained by the maintainers of the respective project. For example, refer
 to the maintainers specified in Alertmanager's
-[MAINTAINERS.md](https://github.com/prometheus/alertmanager/blob/master/MAINTAINERS.md)
+[MAINTAINERS.md](https://github.com/prometheus/alertmanager/blob/main/MAINTAINERS.md)
 file for documentation about the Alertmanager.
 
 Note that the documentation for the Prometheus server is located in the
 [prometheus/prometheus
-repository](https://github.com/prometheus/prometheus/tree/master/docs) itself.
+repository](https://github.com/prometheus/prometheus/tree/main/docs) itself.
 
 For anything that is not documentation for a specific project, refer to the
 following maintainers with their focus areas:

README.md

@@ -9,7 +9,7 @@ See [`CONTRIBUTING.md`](CONTRIBUTING.md) for general instructions for new Promet
 
 The main documentation contents of this website are located in the [`content/docs`](content/docs) directory.
 
-Documentation concerning the Prometheus server is [maintained in the Prometheus server repository](https://github.com/prometheus/prometheus/tree/master/docs) and cloned into the website at build time.
+Documentation concerning the Prometheus server is [maintained in the Prometheus server repository](https://github.com/prometheus/prometheus/tree/main/docs) and cloned into the website at build time.
 
 As a guideline, please keep the documentation generally applicable and avoid use-case-specific changes.
 
@@ -61,7 +61,7 @@ If you have the prerequisite access rights, you can view the Netlify settings he
 * GitHub webhook notifying Netlify of branch changes: https://github.com/prometheus/docs/settings/hooks
 * Netlify project: https://app.netlify.com/sites/prometheus-docs
 
-Changes to the `master` branch are deployed to the main site at https://prometheus.io.
+Changes to the `main` branch are deployed to the main site at https://prometheus.io.
 
 Netlify also creates preview deploys for every pull request. To view these for a PR where all checks have passed:
 

content/blog/2015-06-01-advanced-service-discovery.md

@@ -16,7 +16,7 @@ mechanisms to Prometheus.
 
 Aside from many smaller fixes and improvements, you can now also reload your configuration during
 runtime by sending a `SIGHUP` to the Prometheus process. For a full list of changes, check the
-[changelog for this release](https://github.com/prometheus/prometheus/blob/master/CHANGELOG.md#0140--2015-06-01).
+[changelog for this release](https://github.com/prometheus/prometheus/blob/main/CHANGELOG.md#0140--2015-06-01).
 
 In this blog post, we will take a closer look at the built-in service discovery mechanisms and provide
 some practical examples. As an additional resource, see

content/blog/2017-06-21-prometheus-20-alpha3-new-rule-format.md

@@ -25,7 +25,7 @@ Alerting and recording rules are one of the critical features of Prometheus. But
 
 * All rules ran with the same interval. We could have some heavy rules that are better off being run at a 10-minute interval and some rules that could be run at 15-second intervals.
 
-* All rules were evaluated concurrently, which is actually Prometheus’ oldest [open bug](https://github.com/prometheus/prometheus/blob/master/rules/manager.go#L267). This has a couple of issues, the obvious one being that the load spikes every eval interval if you have a lot of rules. The other being that rules that depend on each other might be fed outdated data. For example:
+* All rules were evaluated concurrently, which is actually Prometheus’ oldest [open bug](https://github.com/prometheus/prometheus/blob/main/rules/manager.go#L267). This has a couple of issues, the obvious one being that the load spikes every eval interval if you have a lot of rules. The other being that rules that depend on each other might be fed outdated data. For example:
 
 ```
 instance:network_bytes:rate1m = sum by(instance) (rate(network_bytes_total[1m]))

content/blog/2018-07-05-implementing-custom-sd.md

@@ -16,27 +16,27 @@ outside the team and then not maintained or tested well. We want to commit to on
 integration with service discovery mechanisms that we know we can maintain, and that work as intended.
 For this reason, there is currently a moratorium on new SD integrations.
 
-However, we know there is still a desire to be able to integrate with other SD mechanisms, such as 
-Docker Swarm. Recently a small code change plus an example was committed to the documentation 
-[directory](https://github.com/prometheus/prometheus/tree/master/documentation/examples/custom-sd)
+However, we know there is still a desire to be able to integrate with other SD mechanisms, such as
+Docker Swarm. Recently a small code change plus an example was committed to the documentation
+[directory](https://github.com/prometheus/prometheus/tree/main/documentation/examples/custom-sd)
 within the Prometheus repository for implementing a custom service discovery integration without having
 to merge it into the main Prometheus binary. The code change allows us to make use of the internal
 Discovery Manager code to write another executable that interacts with a new SD mechanism and outputs
 a file that is compatible with Prometheus' file\_sd. By co-locating Prometheus and our new executable
 we can configure Prometheus to read the file\_sd-compatible output of our executable, and therefore
 scrape targets from that service discovery mechanism. In the future this will enable us to move SD
 integrations out of the main Prometheus binary, as well as to move stable SD integrations that make
-use of the adapter into the Prometheus 
-[discovery](https://github.com/prometheus/prometheus/tree/master/discovery) package. 
+use of the adapter into the Prometheus
+[discovery](https://github.com/prometheus/prometheus/tree/main/discovery) package.
 
-Integrations using file_sd, such as those that are implemented with the adapter code, are listed 
+Integrations using file_sd, such as those that are implemented with the adapter code, are listed
 [here](https://prometheus.io/docs/operating/integrations/#file-service-discovery).
 
 Let’s take a look at the example code.
 
 ## Adapter
-First we have the file 
-[adapter.go](https://github.com/prometheus/prometheus/blob/master/documentation/examples/custom-sd/adapter/adapter.go).
+First we have the file
+[adapter.go](https://github.com/prometheus/prometheus/blob/main/documentation/examples/custom-sd/adapter/adapter.go).
 You can just copy this file for your custom SD implementation, but it's useful to understand what's
 happening here.
 
@@ -70,25 +70,25 @@ from our SD mechanism.
         Labels  map[string]string `json:"labels"`
     }
 
-This `customSD` struct exists mostly to help us convert the internal Prometheus `targetgroup.Group` 
+This `customSD` struct exists mostly to help us convert the internal Prometheus `targetgroup.Group`
 struct into JSON for the file\_sd format.
 
 When running, the adapter will listen on a channel for updates from our custom SD implementation.
 Upon receiving an update, it will parse the targetgroup.Groups into another `map[string]*customSD`,
 and compare it with what’s stored in the `groups` field of Adapter. If the two are different, we assign
-the new groups to the Adapter struct, and write them as JSON to the output file. Note that this 
+the new groups to the Adapter struct, and write them as JSON to the output file. Note that this
 implementation assumes that each update sent by the SD implementation down the channel contains
 the full list of all target groups the SD knows about.
 
 ## Custom SD Implementation
 
 Now we want to actually use the Adapter to implement our own custom SD. A full working example is in
 the same examples directory
-[here](https://github.com/prometheus/prometheus/blob/master/documentation/examples/custom-sd/adapter-usage/main.go).  
+[here](https://github.com/prometheus/prometheus/blob/main/documentation/examples/custom-sd/adapter-usage/main.go).
 
-Here you can see that we’re importing the adapter code 
+Here you can see that we’re importing the adapter code
 `"github.com/prometheus/prometheus/documentation/examples/custom-sd/adapter"` as well as some other
-Prometheus libraries. In order to write a custom SD we need an implementation of the Discoverer interface. 
+Prometheus libraries. In order to write a custom SD we need an implementation of the Discoverer interface.
 
     // Discoverer provides information about target groups. It maintains a set
     // of sources from which TargetGroups can originate. Whenever a discovery provider
@@ -110,13 +110,13 @@ We really just have to implement one function, `Run(ctx context.Context, up chan
 This is the function the manager within the Adapter code will call within a goroutine. The Run function
 makes use of a context to know when to exit, and is passed a channel for sending it's updates of target groups.
 
-Looking at the [Run](https://github.com/prometheus/prometheus/blob/master/documentation/examples/custom-sd/adapter-usage/main.go#L153-L211) 
+Looking at the [Run](https://github.com/prometheus/prometheus/blob/main/documentation/examples/custom-sd/adapter-usage/main.go#L153-L211)
 function within the provided example, we can see a few key things happening that we would need to do
 in an implementation for another SD. We periodically make calls, in this case to Consul (for the sake
-of this example, assume there isn’t already a built-in Consul SD implementation), and convert the 
+of this example, assume there isn’t already a built-in Consul SD implementation), and convert the
 response to a set of `targetgroup.Group` structs. Because of the way Consul works, we have to first make
 a call to get all known services, and then another call per service to get information about all the
-backing instances. 
+backing instances.
 
 Note the comment above the loop that’s calling out to Consul for each service:
 
@@ -149,7 +149,7 @@ Prometheus as Docker containers via docker-compose when working with the example
         container_name: consul
         ports:
         - 8300:8300
-        - 8500:8500      
+        - 8500:8500
         volumes:
         - ${PWD}/consul.json:/consul/config/consul.json
     prometheus: