Prometheus Operator配置外部exporter
最近在做一个服务器能耗监测相关的工具，因为涉及到微服务，最终选定了Kubernetes作为平台。既然涉及到性能监控，一番搜索后，自然离不开该领域的“明星”Prometheus。
Prometheus是一个非常通用的性能数据收集工具。有多通用呢？通用到它几乎无法直接从任何性能数据源获取任何数据，必须通过类似驱动的中间件（官方称呼为exporter，译为导出器）对数据进行文本化的格式化处理，才能被Prometheus解析并记录下来。这一方面意味着Prometheus本身“一无是处”，而又意味着开发团队可以不用顾及任何数据源的兼容性，可以专心开发与监控相关的核心功能。
那么问题就来了：Prometheus是作为一个单体应用而设计的，接入方式可以说是“四通八达”，而性能数据收集往往涉及系统底层访问，时常需要提权操作；而Kubernetes可以说是一个半封闭式的系统，通过隔离性削减了很大一部分的特权级别的功能。好在Docker和Kubernetes做出了妥协，我们还是有机会通过参数强制开放危险权限以达成目的的。
CoreOS作为云计算领域的明星角色，在相当广泛的领域提供了大量开源组件的实现，比如CoreOS本体，Kubernetes网络层插件Flannel（据说是最好配置的CNI，但我就从来没安装成功过），等等。这次的主角Prometheus Operator也是源自CoreOS项目组。
默认情况下Service基于selector自动创建Endpoints，但是由于ipmi_exporter暂时没办法部署在容器里，所以用Service+Pod的方法行不通。Prometheus Operator只能用Service里定义的端口进行数据监控，所以改端口没什么用，必须创建包含目标端口的服务。思路是，先手动创建Endpoints，再基于Endpoints创建Service，这样Service就可以用现有的Endpoints提供服务。
Probe和Monitor好像不是同一种用法，所以就没用了。
Service要与Endpoints重名，这样才能让Endpoints覆盖Service以提供服务Service不能写selector，不然会覆盖Endpoints- 在一个
Endpoints里写多个address即可 serviceMonitor的selector要与Service的label相对应
参考：
https://devops.college/prometheus-operator-how-to-monitor-an-external-service-3cb6ac8d5acb
https://www.jianshu.com/p/005112fd2f0a