RepoMirrors
/
prometheus
mirror of https://github.com/prometheus/prometheus
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

A few spelling corrections. (#2960)

This commit is contained in:
J. Taylor O'Connor 2017-07-17 16:13:50 -05:00 committed by Brian Brazil
parent 2a9ca394dd
commit 5a19ffb315
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
discovery/README.md
View File

@ -13,7 +13,7 @@ what makes a good SD and covers some of the common implementation issues.
The first question to be asked is does it make sense to add this particular
SD? An SD mechanism should be reasonably well established, and at a minimum in
use across multiple orgnaisations. It should allow discovering of machines
use across multiple organisations. It should allow discovering of machines
and/or services running somewhere. When exactly an SD is popular enough to
justify being added to Prometheus natively is an open question.
@ -29,7 +29,7 @@ discovery. In that case the SD you should be looking at is whatever decides
that a machine is going to be a Kafka server, likely a machine database or
configuration management system.
If something is particlarly custom or unusual, `file_sd` is the generic
If something is particularly custom or unusual, `file_sd` is the generic
mechanism provided for users to hook in. Generally with Prometheus we offer a
single generic mechanism for things with infinite variations, rather than
trying to support everything natively (see also, alertmanager webhook, remote
@ -39,7 +39,7 @@ instead.
For configuration management systems like Chef, while they do have a
database/API that'd in principle make sense to talk to for service discovery,
the idomatic approach is to use Chef's templating facilities to write out a
the idiomatic approach is to use Chef's templating facilities to write out a
file for use with `file_sd`.
@ -74,7 +74,7 @@ may only contain `[_a-zA-Z0-9]`, sanitize by replacing with underscores as neede
For targets with multiple potential ports, you can a) expose them as a list, b)
if they're named expose them as a map or c) expose them each as their own
target. Kuberenetes SD takes the target per port approach. a) and b) can be
target. Kubernetes SD takes the target per port approach. a) and b) can be
combined.
For machine-like SDs (OpenStack, EC2, Kubernetes to some extent) there may
@ -99,9 +99,9 @@ whatever functionality the SD itself offers.
It is a general rule with Prometheus that all configuration comes from the
configuration file. While the libraries you use to talk to the SD may also
offer other mechanisms for providing configuration/authentication under the
covers (EC2's use of enviroment variables being a prime example), using your SD
covers (EC2's use of environment variables being a prime example), using your SD
mechanism should not require this. Put another way, your SD implementation
should not read enviroment variables or files to obtain configuration.
should not read environment variables or files to obtain configuration.
Some SD mechanisms have rate limits that make them challenging to use. As an
example we have unfortunately had to reject Amazon ECS service discovery due to