 Zobacz na TensorFlow.org |  Uruchom w Google Colab |  Wyświetl źródło na GitHub |  Pobierz notatnik |
Przegląd
Ten tutorial ładunki CoreDNS metryki ze Prometeusz serwer w tf.data.Dataset , a następnie wykorzystuje tf.keras szkolenia i wnioskowania.
CoreDNS jest serwer DNS z naciskiem na odkryciu usług i jest szeroko stosowane jako część Kubernetes klastra. Z tego powodu często jest ściśle monitorowany przez operacje devops.
Ten samouczek jest przykładem, z którego mogą skorzystać Devops poszukujący automatyzacji w swoich działaniach poprzez uczenie maszynowe.
Konfiguracja i użytkowanie
Zainstaluj wymagany pakiet tensorflow-io i uruchom ponownie środowisko wykonawcze
import os
try:
%tensorflow_version 2.x
except Exception:
pass
TensorFlow 2.x selected.
pip install tensorflow-io
from datetime import datetime
import tensorflow as tf
import tensorflow_io as tfio
Zainstaluj i skonfiguruj CoreDNS i Prometheus
Dla celów demonstracyjnych, serwer CoreDNS lokalnie z portem 9053 otwarty do otrzymania zapytania DNS i port 9153 (defult) otwarte, aby odsłonić metryk do skrobania. Poniżej znajduje się podstawowa konfiguracja Corefile dla CoreDNS i jest dostępny do pobrania :
.:9053 {
prometheus
whoami
}
Więcej szczegółów na temat instalacji można znaleźć na CoreDNS męska dokumentacji .
curl -s -OL https://github.com/coredns/coredns/releases/download/v1.6.7/coredns_1.6.7_linux_amd64.tgztar -xzf coredns_1.6.7_linux_amd64.tgzcurl -s -OL https://raw.githubusercontent.com/tensorflow/io/master/docs/tutorials/prometheus/Corefilecat Corefile
.:9053 {
prometheus
whoami
}
# Run `./coredns` as a background process.
# IPython doesn't recognize `&` in inline bash cells.
get_ipython().system_raw('./coredns &')
Następnym krokiem jest do konfiguracji serwera i używać Prometeusz Prometheus do CoreDNS zeskrobać metryk, które są narażone na porcie 9153 z góry. prometheus.yml plik konfiguracji jest także dostępna dla pobrania :
curl -s -OL https://github.com/prometheus/prometheus/releases/download/v2.15.2/prometheus-2.15.2.linux-amd64.tar.gztar -xzf prometheus-2.15.2.linux-amd64.tar.gz --strip-components=1curl -s -OL https://raw.githubusercontent.com/tensorflow/io/master/docs/tutorials/prometheus/prometheus.ymlcat prometheus.yml
global:
scrape_interval: 1s
evaluation_interval: 1s
alerting:
alertmanagers:
- static_configs:
- targets:
rule_files:
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: "coredns"
static_configs:
- targets: ['localhost:9153']
# Run `./prometheus` as a background process.
# IPython doesn't recognize `&` in inline bash cells.
get_ipython().system_raw('./prometheus &')
Aby pokazać pewną aktywność, dig komenda może być używany do generowania kilka zapytań DNS przez serwer CoreDNS że został zainstalowany:
sudo apt-get install -y -qq dnsutils
dig @127.0.0.1 -p 9053 demo1.example.org
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 9053 demo1.example.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53868 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 855234f1adcb7a28 (echoed) ;; QUESTION SECTION: ;demo1.example.org. IN A ;; ADDITIONAL SECTION: demo1.example.org. 0 IN A 127.0.0.1 _udp.demo1.example.org. 0 IN SRV 0 0 45361 . ;; Query time: 0 msec ;; SERVER: 127.0.0.1#9053(127.0.0.1) ;; WHEN: Tue Mar 03 22:35:20 UTC 2020 ;; MSG SIZE rcvd: 132
dig @127.0.0.1 -p 9053 demo2.example.org
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 -p 9053 demo2.example.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53163 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: f18b2ba23e13446d (echoed) ;; QUESTION SECTION: ;demo2.example.org. IN A ;; ADDITIONAL SECTION: demo2.example.org. 0 IN A 127.0.0.1 _udp.demo2.example.org. 0 IN SRV 0 0 42194 . ;; Query time: 0 msec ;; SERVER: 127.0.0.1#9053(127.0.0.1) ;; WHEN: Tue Mar 03 22:35:21 UTC 2020 ;; MSG SIZE rcvd: 132
Teraz serwer CoreDNS, którego metryki są zbierane przez serwer Prometheus i gotowe do wykorzystania przez TensorFlow.
Utwórz zestaw danych dla metryk CoreDNS i użyj go w TensorFlow
Tworzenie zestawu danych dla CoreDNS metryk, które są dostępne z serwera PostgreSQL, można zrobić z tfio.experimental.IODataset.from_prometheus . Na minimum potrzebne są dwa argumenty. query jest przekazywane do serwera Prometheus wybrać metryki i length jest okresem chcesz załadować do zestawu danych.
Można zacząć od "coredns_dns_request_count_total" i "5" (sekund), aby utworzyć zestaw danych poniżej. Ponieważ wcześniej w samouczku dwóch zapytań DNS zostały wysłane, oczekuje się, że metryki dla "coredns_dns_request_count_total" będzie "2.0" na końcu szeregu czasowego:
dataset = tfio.experimental.IODataset.from_prometheus(
"coredns_dns_request_count_total", 5, endpoint="http://localhost:9090")
print("Dataset Spec:\n{}\n".format(dataset.element_spec))
print("CoreDNS Time Series:")
for (time, value) in dataset:
# time is milli second, convert to data time:
time = datetime.fromtimestamp(time // 1000)
print("{}: {}".format(time, value['coredns']['localhost:9153']['coredns_dns_request_count_total']))
Dataset Spec:
(TensorSpec(shape=(), dtype=tf.int64, name=None), {'coredns': {'localhost:9153': {'coredns_dns_request_count_total': TensorSpec(shape=(), dtype=tf.float64, name=None)} } })
CoreDNS Time Series:
2020-03-03 22:35:17: 2.0
2020-03-03 22:35:18: 2.0
2020-03-03 22:35:19: 2.0
2020-03-03 22:35:20: 2.0
2020-03-03 22:35:21: 2.0
Dalsze spojrzenie na specyfikację zestawu danych:
(
TensorSpec(shape=(), dtype=tf.int64, name=None),
{
'coredns': {
'localhost:9153': {
'coredns_dns_request_count_total': TensorSpec(shape=(), dtype=tf.float64, name=None)
}
}
}
)
Jest oczywiste, że zestaw danych składa się (time, values) krotki gdzie values pola jest dict Python rozszerzył się:
"job_name": {
"instance_name": {
"metric_name": value,
},
}
W powyższym przykładzie, 'coredns' to nazwa zadania, 'localhost:9153' jest nazwą instancji, a 'coredns_dns_request_count_total' to nazwa metryki. Należy pamiętać, że w zależności od użytego zapytania Prometheus, możliwe jest zwrócenie wielu zadań/instancji/metryk. Jest to również powód, dla którego dyktowanie Pythona zostało użyte w strukturze zestawu danych.
Weź kolejne zapytanie "go_memstats_gc_sys_bytes" jako przykład. Ponieważ oba CoreDNS i Prometheus są napisane w Golang, "go_memstats_gc_sys_bytes" metryka jest dostępna zarówno dla "coredns" pracy i "prometheus" pracy:
dataset = tfio.experimental.IODataset.from_prometheus(
"go_memstats_gc_sys_bytes", 5, endpoint="http://localhost:9090")
print("Time Series CoreDNS/Prometheus Comparision:")
for (time, value) in dataset:
# time is milli second, convert to data time:
time = datetime.fromtimestamp(time // 1000)
print("{}: {}/{}".format(
time,
value['coredns']['localhost:9153']['go_memstats_gc_sys_bytes'],
value['prometheus']['localhost:9090']['go_memstats_gc_sys_bytes']))
Time Series CoreDNS/Prometheus Comparision: 2020-03-03 22:35:17: 2385920.0/2775040.0 2020-03-03 22:35:18: 2385920.0/2775040.0 2020-03-03 22:35:19: 2385920.0/2775040.0 2020-03-03 22:35:20: 2385920.0/2775040.0 2020-03-03 22:35:21: 2385920.0/2775040.0
Utworzona Dataset jest gotowy, aby być przekazywane do tf.keras bezpośrednio zarówno dla celów szkoleniowych lub wnioskowania teraz.
Użyj zestawu danych do trenowania modelu
Zbiór danych utworzonych z metryki, to jest możliwe, aby bezpośrednio przejść do zbioru danych do tf.keras dla modelu szkolenia lub wnioskowania.
W celach demonstracyjnych w tym samouczku wykorzystamy bardzo prosty model LSTM z 1 funkcją i 2 krokami jako danymi wejściowymi:
n_steps, n_features = 2, 1
simple_lstm_model = tf.keras.models.Sequential([
tf.keras.layers.LSTM(8, input_shape=(n_steps, n_features)),
tf.keras.layers.Dense(1)
])
simple_lstm_model.compile(optimizer='adam', loss='mae')
Zestaw danych do użycia to wartość „go_memstats_sys_bytes” dla CoreDNS z 10 próbkami. Jednakże, ponieważ przesuwne okno window=n_steps i shift=1 utworzone są potrzebne są dodatkowe próbki (dla dowolnych dwóch elementów consecute pierwsza przyjmuje się jako x i drugi przyjmuje się jako y na treningowej). Suma wynosi 10 + n_steps - 1 + 1 = 12 sek.
Wartość danych jest skalowane do [0, 1] .
n_samples = 10
dataset = tfio.experimental.IODataset.from_prometheus(
"go_memstats_sys_bytes", n_samples + n_steps - 1 + 1, endpoint="http://localhost:9090")
# take go_memstats_gc_sys_bytes from coredns job
dataset = dataset.map(lambda _, v: v['coredns']['localhost:9153']['go_memstats_sys_bytes'])
# find the max value and scale the value to [0, 1]
v_max = dataset.reduce(tf.constant(0.0, tf.float64), tf.math.maximum)
dataset = dataset.map(lambda v: (v / v_max))
# expand the dimension by 1 to fit n_features=1
dataset = dataset.map(lambda v: tf.expand_dims(v, -1))
# take a sliding window
dataset = dataset.window(n_steps, shift=1, drop_remainder=True)
dataset = dataset.flat_map(lambda d: d.batch(n_steps))
# the first value is x and the next value is y, only take 10 samples
x = dataset.take(n_samples)
y = dataset.skip(1).take(n_samples)
dataset = tf.data.Dataset.zip((x, y))
# pass the final dataset to model.fit for training
simple_lstm_model.fit(dataset.batch(1).repeat(10), epochs=5, steps_per_epoch=10)
Train for 10 steps Epoch 1/5 10/10 [==============================] - 2s 150ms/step - loss: 0.8484 Epoch 2/5 10/10 [==============================] - 0s 10ms/step - loss: 0.7808 Epoch 3/5 10/10 [==============================] - 0s 10ms/step - loss: 0.7102 Epoch 4/5 10/10 [==============================] - 0s 11ms/step - loss: 0.6359 Epoch 5/5 10/10 [==============================] - 0s 11ms/step - loss: 0.5572 <tensorflow.python.keras.callbacks.History at 0x7f1758f3da90>
Powyższy wyszkolony model nie jest zbyt przydatny w rzeczywistości, ponieważ serwer CoreDNS skonfigurowany w tym samouczku nie ma żadnego obciążenia. Jest to jednak działający potok, którego można użyć do ładowania metryk z prawdziwych serwerów produkcyjnych. Model można następnie ulepszyć, aby rozwiązać rzeczywisty problem automatyzacji Devops.