README.md 14.7 KB
Newer Older
Karim El Aammari's avatar
Karim El Aammari committed
1
# vagrant-prometheus
k.elaammari's avatar
k.elaammari committed
2
3

## Einleitung
Karim El Aammari's avatar
Karim El Aammari committed
4

k.elaammari's avatar
readme    
k.elaammari committed
5
Mithilfe dieses Workflows können Sie mit Vagrant eine vollständige Monitoring-Infrastruktur aus den folgenden Komponenten erstellen. Jede der Komponenten wird auf einer eigenen virtuellen Maschine durch ein idempotentes Skript installiert. 
k.elaammari's avatar
k.elaammari committed
6
7
8
9
10

* Grafana (Visualisierung, Graphen, Dashboards)
* Prometheus (Node-Metriken abgreifen und an DB weiterleiten)
* InfluxDB (Time-Series DB, Langzeitspeicher, Backup/Restore)
* Chronograf (Graphisches Interface zu InfluxDB)
k.elaammari's avatar
readme    
k.elaammari committed
11
* Node-Set (Überwachete Dummy-Maschinen)
k.elaammari's avatar
k.elaammari committed
12

k.elaammari's avatar
readme    
k.elaammari committed
13
Es ist auf jeder dieser virtuellen Maschinen (VMs) der Prometheus-node-exporter für das Bereitstellen der zu erfassenden Metriken installiert.
k.elaammari's avatar
k.elaammari committed
14

k.elaammari's avatar
readme    
k.elaammari committed
15
![Infrastruktur](./docu/inkscape/infrastruktur.png)
k.elaammari's avatar
k.elaammari committed
16
17

## Voraussetzungen
Karim El Aammari's avatar
Karim El Aammari committed
18

k.elaammari's avatar
readme    
k.elaammari committed
19
Um den Workflow ausführen zu können müssen folgenden Programme installiert sein:
Karim El Aammari's avatar
Karim El Aammari committed
20

k.elaammari's avatar
k.elaammari committed
21
* Vagrant (<https://www.vagrantup.com/>)
k.elaammari's avatar
readme    
k.elaammari committed
22
* VirtualBox (<https://www.virtualbox.org/>) oder ein anderer unterstützter Hypervisor
k.elaammari's avatar
k.elaammari committed
23
24
* Git (<https://git-scm.com/>)

k.elaammari's avatar
readme    
k.elaammari committed
25
Im Weiteren wird vorausgesetzt, dass Sie sich auf einem Linux basierten Betriebssystem befinden. Der Workflow funktioniert auch auf Windows-Platformen, hierbei ist aber zu beachten, dass unter Windows standardmäßig Zeilenumbrüche mit CR & LF kodiert werden. Im Gegensatz zum einfachen LF Zeilenumbruch unter Linux. Da die Dateien mit dem File-Provisionierer übertragen werden, muss darauf geachtet werden, dass die Dateien mit einem einfachen LF gespeichert werden. In der Git-Konfiguration sollte demensprechend folgende Funktion abgeschaltet werden. Diese ist normalerweise unter Windows eingeschaltet und fügt beim auschecken ein CR zum LF hinzu.
k.elaammari's avatar
k.elaammari committed
26

Karim El Aammari's avatar
Karim El Aammari committed
27
28
```shell
git config --global core.autocrlf false
k.elaammari's avatar
k.elaammari committed
29
```
k.elaammari's avatar
k.elaammari committed
30
31
32

## Getting started

k.elaammari's avatar
readme    
k.elaammari committed
33
Um direkt zu starten, kopieren Sie mit folgendem Befehl das Projekt auf ihren Rechner und wechseln anschließend in das erstellte Verzeichnis.
k.elaammari's avatar
k.elaammari committed
34
35

```shell
k.elaammari's avatar
readme    
k.elaammari committed
36
git clone git@git.gsi.de:dc/common/vagrant-prometheus.git
k.elaammari's avatar
k.elaammari committed
37
38
```

k.elaammari's avatar
readme    
k.elaammari committed
39
Bevor die VMs gestartet werden sollten, müssen die benötigten TLS-Zertifikate erzeugt werden. Hierfür führen Sie folgenden Befehl aus.
k.elaammari's avatar
k.elaammari committed
40
41
42
43
44

```shell
./scripts/openssl_generate.sh
```

k.elaammari's avatar
readme    
k.elaammari committed
45
Nachdem die Zertifikate erzeugt wurden, können die VMs gestartet werden.
k.elaammari's avatar
k.elaammari committed
46
47

```shell
Karim El Aammari's avatar
Karim El Aammari committed
48
vagrant up
k.elaammari's avatar
k.elaammari committed
49
50
```

Karim El Aammari's avatar
Karim El Aammari committed
51
Anschließen starten nacheinander Influx, Prometheus, Grafana und Chronograf. Die Nodes, dessen Metriken erfasst werden sollen, müssen explizit gestartet werden, entweder einzeln oder als Regex.
k.elaammari's avatar
k.elaammari committed
52
53

```shell
Karim El Aammari's avatar
Karim El Aammari committed
54
vagrant up {node-1 node-2 ... node-10 | /node-.*/}
k.elaammari's avatar
readme    
k.elaammari committed
55
```  
k.elaammari's avatar
k.elaammari committed
56
57
58

## Überwachen der Maschinen

k.elaammari's avatar
readme    
k.elaammari committed
59
Nachdem die Maschinen gestartet sind und die Provisionierung erfolgreich ausgeführt wurde, können wir über die von Vagrant weitergeleiteten Ports direkt auf die Dienste zugreifen.
k.elaammari's avatar
k.elaammari committed
60

Karim El Aammari's avatar
Karim El Aammari committed
61
62
63
* <https://127.0.0.1:3000> (Grafana)
* <https://127.0.0.1:8888> (Chronograf)
* <http://127.0.0.1:9090> (Prometheus)
k.elaammari's avatar
k.elaammari committed
64
65
66

Wenn auf ihrem Betriebssystem diese Ports schon in Verwendung sind, können Sie in der Vagrantfile eine andere Zuordnung konfigurieren.

k.elaammari's avatar
readme    
k.elaammari committed
67
Da die Dienste Grafana und Chronograf ein signiertes TLS-Zertifikat besitzen, können Sie ihrem Browser das unter ```./openssl/data/certificates/cacert.pem``` gespeicherte Root-Zertifikat als Zertifizierungsstelle eintragen, um Warnungen und mögliche Zweifel beim Aufruf der Seiten zu vermeiden. Um beim hinzufügen das Zertifikat zu verifizieren, können Sie mit folgendem Befehl die Fingerprints der erzeugen Zertifikate anzeigen lassen.
k.elaammari's avatar
k.elaammari committed
68
69
70
71
72
73

```shell
./scripts/openssl_fingerprint.sh
```

## Backup- und Restore-Workflow
Karim El Aammari's avatar
Karim El Aammari committed
74

k.elaammari's avatar
k.elaammari committed
75
### Backup
Karim El Aammari's avatar
Karim El Aammari committed
76

k.elaammari's avatar
readme    
k.elaammari committed
77
Die InfluxDB ist durch einen Backup- und Restore-Mechanismus ausgestattet, mit dem wir die gesammelten Daten des Monitoringsystems extern speichern und zurück spielen können. In diesem Workflow wird Standardmäßig um 1 Uhr täglich ein Vollbackup ausgelöst, das separat zu den vorherigen Backups in einem Ordner mit Zeitstempel abgelegt wird. Konfigurieren können Sie den Timer in der Datei: ```./provision/influx/config/backup.timer```. Wichtig zu beachten ist, dass das Backup in einem von VirtualBox geteilten Ordner zwischen VM ```/vagrant/backup``` und Projektverzeichnis ```./backup``` gespeichert wird! Wenn Ihr Hypervisor diese Funktion nicht unterstützt, müssen Sie die Backups von Hand aus der Influx-VM kopieren. Vagrant bietet hier alternativ Rsync oder SMB an.
k.elaammari's avatar
k.elaammari committed
78
79
80
81

Um ein manuelles Backup zu starten, führen Sie folgendes Skript aus.

```shell
Karim El Aammari's avatar
Karim El Aammari committed
82
./scripts/influx_backup.sh %PFAD%
k.elaammari's avatar
k.elaammari committed
83
84
```

k.elaammari's avatar
readme    
k.elaammari committed
85
Mit der %PFAD% Variable geben Sie den Ausgabepfad des Backups an. Dabei beschreibt der Pfad den Speicherort innerhalb der VM.
k.elaammari's avatar
k.elaammari committed
86
87

### Restore
Karim El Aammari's avatar
Karim El Aammari committed
88

k.elaammari's avatar
k.elaammari committed
89
90
91
92
93
94
Um ein Backup in die InfluxDB wieder zurück zuspielen, benutzen Sie folgendes Skript.

```shell
./scripts/influx_restore.sh <PFAD>
```

Karim El Aammari's avatar
Karim El Aammari committed
95
Die %PFAD% Variable ist hierbei der Ordner indem sich die Backupdateien befinden. Sollte in Ihrer Influx-Instanz schon die Datenbank "prom" existieren, werden Sie gefragt ob Sie diese löschen wollen, um die "prom"-Datenbank aus dem Backup laden zu können. Diese Operation ist notwendig, da hier bei jedem Backup die vollständige Datenbank gesichert wird und dementsprechend eine vollständige Datenbank zurück gespielt wird.
k.elaammari's avatar
k.elaammari committed
96

k.elaammari's avatar
readme    
k.elaammari committed
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
## Openssl

Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu können, benötigen wir TLS-Zertifikat die wir mit dem Openssl-Toolkit erzeugen (<https://www.openssl.org/>). Hierfür wird zuerst ein Root-Zertifikat (cacert.pem) erzeugt und anschließend die Zertifikate für die Dienste Grafana, Influx und Chronograf. Diese werden von dem Root-Zertifikat signiert, sodass mit dem Root-Zertifikat die Authentifizierung erfolgen kann. Wichtig ist zu beachten, dass zu jedem Zertifikat auch ein Private-Key existiert, so z.B. cacert.pem und cakey.pem oder influxcert.pem und influxkey.pem.

### Openssl Ordnerstruktur

```shell
./openssl
    ./config
        ./chronograf.cnf
        ./grafana.cnf
        ./influx.cnf
        ./openssl-ca.cnf
    ./data
        ./certificates
        ./csrdb
```

Im Config-Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugung in die Zertifikate eingetragen werden. Das Data-Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.

### Zertifikat-Seriennummer

Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden Standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die anfangs Seriennummer auf einen andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss grade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.

```shell
#./scripts/openssl_generate.sh 01
#./scripts/openssl_generate.sh FF
#./scripts/openssl_generate.sh 0100
#./scripts/openssl_generate.sh FFFF
#./scripts/openssl_generate.sh 010000
#./scripts/openssl_generate.sh 0FFF8729  
#./scripts/openssl_generate.sh 01FA55DEC3
...
```

### Private-Key verloren

Wenn ein Private-Key auf irgendeine Art an Dritte verloren gegangen ist, müssen Sie reagieren. In diesem Fall ist zu unterscheiden, ob es sich um den cakey.pem, also der Root-Key oder den Key eines Dienstes wie grafanakey.pem handelt. Sollten Sie ihren Root-Key verlieren, ist ihre Kommunikation zwischen den Diensten auch für 3.te weiterhin sicher verschlüsselt, aber mit dem Root-Key könnten fremde Zertifikate signiert werden, welche dann von Ihrem installierten Root-Zertifikat als gültig anerkannt werden würden. Im zweiten Fall, wenn Sie den Privat-Key eines Dienstes verloren haben, könnten zwar keine Zertifikate signiert werden, aber mit dem aktuellen Privat-Key, kann sich ein 3.ter als der Dienst ausgeben, für den das Zertifikat ausgestellt wurde. Des Weiteren sind die mit dem Zertifikat aufgebauten verschlüsselten Verbindungen auch nur noch bedingt sicher vor dem Mitlesen Dritter.

* Root-Key verloren, in diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen.   Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.

```shell
./scripts/openssl_generate.sh 
vagrant provision --all
```

* Dienst-Key verloren, bedeutet, dass Sie nur das jeweilige Zertifikat ersetzen müssen.

```shell
./scripts/openssl_node.sh (flux | graf | chron)
vagrant provision (flux | graf | chron)
```

### Eigene Zertifikate

Wenn Sie eigene Zertifikate erzeugen und diese in diesem Workflow benutzen möchten, müssen Sie diese an die entsprechenden Pfade kopieren oder verlinken. Standardmäßig werden die erzeugten Zertifikate aus ```./openssl/data/certificates``` mit dem jeweiligen Provision-Verzeichnis der VMs verlinkt. Sie können an dieselben Stellen ````./provision/*/https``` Ihre Zertifikate kopieren und mit dem Provisionierer diese übertragen lassen. Sollten ihre Zertifikate nicht wie unten benannt werden können, müssen Sie zusätzlich in den Konfigurationen die geänderten Dateinamen eintragen.

```shell
./provision
    ./chronograf
        ./config/chronograf.service # TLS_CERTIFICATE, TLS_PRIVATE_KEY
        ./https
            ./cacert.pem
            ./chronografcert.pem
            ./chronografkey.pem
    ./grafana
        ./config/graf_conf.ini      # Sektion [server]: cert_file, cert_key
        ./https
            ./cacert.pem
            ./grafanacert.pem
            ./grafanakey.pem
    ./influx
        ./config/influxdb.conf      # Sektion [http]: https-certificate, https-private-key
        ./https
            ./cacert.pem
            ./influxcert.pem
            ./influxkey.pem
```

## Authentifizierung

### Grafana

Für Grafana werden zwei Benutzer angelegt, ein Administrator und ein optionaler View-Benutzer mit der Berechtigung Dashboards anzuzeigen. Angelegt werden die Benutzer mit dem ```./provision/grafana/setup_grafana.sh```-Skript. Die Standardpasswörter für die beiden Benutzer können in folgenden JSON-Dateien bearbeiten werden. Nachdem die Benutzer erzeugt wurden, wird zusätzlich ein API-Token erstellt, mit dem anschließend alle Änderungen gemacht werden. Gespeichert wird dieser Token innerhalb der VM im ```/var/lib/grafana/token```-Verzeichnis. Anhand der Existenz dieses Tokens innerhalb der VM entscheidet das Skript, ob Grafana initial konfiguriert werden muss.

```shell
./provision/grafana/config/users
    ./admin_password.json
    ./view_user.json
```

#### Passwörter ändern

Das ändern von Benutzer Passwörter sollten nach Möglichkeit über das Grafna-UI erfolgen, entweder als Admin oder vom Benutzer selbst. Daneben besteht noch die Option die HTTP-API zu benutzen. Hierfür können Sie sich am ```setup_grafana.sh```-Skript von Grafana orientieren und den CURL Befehl entweder mit BasicAuth oder mit dem API-Token bauen.    

#### Admin Passwort zurücksetzen

Sollten kein Zugriff auf den Admin-Benutzer bestehen, kann mit der Grafana-CLI das Passwort zurückgesetzten werden. Hierfür muss lokal auf der VM folgender Befehl ausgeführt werden.

```shell
vagrant ssh graf    # verbinden mit der VM 
sudo grafana-cli --homepath /usr/share/grafana admin reset-admin-password "newpass"
```

### Influx

In der Influx-Datenbank werden drei Benutzer angelegt, ein Administrator und anschließend zwei weitere Benutzer für Grafana und Prometheus. Dabei ist festgelegt, dass der Prometheus Benutzer nur Schreib-Rechte und Grafana nur Lese-Rechte bekommt. Ausgeführt werden die Queries mit dem ```./provision/influx/setup_influx.sh```-Skript indem mit CURL die Queries an die HTTP-API von Influx gesendet werden. Beim ersten Start von Influxdb wird keine Authentifizierung für das erzeugen eines Administrators verlang. Anschließend schaltet sich die Authentifizierung automatisch für die folgende Queries ein. Die Standardpasswörter für die Benutzer sind in folgenden Dateien.

```shell
./provision/influx/
    ./setup_influx.sh       # Admin-Benutzer
    ./config/setup.queries  # Prometheus- und Grafana-Benutzer   
```

#### Passwörter ändern

Passwörter können Sie nur als Admin-Benutzer ändern. Die einfachste Möglichkeit wäre es im UI vom Chronografen in der Sektion 'InfluxDB Admin' diese zu ändern. Die andere Möglichkeit wäre mit dem Influx-CLI Tool sich auf der Influx-Datenbank anzumelden. Da das Tool die HTTP-API benutzt, kann auch von einer anderen VM die Anmeldung erfolgen, da das Tool aber im Moment nur auf der flux-VM liegt, wird hier eine Verbindung auf die flux-VM per SSH aufgebaut.

```shell
vagrant ssh flux
influx -ssl -unsafeSsl 
>auth  
username: 
password:
>SET PASSWORD FOR "name" = 'newpass'
result message...
```

Wenn Sie das Passwort von Prometheus oder Grafana ändern, müssen Sie auch die Konfiguration bzw. die Grafana-Datasource aktualisieren.  

##### Prometheus
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen die Provisionierung neu aus und laden Sie die Konfiguration neu.

```shell
nano ./provision/prometheus/config/prom.yml 

vagrant provision prom  
vagrant ssh prom
sudo curl -X POST http://localhost:9090/-/reload
```

##### Grafana
Um die Influx-Datasource zu aktualisieren, wählen Sie im Grafana-UI > Configuration > Data Source > InfluxDB aus und tragen in der Sektion "InfluxDB Details" die neuen Benutzerdaten ein. Wenn Sie zusätzlich auch das Standartpassword in den Influx-Setupqueries geändert haben, sollten Sie diese Änderung auch in die JSON-Datei der Datasource eintragen, ohne die Provisionierung neu auszuführen.

```shell 
./provision/grafana/config/datasources/ds_influx.json
```

#### Admin Passwort zurücksetzen

Sollte ein 2.ter Admin-Benutzer existieren, kann mit den oben beschriebenen Methoden das Passwort geändert werden. Ist kein weitere Admin-Benutzer verfügbar, muss die Authentifizierung abgeschaltet werden und dann ein neuer Admin erzeugt werden.

```shell 
vagrant ssh flux
# Ändern sie in der Sektion [http], die Variable "auth-enabled" = false
sudo nano /etc/influxdb/influxdb.conf
# influx neustarten
systemctl restart influx
# influx verbinden
influx -ssl -unsafeSsl 
>SET PASSWORD FOR "name" = 'newpass'
>exit
# Ändern sie in der Sektion [http], die Variable "auth-enabled" = true
sudo nano /etc/influxdb/influxdb.conf
# influx neustarten
systemctl restart influx
```