mysqld_exporter的源码分析和定制化（单个mysqld_exporter监控多个数据库实例）

mysqld_exporter是prometheus官方提供的用于监控mysql运行状态的exporter。其相关信息可以参考：https://github.com/prometheus/mysqld_exporter。

1. 配置

先看一下其配置方式。主要的配置内容分为两部分，一部分是监控目标mysql的连接信息，另一部分是exporter抓取的监控参数的设置。

首先是连接信息：

连接信息的设置方法有两种。第一种是通过环境变量设置，例如：

export DATA_SOURCE_NAME='user:password@(hostname:3306)/'
./mysqld_exporter <flags>

另一种方法是通过配置文件进行设置。配置文件会在func parseMycnf()函数中被转化为与环境变量设置的格式相同。随后该设置将传入golang的db库并进行数据库连接。

对于两种设置的优先级，当环境变量存在（长度大于0）时，将不会对配置文件进行解析。

然后是exporter抓取的监控参数的设置：

这里用集合来表示监控参数的范围。首先exporter中利用scrapers常量记录了一个默认的采集范围集合A。

exporter也允许在exporter启动的时候，通过设置启动参数来设置采集范围B。

当集合B不存在时，集合A生效；当集合B存在时，集合B生效，集合A失效。

Prometheus在采集exporter的数据时，可以携带一个collect[]参数设定采集范围C。

当集合C不存在时，Prometheus最终的采集范围是A或者B（取决于哪个集合生效）；当集合C存在时，Prometheus最终的采集范围时C和A或者B（取决于哪个集合生效）的交集。

2. 工作模式

exporter收集监控数据主要是由Collector实现的。

首先是路由的注册。注意mysqld_exporter.go的277和278行：

    handlerFunc := newHandler(collector.NewMetrics(), enabledScrapers)
    http.Handle(*metricPath, promhttp.InstrumentMetricHandler(prometheus.DefaultRegisterer, handlerFunc))

可以看出主要的处理函数在newHandler()，回到162行函数本体。164行是默认的scraper，165行是获取prometheus带的collect[]参数。在196-208行，对collect[]进行了处理，并与scraper求了交集。

在210-211行注册了prometheus的collector，collector的处理入口在/collector/exporter.go的85行New()函数。函数New()返回了一个叫Exporter的结构体。该结构体实现了Prometheus采集的interface，因此在117行的其成员函数Collect()就是采集数据的位置。

Collect()函数调用了126行的scrape()函数。scrape()函数做了一些数据库初始化的操作后，在160行遍历了所有scraper，并go func调用所有scraper的Scrape()函数，实现对目标数据的采集。

综上，对于mysqld_exporter，只有Prometheus在访问其数据接口时，exporter才对数据库进行连接并采集数据。对于多个scraper，exporter采取多个协程实现数据的并发采集。（具体的并发能力还要看mysql中为exporter提供的账号的并发连接数）

3. 定制化

对于单个mysqld_exporter，其内存占用多在几十M左右。而在实际的应用中，单个exporter实例只能监控单个mysql数据库是该exporter的一个痛点。

而第2节中介绍的数据采集的特性，其数据接口在未被访问时几乎没有其他动作，因此从性能开销上来讲，利用单个exporter监控多个数据库并不会存在太大问题。

（当然一个显然的问题是，多个数据库的请求是串行还是并行？如果选择并行，对每个数据库的每个scraper使用单独的协程，在协程数量过多的时候对性能会不会产生影响。这是需要深入讨论的问题。但是接下来的内容避开了这个问题。）

如何使exporter可以监控多个数据库实例？一个直接的思路是，在Prometheus访问数据接口时，多传入一个instance参数，该参数为监控目标数据库的地址和端口，例如“localhost:3306”。

那么，当我们处理Prometheus的访问（即前文提到的newHandler）时，如果解析到了instance参数，就将该instance信息替换掉配置中的数据库连接信息，这样就实现了利用Prometheus的配置参数选择监控的数据库实例。

通常，Prometheus的配置文件应该类似：

scrape_configs:

  - job_name: 'prometheus'

    static_configs:
      - targets: ['localhost:9090']

      - params
        "collect[]":
          - ***

但是这样每次访问接口只能获取某个数据库实例的监控数据。这些数据如何整合到一起？

这时候Prometheus配置中的relabel config就登场了。（这里，具体的说明文档请参考https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config）

这里我们解释一下relabel和metrics relabel的区别。relabel是在Prometheus访问数据接口前生效的，metrics relabel是在接收到数据之后生效的。

relabel config中提供了以下两个label：

第一个是__address__。通常，我们在配置Prometheus的监控对象时，监控的目标时target。在relabel阶段，target会自动传给__address__，并作为relabel之后Prometheus访问数据接口的地址。

因此，在relabel阶段，我们可以直接将__address__这个label进行replace，这样就可以重新制定Prometheus访问的数据接口的地址。

第二个是__param_<name>。即，我们可以在relabel阶段，通过对这个label进行处理，实现在访问数据接口时携带指定的参数和内容。

举例如下：

scrape_configs:

  - job_name: 'prometheus'

    static_configs:
      - targets:
        - localhost:3306
        - localhost:3308

      - params
        "collect[]":
          - ***

    relabel_config
      - source_labels: ['targets']
        target_label: __address__
      - source_labels: ['__address__']
        target_label: __param_instance
      - source_labels: ['__address__']
        replacement: localhost:9104

假设我们在本地3306和3308两个端口起了两个mysql，然后再9104起了定制化的exporter。

先看relabel，我们把targets放入__address__，然后将__address__放入__param_instance，这样原来的target就作为访问数据接口的参数instance。而访问接口的地址被replace成localhost:9104。

这样就通过在exporter的数据接口增加参数，结合Prometheus配置中的relabel，实现了利用单个mysqld_exporter对多个数据库实例进行监控。

如果需要更深的定制化，比如通过sql语句指定采集的数据等，用mysqld_exporter就不合适了。为了实现这个功能，需要实现一个独立的Colletor，这样开发成本较高。

对于自定义sql语句这个需求，可以使用sql_exporter实现。详情可以参考https://github.com/free/sql_exporter。