Dieser Beitrag ist im Februar 2017 erschienen
Nach etwas Warten kann man jetzt den neuen, mandantenfähigen, Container Monitoring-Dienst in Triton ausprobieren. Die Architektur ist an Triton angepasst.
Auf jedem Compute-Node läuft der cmon-agent, welcher die Anfragen des cmon-proxies beantwortet, welche dieser von Kundensystemen annimmt und an die Agents weiterleitet. Beispielhaft als Kundensystem kann z. B. eine Prometheus-Instanz verwendet werden. Kunden könnten aber auch jedes andere System verwenden, welches das entsprechende Protokoll verwenden kann.
Der Proxy übernimmt dabei auch die Authentisierung des Benutzers. Ein "discover"-Request zeigt nur die VMs und Container des Users, der sich mit seinem Zertifikat identifiziert hat:
root@018d7ba0-cf68-65f7-8f6d-f3cd1c07ec31:~# curl --insecure --cert-type pem --cert .triton/docker/hbloed\@cloudapi_de-gt-1_cns_tgos_de/cert.pem --key .triton/docker/hbloed\@cloudapi_de-gt-1_cns_tgos_de/key.pem "https://cmon.de-gt-1.tgos.de:9163/v1/discover" | json |less
{
"containers": [
{
"server_uuid": "c77bb4ab-edbf-11e1-8ca2-07d38ce1fc4e",
"source": "Bootstrapper",
"vm_alias": "ubuntu-dev",
"vm_owner_uuid": "f5d89e91-c2e2-e641-e780-b78365fc4843",
"vm_uuid": "ec057038-51aa-ed39-ffc9-dd88a5a20198",
"cached_date": 1486888939965
},
{
"server_uuid": "ce9cb495-0a25-11e2-bc01-f80f41f39e9a",
"source": "Bootstrapper",
"vm_alias": "pmm-data",
"vm_image_uuid": "79e66839-0d38-1ed2-9399-18af1ec89b95",
"vm_owner_uuid": "f5d89e91-c2e2-e641-e780-b78365fc4843",
"vm_uuid": "e66cb4c8-d980-4b5a-8e81-6a3b9b256bff",
"cached_date": 1486889098382
},
{
"server_uuid": "a0cf8f41-0731-11e2-afa6-f80f41f39c36",
"source": "Bootstrapper",
"vm_alias": "dcos-bootstrap",
"vm_owner_uuid": "f5d89e91-c2e2-e641-e780-b78365fc4843",
"vm_uuid": "c7f7883e-3ce6-41be-b4be-23d6d4e010c5",
"cached_date": 1486889144168
},
{
"server_uuid": "ce9cb495-0a25-11e2-bc01-f80f41f39e9a",
"source": "Bootstrapper",
"vm_alias": "registry-data",
"vm_image_uuid": "9e80b657-6fff-7764-e69e-c3586764ca55",
"vm_owner_uuid": "f5d89e91-c2e2-e641-e780-b78365fc4843",
"vm_uuid": "bed354fb-cef9-6a97-98f9-a52130aa247e",
"cached_date": 1486889144832
},
[...]
Ein "metrics"-Request für die Metriken der "ubuntu-dev" VM (ec057038-51aa-ed39-ffc9-dd88a5a20198) liefert dann folgende Informationen:
[root@headnode (de-gt-1) ~]# curl --insecure --cert-type pem --cert /root/tmp/cert.pem --key /root/tmp/key.pem http://10.64.244.47:9163/v1/ec057038-51aa-ed39-ffc9-dd88a5a20198/metrics
# HELP net_agg_packets_in Aggregate inbound packets
# TYPE net_agg_packets_in counter
net_agg_packets_in 121472002
# HELP net_agg_packets_out Aggregate outbound packets
# TYPE net_agg_packets_out counter
net_agg_packets_out 1147142
# HELP net_agg_bytes_in Aggregate inbound bytes
# TYPE net_agg_bytes_in counter
net_agg_bytes_in 9197688997
# HELP net_agg_bytes_out Aggregate outbound bytes
# TYPE net_agg_bytes_out counter
net_agg_bytes_out 292011105
# HELP mem_agg_usage Aggregate memory usage in bytes
# TYPE mem_agg_usage gauge
mem_agg_usage 2297913344
# HELP mem_limit Memory limit in bytes
# TYPE mem_limit gauge
mem_limit 2415919104
# HELP mem_swap Swap in bytes
# TYPE mem_swap gauge
mem_swap 2303287296
# HELP mem_swap_limit Swap limit in bytes
# TYPE mem_swap_limit gauge
mem_swap_limit 8589934592
# HELP cpu_user_usage User CPU utilization in nanoseconds
# TYPE cpu_user_usage counter
cpu_user_usage 87523304936351
# HELP cpu_sys_usage System CPU usage in nanoseconds
# TYPE cpu_sys_usage counter
cpu_sys_usage 68369105549045
# HELP cpu_wait_time CPU wait time in nanoseconds
# TYPE cpu_wait_time counter
cpu_wait_time 23197821627699
# HELP load_average Load average
# TYPE load_average gauge
load_average 0.01953125
# HELP zfs_used zfs space used in bytes
# TYPE zfs_used gauge
zfs_used 151552
# HELP zfs_available zfs space available in bytes
# TYPE zfs_available gauge
zfs_available 10737266688
# HELP time_of_day System time in seconds since epoch
# TYPE time_of_day counter
time_of_day 1487106517427
Die Prometheus-Konfiguration kann dann z. B. so aussehen:
root@018d7ba0-cf68-65f7-8f6d-f3cd1c07ec31:~/work/src/github.com/prometheus/prometheus# cat triton.yml
global:
scrape_interval: 10s
evaluation_interval: 8s
# scrape_timeout is set to the global default 10s
scrape_configs:
- job_name: triton-lab
scheme: https
tls_config:
cert_file: /root/.triton/docker/hbloed@cloudapi_de-gt-1_cns_tgos_de/cert.pem
key_file: /root/.triton/docker/hbloed@cloudapi_de-gt-1_cns_tgos_de/key.pem
insecure_skip_verify: true
triton_sd_configs:
- account: 'hbloed'
cert: '/root/.triton/docker/hbloed@cloudapi_de-gt-1_cns_tgos_de/cert.pem'
dns_suffix: 'cmon.de-gt-1.cns.tgos.de'
endpoint: 'cmon.de-gt-1.cns.tgos.de'
insecure_skip_verify: true
key: '/root/.triton/docker/hbloed@cloudapi_de-gt-1_cns_tgos_de/key.pem'
version: 1
Und damit gibt es dann natürlich auch bunte Bilder.
So funktioniert mandantenfähiges Container Monitoring mit Triton. Die Metriken werden nicht "auf Vorrat" in irgendwelchen Datenbanken gesammelt sondern Kunden wird ein Endpunkt zur Verfügung gestellt, von dem er Daten über seine provisionierten Ressourcen pollen und dann nach seinem Gusto verarbeiten kann (z. B. in einer eigenen Prometheus-Instanz).
Links:
Die Beschreibung für die Prometheus-Installation und Konfiguration findet sich unter https://github.com/joyent/triton-mon/blob/master/docs/INSTALLING.md
Richard Kiene und Tim Gross hatten das Projekt auf der PromCon 2016 in Berlin vorgestellt. Nur, falls die Seite mal verschwindet: Video und Folien:
Um Dashboards zu bauen, wird Grafana empfohlen. Aber nicht nur, um in Grafana sinnvolle Dashboards konfigurieren zu können (sondern auch um in Prometheus die Containernamen und nicht die Container-UUIDs zu sehen) ist es sinnvoll, sich mit den relabel-Regeln von Prometheus zu beschäftigen. Dieses Beispiel hilft dabei.
Damit tauchen die Container jetzt schon in der Target-Übersicht von Prometheus mit "lesbarem" Namen auf. In Grafana, kann man jetzt im Legend-Format {{ instance }} wählen. Damit werden dann auch dort die Containernamen aufgeführt.