Documentation.

This commit is contained in:
2020-12-23 21:13:56 +05:00
parent 115e5d5051
commit fd8e5b9e1f
5 changed files with 83 additions and 2 deletions

21
docs/CONFIGURE.md Normal file
View File

@@ -0,0 +1,21 @@
# Configuration
This page describes every configuration value.
## The Table
| Variable | Type | Description |
| -------- | ---- | ----------- |
| applications > APPNAME > endpoint | string | Prometheus metrics endpoint URL. |
| applications > APPNAME > headers > MAP | map | Headers which should be added to request. See example below. |
| applications > APPNAME > time_between_requests | string | time.Duration-compatible string which represents timeout between requests. |
## Headers map example
```
applications:
example:
headers:
HeaderOne: valueOne
HeaderTwo: valueTwo
```

View File

@@ -10,4 +10,22 @@ Why proxy? Let's go by example.
Imagine that software you wish to monitor with classic NMS exposes 250 metric items and you wrote a simple script which returns needed data. Classic NMSes is able to process only one value per checker (usually), which means that processing every metric will do 250 HTTP requests to monitored software which is obviously not good.
Of course you can write own script that will request once and another script that will parse saved data, but how would you deal with parametrized metrics (like `dnsdist_frontend_responses{frontend="127.0.0.1:53",proto="UDP",thread="0"}`)? This will definetely took a lot of brain cells and time.
Metricator instead acts like Prometheus itself from monitored software PoV: it performs one HTTP request each timeout (configured in config), parses data and making it available to other requesters. As parsed metric data stored in memory it will be blazing fast and won't overload your system.
Also Metricator "reformats" metric names and parameters to be more easily parsed if needed, so:
```
dnsdist_frontend_responses{frontend="127.0.0.1:53",proto="UDP",thread="0"}
```
became:
```
dnsdist_frontend_responses/frontend:127.0.0.1:53/proto:UDP/thread:0
```
## Docs
* [Installation](INSTALL.md)

42
docs/INSTALL.md Normal file
View File

@@ -0,0 +1,42 @@
# Installing Metricator
There are three ways to install metricator:
1. Using Docker image.
2. Using pre-built binaries.
3. From source
This page describes all of them.
## Docker
To run Metricator in Docker simply run:
```
docker run -v $(pwd)/metricator.yaml:/config.yaml -p 8080:34421 registry.gitlab.pztrn.name/pztrn/metricator:latest
```
Don't forget to create configuration file as described [here](CONFIGURE.md)!
### docker-compose
```
version: "2.4"
services:
metricator:
image: registry.gitlab.pztrn.name/pztrn/metricator:latest
restart: always
ports:
- 8080:34421
volumes:
- /full/path/to/metricator.yaml:/config.yaml
```
## Pre-built binaries
To be written. Stay tuned.
## From source
To be written. Stay tuned.