Documentation: fix typos

Documentation/alertmanager.md

@@ -51,12 +51,12 @@ A healthy node would be one that has joined the existing mesh network and has
 been communicated the state that it missed while that particular instance was
 down for the upgrade.
 
-Currently there is no way to tell whether an Alertmanger instance is healthy
+Currently there is no way to tell whether an Alertmanager instance is healthy
 under the above conditions. There are discussions of using vector clocks to
 resolve merges in the above mentioned situation, and ensure on a best effort
 basis that joining the network was successful.
 
-> Note that single instance Alertmanger setups will therefore not have zero
+> Note that single instance Alertmanager setups will therefore not have zero
 > downtime on deployments.
 
 The current implementation of rolling deployments simply decides based on the

Documentation/exposing-metrics.md

@@ -3,7 +3,7 @@
 There are a number of
 [applications](https://prometheus.io/docs/instrumenting/exporters/#directly-instrumented-software)
 that are natively instrumented with Prometheus metrics, those applications
-simply expose the metrics through an http server.
+simply expose the metrics through an HTTP server.
 
 The Prometheus developers and the community are maintaining [client
 libraries](https://prometheus.io/docs/instrumenting/clientlibs/#client-libraries)
@@ -19,19 +19,19 @@ called
 Exporters can generally be divided into two categories:
 
 * Instance exporters: These expose metrics about a single instance of an
-  application. For example the http requests that a single http server has
+  application. For example the HTTP requests that a single HTTP server has
 exporters served. These exporters are deployed as a
 [side-car](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)
 container in the same pod as the actual instance of the respective application.
 A real life example is the [`dnsmasq` metrics
 sidecar](https://github.com/kubernetes/dns/blob/master/docs/sidecar/README.md),
-which converts the propriatary metrics format communicated over the DNS
+which converts the proprietary metrics format communicated over the DNS
 protocol by dnsmasq to the Prometheus exposition format and exposes it on an
-http server.
+HTTP server.
 
 * Cluster-state exporters: These expose metrics about an entire system, they
   could be native to the environment the application constructs. For example
-these could be the number 3D objects in a game, or metrics about a kubernetes
+these could be the number 3D objects in a game, or metrics about a Kubernetes
 deployment. These exporters are typically deployed as a normal Kubernetes
 deployment, but can vary depending on the nature of the particular exporter. A
 real life example of this is the

Documentation/prometheus.md

@@ -111,6 +111,7 @@ it brought up as data sources in potential Grafana deployments.
 Prometheus instances are deployed with default values for requested and maximum
 resource usage of CPU and memory. This will be made configurable in the `Prometheus` 
 TPR eventually.
+
 Prometheus comes with a variety of configuration flags for its storage engine that
 have to be tuned for better performance in large Prometheus servers. It will be the
 operators job to tune those correctly to be aligned with the experiences load

Documentation/service-monitor.md

@@ -25,7 +25,7 @@ discovers those `Endpoints` objects and configures Prometheus to monitor those
 
 The `endpoints` section of the `ServiceMonitorSpec`, is used to configure which
 ports of these `Endpoints` are going to be scraped for metrics, and with which
-paramters. For advanced use cases one may want to monitor ports of backing
+parameters. For advanced use cases one may want to monitor ports of backing
 `Pod`s, which are not directly part of the service endpoints. Therefore when
 specifying an endpoint in the `endpoints` section, they are strictly used.