(MySQL) Performance Monitoring mit Prometheus [UPDATE]

| Keine Kommentare | Keine TrackBacks

In meinem letztem Projekt habe ich mal wieder nach einem (Performance)Monitoring Tool gesucht und mit Prometheus sogar fündig geworden. Prometheus kann weit mehr als eine MySQL Instanz ‘monitoren’. Dabei ist die Grundidee von Prometheus Metriken einzusammeln.

Hier ein einfaches Beispiel einer Konfiguration von Prometheus:

global: 
  scrape_interval: 1m
  scrape_timeout: 10s
  evaluation_interval: 1m

scrape_configs:
  - job_name: mysql
    scheme: http
    target_groups:
    - targets: 
        - '10.17.148.31:9104'
      labels:
        zone: mysql

Das ist eigentlich eine langweilige Config. Der Witz von Prometheus ist viele Quellen zu aggregieren und damit auch korrellieren zu können. Sprich viele Jobs und massig Targets. Damit ist Prometheus die zentrale Performancedatenbank, welche die Metriken aller Targets sammelt und speichert.

Bleiben wir bei der einfachen Config von oben. Alle Minute holt sich Prometheus von 172.17.148.31:9104 Metriken (/metrics) und labelt diese mit zone=mysql. Diese Labels können später bei der Abfrage wiederverwendet werden.

Schauen wir uns mal einen Teil der Metriken an:

> curl 10.17.148.31:9104/metrics
...
mysql_global_status_threads_cached 26
mysql_global_status_threads_connected 99
mysql_global_status_threads_created 125
mysql_global_status_threads_running 2
...

Damit hat jeder MySQL Admin was anzufangen. Hinter der Adresse lauscht ein Exporter. Wie soll es anders sein hier als Docker Container. FYI: Nicht so in Produktion machen!

> docker run -d -p 9104:9104 --link=mysql:backend \
  -e DATA_SOURCE_NAME=prometheus:prometheus@secret(backend:3306)/ \
  prom/mysqld-exporter

Das ist etwas old school Docker. Offensichtlich läuft auch die Datenbank in einem Container (mysql) und wir verwenden hier noch das deprecatete --link :)

mysqld-exporter kennt noch weitere Optionen:

$ docker run --rm prom/mysqld-exporter --help
Usage of /bin/mysqld_exporter:
  -collect.auto_increment.columns
      Collect auto_increment columns and max values from information_schema
  -collect.binlog_size
      Collect the current size of all registered binlog files
  -collect.global_status
      Collect from SHOW GLOBAL STATUS (default true)
  -collect.global_variables
      Collect from SHOW GLOBAL VARIABLES (default true)
  -collect.info_schema.processlist
      Collect current thread state counts from the information_schema.processlist
  -collect.info_schema.tables
      Collect metrics from information_schema.tables (default true)
  -collect.info_schema.tables.databases string
      The list of databases to collect table stats for, or '*' for all (default "*")
  -collect.info_schema.tablestats
      If running with userstat=1, set to true to collect table statistics
  -collect.info_schema.userstats
      If running with userstat=1, set to true to collect user statistics
  -collect.perf_schema.eventsstatements
      Collect metrics from performance_schema.events_statements_summary_by_digest
  -collect.perf_schema.eventsstatements.digest_text_limit int
      Maximum length of the normalized statement text (default 120)
  -collect.perf_schema.eventsstatements.limit int
      Limit the number of events statements digests by response time (default 250)
  -collect.perf_schema.eventsstatements.timelimit int
      Limit how old the 'last_seen' events statements can be, in seconds (default 86400)
  -collect.perf_schema.eventswaits
      Collect metrics from performance_schema.events_waits_summary_global_by_event_name
  -collect.perf_schema.file_events
      Collect metrics from performance_schema.file_summary_by_event_name
  -collect.perf_schema.indexiowaits
      Collect metrics from performance_schema.table_io_waits_summary_by_index_usage
  -collect.perf_schema.tableiowaits
      Collect metrics from performance_schema.table_io_waits_summary_by_table
  -collect.perf_schema.tablelocks
      Collect metrics from performance_schema.table_lock_waits_summary_by_table
  -collect.slave_status
      Collect from SHOW SLAVE STATUS (default true)
  -config.my-cnf string
      Path to .my.cnf file to read MySQL credentials from. (default "/home/golang/.my.cnf")
  -log.level value
      Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal, panic]. (default info)
  -log_slow_filter
      Add a log_slow_filter to avoid exessive MySQL slow logging.  NOTE: Not supported by Oracle MySQL.
  -web.listen-address string
      Address to listen on for web interface and telemetry. (default ":9104")
  -web.telemetry-path string
      Path under which to expose metrics. (default "/metrics")

Prometheus aggregiert die Daten. Im eigenem Expression Browser kann auf die Daten zugegriffen werden. Prometheus bringt eine nette Query Language mit, die einem erlauben alle bekannten Abfragen nachzubilden. Einfachste Abfragen wären (selbsterklärend):

mysql_global_status_created_tmp_disk_tables

increase(mysql_global_status_created_tmp_disk_tables[2m])/120

[UPDATE]

Brian Brazil hat einen besseren Vorschlag:

rate(mysql_global_status_created_tmp_disk_tables[2m])

(Einen Überblick über die (Funktionen)[https://prometheus.io/docs/querying/functions/] gibt es auch)

Als Dashboard ist Grafana zu empfehlen. Zwar bietet Prometheus mit PomDash was eigenes an, Aber imho gehört die Zukunft Grafana.

Daneben bietet Prometheus (nicht Gegenstand des Artikels) auch ein (experimentelles) Alerting.

Nicht alles

Prometheus erlaubt den Zugriff auf historische Daten, die eben noch im nachhinein nach Bedarf korreliert werden können. Nutzer von PNP4Nagios verstehen meine Freude :) Eine weitere Stärke von Prometheus ist es nicht nur einen Exporter abzufragen. Die Stärke von Prometheus ist es die Metriken der Exporter aller Nodes des RZs abzufragen \o/

Fazit

An Prometheus gefällt mir die einfache Zusammenführung von Daten. So ist es - bei entsprechenden Exportern - z.B. Netzlatenz, CPU Auslastung und Datenbankperformance über das ganze RZ an einem Punkt zu vergleichen. Und das auch im Nachhinein. Oft fällt mir im Nachhinein ein, was ich gerne korreliren würde und genau das ermöglicht Prometheus.

Es ist sehr leicht eigene Exporter zu schreiben. Nervig ist das jeder Exporter einen eigenen Port braucht :(

Viel Spaß

Erkan

[Update]

Eine nette Präsentation gab es beim MariaDB Berlin Meetup. Besonders die Grafana Bilder sind ans Herz zu legen.

[Update2]

Percona hat ja immer einen guten Riecher für ‘Hot Stuff’. So überrascht es nicht, dass die heute ihr Percona Monitoring and Management (mit Prometheus) vorgestellt haben.

Keine TrackBacks

TrackBack-URL: http://linsenraum.de/mt/mt-tb.cgi/391

Jetzt kommentieren