Documentation.

CHANGELOG.md

@@ -5,7 +5,7 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [0.1.0] - 2020-12-2x
+## [0.1.0] - 2020-12-23
 
 Initial release.
 

docs/CONFIGURE.md

@@ -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
+```

docs/INDEX.md

@@ -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)

docs/INSTALL.md

@@ -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.

metricator.example.yaml

@@ -7,7 +7,7 @@ applications:
     # Headers to append to request.
     headers:
       X-API-KEY: th4apik3yh4rdt0gu3ss
-    # Timeout between requests. Not neccessarily be exact and requests might
+    # Timeout between requests. Not necessarily be exact and requests might
     # be sent in 60 or more seconds (in this example).
     time_between_requests: 60s