重磅！DIY的Prometheus主备方案，全网唯一生产未上

　　写在开篇
　　关于prometheus的高可用方案，经过笔者不断的研究、对比、和搜索，发现不管是官方、还是各大搜索引擎搜索出来的方案，都不符合笔者的需求。因此，笔者自己设计了一套prometheus主备的方案。该方案是一个很low的方案，但经过不断的实践、验证，最后发现还挺实用。关于本方案，笔者以后还会找机会用go或者python开发一个带UI界面的prometheus主备管理器，让它的功能更加完善，做到更自动化和智能化。Prometheus是监控领域的新启之秀，潜力非常大，K8S内置对它直接支持，直接有提供exporter，而K8S又是未来基础架构的主力军。而监控方面，prometheus成为未来的主力军是胜券在握，把它玩透了你绝对不吃亏。好了，前戏有点多了。敬请大家的关注、点赞、转发。下面的正式进入主题！！！DIY的prometheus主备方案架构图
　　方案说明两台主机（master和slave）分别部署keepalived，让master主机接管VIP，注意：keepalived建议配置成非抢占模式之所以采用VIP的原因如下：为了方便日常访问Prometheus页面和Alertmanager页面，在主备切换时，可无需更换访问ip。上层可视化应用（如grafana）通过VIP来对接Prometheus的数据源，当主备切换时，无需在grafana上修改对应的数据源。日常由master主机处于工作状态，在master中，启动Promethues和Alertmanager组件，启动webhook脚本（告警消息推送脚本，用于将告警推送到其他平台）。slave主机备用状态，在slave中，需要启动Promethues组件（用于拉取指标数据），启动Alertmanager组件（用于接收警报消息），这里注意，webhook脚本需处于停止状态（不进行告警推送到其他平台）。这样做是为了规避推送重复告警的问题，虽然Alertmanager有自身的去重告警功能，但这样的设计根本就没有告警重复，已经将重复扼杀在摇篮里了。在接入监控对象时（部署对应的exporter），切记，仅需要在master上做配置即可，slave定期从master拉取配置文件（包括主配置文件、警报规则文件等），定期和master保持配置同步。master和slave的配置保持同步，意味着两边都会拉取被监控对象的监控指标数据。监控指标的拉取、警报的触发两台均一起工作，但告警的推送只有master在负责，slave不负责告警的推送，如果master不可用了，就需要将slave上的webhook脚本手动拉起来，由slave上的webhook脚本接管告警推送的任务。配置文件同步的做法是采用最原始、最简单、最粗暴的办法，master和slave的配置文件同步方案如下：
　　Master主机：master提供配置文件下载服务，由python自带的SimpleHTTPServer模块实现，且需要在prometheus或alertmanager规范安装路径下（如usrlocalprometheus）进行SimpleHTTPServer模块的启动，拉起后，默认的监听端口是8000。master检测配置文件变化情况，如达到条件则触发备份和打包新的配置目录。在master上，设计了一个保存通知动作的文件noticeslave。action，配置发生变化写入1，配置没有发生变化写入0。同时，该检测脚本作为常驻进程在后台运行。
　　Slave主机：slave从master下载通知动作的文件noticeslave。action，根据状态码（1和0）来决定接下来的动作，如果是1，则：从master下载配置压缩包、备份原有配置目录、解压新下载后的配置压缩包、热重启相关组件（prometheus、alertmanger），如果是0则什么都不做。
　　对于配置文件的同步，也是有两种实现方式的，要么是推，要么是拉，笔者的这个方案里是后者，笔者目前之所以折腾零散的shell脚本来去做高可用的管理，是为了能快速解决需求，因此才做了这个简陋的方案，笔者的原则是：困难的事情简单做，简单的事情咱不做（开玩笑哈！！！）。当然，笔者以后会通过Go或者Python打造一个管理Promtheus主备的工具，且是带UI的管理工具，敬请期待推出！我不造车，我只造零件。一、规划和规范1。设备规划（本示例为测试环境）
　　角色
　　物理IP
　　VIP
　　安装组件
　　告警推送方式
　　master
　　192。168。11。146
　　192。168。11。203（当前接管）
　　prometheus、alertmanager（均拉起）
　　webhook方式，脚本拉起
　　slave
　　192。168。11。147
　　prometheus、alertmanager（均拉起）
　　webhook方式，脚本不拉起（备用）2。统一安装路径规范
　　master和slave主机的标准安装路径均为：usrlocal，笔者安装组件后的环境如下：usrlocalkeepalived（注意：建议keepalived配置成非抢占模式）usrlocalprometheususrlocalalertmanager
　　至于安装路径的规范，请自行根据实际情况敲定。3。prometheus组件配置文件和目录规范所有配置文件统一标准路径：usrlocalprometheusconfprometheus主配置文件：usrlocalprometheusconfprometheus。yml按业务粒度，一个业务对应一个目录，业务下不同的监控对象都放在对应的业务目录下：usrlocalprometheusconfbusiness
　　特别说明1：请自行在prometheus组件的安装目录下创建conf目录，并将默认的prometheus。yml配置文件移动进去
　　特别说明2：请自行在prometheus组件的配置文件统一标准路径（。conf）下创建业务目录business
　　特别说明3：业务目录下，又包含两个目录：job和rule，job用于存放监控拉取配置文件，rule用于存放警报规则配置文件
　　配置文件目录和业务目录规划示范，如下：usrlocalprometheus这是规范的安装路径usrlocalprometheusconf这是规范的配置目录usrlocalprometheusconfprometheus。yml这是主配置文件usrlocalprometheusconfbusiness这是按业务粒度规划的业务根目录如下是业务A的规划案例：usrlocalprometheusconfbusinessabusiness这是业务a的目录usrlocalprometheusconfbusinessabusinessjoboracle。yml这是业务a下拉取oracle监控配置数据的yml配置文件usrlocalprometheusconfbusinessabusinessruleoracle。rules这是业务a下oracle的警报规则rules配置文件
　　特别说明：上述对业务A的配置文件规划案例非常重要，请务必参照此规范。4。alertmanager组件配置文件和目录规范
　　关于Alertmanager组件的配置文件，相对来说没prometheus那么复杂，主要的规划还是在prometeus中alertmanager的主配置文件统一标准路径放在prometeheus的conf中：usrlocalprometheusconfalertmanager。yml5。备份路径规范
　　在master主机上，会自动备份原有的conf配置文件目录Prometheus组件
　　统一备份路径为：usrlocalprometheusbackupAlertmanager组件
　　不涉及到备份6。日志目录规范
　　在master主机和slave主机上运行的脚本日志均统一存放在指定目录Prometheus组件
　　统一日志目录：usrlocalprometheuslogsAlertManager组件
　　统一日志目录：usrlocalalertmanagerlogs二、组件安装部署
　　注意：master和slave均需要安装如下组件keepalived高可用组件prometheus监控组件alertmanager警报组件
　　因组件的安装部署不是本文的主题，所以笔者在这里就不再撰写安装步骤，在此省略了哈，请自行安装好即可。三、prometheus配置文件目录同步部署
　　说明1：均需要在master和slave上部署文件同步相关脚本
　　说明2：以下的每一步操作，请均进入到usrlocalprometheus目录下进行操作（此目录是之前已经定为安装规范的目录），如您的规范目录和笔者的不同，请进入到您自己的规范目录下。
　　说明3：以下涉及的脚本，涉及的目录：conf、backup、logs、cfmd5，请自行在规范的目录下进行创建即可。1。master部署配置文件下载服务通过python拉起简单的Http服务，默认监听端口为8000，创建脚本startPromconfSyncApi。sh
　　startPromconfSyncApi。sh脚本内容如下：！binshnohupusrbinpythonmSimpleHTTPServerdevnull
　　运行配置文件下载服务的脚本shstartPromconfSyncApi。sh
　　拉起http服务脚本后查看端口〔rootprosvrmasterprometheus〕netstattulnpgrep8000tcp000。0。0。0：80000。0。0。0：LISTEN1293python〔rootprosvrmasterprometheus〕创建配置文件变化检查脚本startTarPackConf。sh
　　注意，请在规范的安装路径usrlocalprometheus下面创建startTarPackConf。sh脚本，以及创建目录cfmd5
　　startTarPackConf。sh脚本内容：！binshtimelogdateYmdH：M：Secho｛timelog｝配置检查器启动taskwaitsec4find。conftypefprint0xargs0md5sum。cfmd5cfmd5。listwhiletruedotimebakdateYmdHMStimelogdateYmdH：M：Smd5sumc。cfmd5cfmd5。list。cfmd5checkcfmd5。logmd5retcat。cfmd5checkcfmd5。loggrepFAILEDwclwhiletruedoif〔｛md5ret｝gt0〕thenecho｛timelog｝配置文件发生变化，触发备份和打包压缩mv。conf。tar。gz。backupconf。tar。gzbak｛timebak｝tarzcfconf。tar。gzconfecho1。noticeslave。actioncurlXPOSThttp：127。0。0。1：9090reloadbreakelseecho0。noticeslave。actionbreakfidonefind。conftypefprint0xargs0md5sum。cfmd5cfmd5。listsleep｛taskwaitsec｝done
　　脚本实现说明：很简单，就是递归搜索conf目录下的所有配置文件且生成md5值保存在。cfmd5cfmd5。list，并使用md5sumc实时检查。cfmd5cfmd5。list中的文件md5值是否有变化，且将结果输出到。cfmd5checkcfmd5。log，再通过cat。cfmd5checkcfmd5。log进行过滤FAILED并统计，只要出现有FAILED，就认为配置文件有发生过变化，要么是增加了，要么是现有的配置文件做了修改。统计的结果保存在md5ret变量，判断条件就是md5ret结果大于0就触发北方和打包压缩配置目录，同时master中的配置文件发生变化后，也会自动触发热重启。接着将状态码1写入到。noticeslave。action文件中，如果没有变化，将状态码就是0。noticeslave。action文件是存储状态变化的（在这里就干脆叫通知文件吧！）。
　　关于通知文件（noticeslave。action）设计的详细说明：对slave端来讲，由slave主动拉取这个通知文件并读取结果，如果是1就触发拉取master打包好的压缩目录并解压，且继续热重启相应的组件，如果是0就啥也不干。
　　关于参数taskwaitsec4，任务等待时间，master目前配置的是4秒，也就是每隔4秒检测一次。对于slave端，也有一个pullwaitsec2参数（目前是2秒），也就是每隔2秒拉取一次通知文件，并做判断。这里要注意，slave的pullwaitsec拉取时间一定要小于master的taskwaitsec时间，别问为什么，自己思考去。
　　拉起配置文件变化检查脚本拉起nohupsh。startTarPackConf。sh。logstarpack。log
　　查看进程〔rootprosvrmasterprometheus〕psauxgreptarroot24730。00。3113284848pts1S09：480：02shstarttarpackconf。sh
　　拉起后会作为后台进程常驻，需要停止的话，查看pid，然后kill掉即可。创建启动prometheus组件，脚本startPrometheusSvr。sh
　　startPrometheusSvr。sh内容：！binshnohup。prometheusstorage。tsdb。retention。time180dweb。enablelifecycleconfig。file。confprometheus。ymllog。levelwarnlog。formatjson。logsprometheusrunstatus。log
　　数据保留周期是180天，请根据实际情况调整，其他参数的意义请自行help
　　在上面脚本的启动参数中，也可以通过参数storage。tsdb。pathdata修改本地数据存储的路径，不指定的话，时序数据默认是在prometheus的data目录下，如需修改数据的存储路径，建议存放在性能好（SSD、高端磁盘阵列）、容量大的目录中。
　　接着启动prometheus拉起〔rootprosvrmasterprometheus〕shstartPrometheusSvr。sh
　　查看进程，检查是否启动成功〔rootprosvrmasterprometheus〕psauxgrepprometheusroot12010。030。1110062866840pts0Sl08：450：22。prometheusweb。enablelifecycleconfig。file。confprometheus。ymllog。levelwarnlog。formatjson为了方便热重启操作，创建脚本hotrestartprometheus。sh，当修改了配置文件后，就手动执行这个脚本进行热重启！binshcurlXPOSThttp：127。0。0。1：9090reload
　　平滑重启示例〔rootprosvrmasterprometheus〕shhotrestartprometheus。sh
　　在日常维护中，当配置文件发生了变更就可以利用该脚本进行平滑重启创建汇总启动脚本startall。sh！binshsh。startPromconfSyncApi。shnohupsh。startTarPackConf。sh。logstarpack。logsh。startPrometheusSvr。sh
　　以后就不用一个一个脚本拉起了，直接拉起该脚本即可一并启动为了增加安全性，仅允许slave主机访问配置文件拉取服务的端口（笔者这里是8000端口）
　　在tcp协议中禁止所有的ip访问本机的8000端口，仅允许slave主机（192。168。11。147）访问本机的8000端口（注意按顺序执行）iptablesIINPUTptcpdport8000jDROPiptablesIINPUTs192。168。11。147ptcpdport8000jACCEPT
　　查看规则〔rootprosvrmasterprometheus〕iptablesnvLChainINPUT（policyACCEPT9packets，744bytes）pktsbytestargetprotoptinoutsourcedestination8552ACCEPTtcp192。168。11。1470。0。0。00tcpdpt：800000DROPtcp0。0。0。000。0。0。00tcpdpt：8000
　　保存规则
　　注意：使用此命令的规则位置可以是任意的，此方式保存的规则在重启机器后无法自动生效，需要使用命令iptablesrestart恢复），笔者这里是保存在了etcsysconfigmyiptablerulescript保存〔rootprosvrmasterprometheus〕iptablessaveetcsysconfigmyiptablerulescript查看〔rootprosvrmasterprometheus〕catetcsysconfigmyiptablerulescriptGeneratedbyiptablessavev1。4。21onMonMay3010：37：122022filter：INPUTACCEPT〔49：4408〕：FORWARDACCEPT〔0：0〕：OUTPUTACCEPT〔27：4840〕AINPUTs192。168。11。14732ptcpmtcpdport8000jACCEPTAINPUTptcpmtcpdport8000jDROPCOMMITCompletedonMonMay3010：37：122022
　　手动清空规则，模拟规则丢失后，从文件中加载查看〔rootprosvrmasterprometheus〕iptablesnvLChainINPUT（policyACCEPT122packets，12944bytes）pktsbytestargetprotoptinoutsourcedestination00ACCEPTtcp192。168。11。1470。0。0。00tcpdpt：800000DROPtcp0。0。0。000。0。0。00tcpdpt：8000ChainFORWARD（policyACCEPT0packets，0bytes）pktsbytestargetprotoptinoutsourcedestinationChainOUTPUT（policyACCEPT86packets，14400bytes）pktsbytestargetprotoptinoutsourcedestination〔rootprosvrmasterprometheus〕手动清空〔rootprosvrmasterprometheus〕iptablesF清空后查看〔rootprosvrmasterprometheus〕iptablesnvLChainINPUT（policyACCEPT12packets，1056bytes）pktsbytestargetprotoptinoutsourcedestinationChainFORWARD（policyACCEPT0packets，0bytes）pktsbytestargetprotoptinoutsourcedestinationChainOUTPUT（policyACCEPT7packets，1080bytes）pktsbytestargetprotoptinoutsourcedestination〔rootprosvrmasterprometheus〕使用iptablesrestore命令还原iptablessave命令所备份的iptables配置〔rootprosvrmasterprometheus〕iptablesrestoreetcsysconfigmyiptablerulescript还原后查看〔rootprosvrmasterprometheus〕iptablesnvLChainINPUT（policyACCEPT34packets，2992bytes）pktsbytestargetprotoptinoutsourcedestination00ACCEPTtcp192。168。11。1470。0。0。00tcpdpt：800000DROPtcp0。0。0。000。0。0。00tcpdpt：8000ChainFORWARD（policyACCEPT0packets，0bytes）pktsbytestargetprotoptinoutsourcedestinationChainOUTPUT（policyACCEPT18packets，2480bytes）pktsbytestargetprotoptinoutsourcedestination〔rootprosvrmasterprometheus〕
　　特别说明：预防规则重启后丢失的办法还有一种，就是将配置规则写入到启动文件中，如etcrc。local，笔者之前将规则保存在etcsysconfigmyiptablerulescript文件中，那么就可以将恢复的命令iptablesrestoreetcsysconfigmyiptablerulescript写入到etcrc。local中
　　特别注意：如果您的环境和笔者不一样，请自行更改为您自己的IP和端口即可。创建汇总停止脚本stopall。sh！binshpsauxgrepSimpleHTTPServergrepvgrepawk｛print2｝xargskillpsauxgrepstartTarPackConf。shgrepvgrepawk｛print2｝xargskillpsauxgrepvgrepgrepprometheusawk｛print2｝xargskill
　　日常维护中，如有需要停止全部服务的需求，运行该脚本即可。2。slave部署配置文件拉取服务
　　特别说明：在slave主机上，请在规范的目录下创建conf、logs、backup目录将首次安装完成的prometheus。yml文件移动到当前的conf目录下mv。prometheus。yml。conf
　　之所以要移动slave本身的prometheus。yml，是因为要从master同步过来已经规划好的conf配置目录，拉取后会覆盖slave上的conf目录，以后都以master的配置为主准备启动prometheus组件的脚本脚本usrlocalprometheusstartPrometheusSvr。sh，代码：！binshnohup。prometheusstorage。tsdb。retention。time180dweb。enablelifecycleconfig。file。confprometheus。ymllog。levelwarnlog。formatjson。logsprometheusrunstatus。log
　　数据保留周期是180天，请根据实际情况调整，其他参数的意义请自行help
　　在上面脚本的启动参数中，也可以通过参数storage。tsdb。pathdata修改本地数据存储的路径，不指定的话，时序数据默认是在prometheus的data目录下，如需修改数据的存储路径，建议存放在性能好（SSD、高端磁盘阵列）、容量大的目录中。接着启动prometheus，并检查是否启动成功〔rootprosvrslaveprometheus〕shstartPrometheusSvr。sh〔rootprosvrslaveprometheus〕psauxgrepprometheusroot51073。716。076896035456pts0Sl17：180：00。prometheusweb。enablelifecycleconfig。file。confprometheus。ymllog。levelwarnlog。formatjsonroot51140。00。4112812976pts0R17：180：00grepcolorautoprometheusYouhavenewmailinvarspoolmailroot〔rootprosvrslaveprometheus〕netstattulnpgrepprometheustcp600：：：9090：：：LISTEN5107。prometheus〔rootprosvrslaveprometheus〕准备从master拉取配置文件目录的脚本startUpdateSyncConf。sh，代码：！binshtimelogdateYmdH：M：Secho｛timelog｝配置更新器启动pullwaitsec2whiletruedowgethttp：192。168。11。146：8000noticeslave。actionOnoticeslave。actiondevnull21statuscat。noticeslave。actionif〔｛status｝eq1〕thentimebakdateYmdHMStimelogdateYmdH：M：Secho｛timelog｝从master下载配置压缩包文件wgethttp：192。168。11。146：8000conf。tar。gzOconf。tar。gzecho｛timelog｝备份原有的配置目录mv。conf。backupconfbak｛timebak｝echo｛timelog｝解压下载后的配置压缩包tarzxfconf。tar。gzecho｛timelog｝热重启prometheus服务curlXPOSThttp：127。0。0。1：9090reloadfisleep｛pullwaitsec｝done
　　pullwaitsec参数控制每隔时间工作一次，首先会从master中拉取通知文件noticeslave。action，并读取里面的结果，如果是1，则说明master上的配置文件有变化，接着会执行一系列操作。如果是0，则什么也不做。创建热重启的脚本hotrestartprometheus。sh！binshcurlXPOSThttp：127。0。0。1：9090reload
　　日常维护中，在slave主机上，如有必要时方便手动执行热重启创建汇总启动脚本startall。sh！binshnohupshstartUpdateSyncConf。sh。logsupdatesync。logsleep3sh。startPrometheusSvr。sh
　　日常维护中，如需一次性拉起服务，执行该脚本即可创建汇总停止脚本stopall。sh！binshpsauxgrepstartUpdateSyncConf。shgrepvgrepawk｛print2｝xargskillpsauxgrepvgrepgrepprometheusawk｛print2｝xargskill
　　日常维护中，如需一次性停止服务，执行该脚本即可四、监控mysql案例
　　prometheus如何监控mysql？很简单，只需要在运行mysql的主机上安装mysqldexporter，mysqldexporter的用途是啥？说白了它就是用来收集mysql数据库相关指标的程序（官方就有，而且是go语言写的），mysqldexporter启动后默认监听9104端口（当然启动时可以通过相应参数进行更改），且它连接上数据库采集相应指标，并等着prometheus服务器来拉取。所以，需要在mysql中创建一个专门用于采集监控指标的数据库账号，让mysqldexporter通过这个账号去登录数据库采集指标，且这个账号要有相关权限（合适的权限即可）。所以的合适，请自行根据实际情况决定要给什么权限，如果是生产环境，一般的原则是：最小原则、够用就好。mysql测试环境信息以下是笔者的mysql测试环境
　　数据库
　　操作系统
　　IP
　　mysql8。0
　　centos7
　　192。168。11。150
　　说明：本篇只讲解如何使用Prometheus监控MySQL，MySQL本身的安装过程不在本篇范围内，请自行将MySQL安装好。下载mysqldexporterwgethttps：github。comprometheusmysqldexporterreleasesdownloadv0。14。0mysqldexporter0。14。0。linuxamd64。tar。gz登录mysql创建用于采集指标数据的专有账户创建账号mysqlcreateuserexporteruserlocalhostidentifiedbyRoot。123456withmaxuserconnections3；QueryOK，0rowsaffected（0。06sec）授权mysqlgrantprocess，replicationclient，selecton。QueryOK，0rowsaffected（0。00sec）刷新权限QueryOK，0rowsaffected（0。00sec）查看权限mysqlshowgrantsforexporteruserlocalhostG；1。rowGrantsforexporteruserlocalhost：GRANTSELECT，PROCESS，REPLICATIONCLIENTON。TOexporteruserlocalhost1rowinset（0。00sec）ERROR：Noqueryspecified查看账号mysqlselectuser，hostfrommysql。userhostexporterlocalhost这个，笔者曾经创建过的，不管它了exporteruserlocalhost这个是刚刚创建好的，就用这个啦！mysql。infoschemalocalhostmysql。sessionlocalhostmysql。syslocalhostrootlocalhostttr1localhost7rowsinset（0。00sec）mysql
　　关于mysql的数据库账号权限的授权和回收的知识，笔者以后会出一个专题，专门深入浅出的剖析，敬请大家的关注！部署mysqldexporter下载完成后，解压，并移动到规定的目录下（目录可自定义哈）tarzxfmysqldexporter0。14。0。linuxamd64。tar。gz〔rootmysql8db〕mkdirusrlocalexporter〔rootmysql8db〕mvmysqldexporter0。14。0。linuxamd64usrlocalexportermysqldexporter〔rootmysql8db〕cdusrlocalexportermysqldexporter〔rootmysql8dbmysqldexporter〕lltotal14824rwrr13434343411357Mar500：30LICENSErwxrxrx13434343415163162Mar500：25mysqldexporter这个就是可执行程序rwrr13434343465Mar500：30NOTICE创建连接mysql的配置文件并启动mysqldexporter创建连接mysql的配置文件〔rootmysql8dbmysqldexporter〕catexporterconnmysql。confEOF〔client〕userexporteruserpasswordRoot。123456EOF查看创建好的配置文件〔rootmysql8dbmysqldexporter〕catexporterconnmysql。conf〔client〕userexporteruserpasswordRoot。123456〔rootmysql8dbmysqldexporter〕启动mysqldexporter为了方便启动，创建一个启动脚本〔rootmysql8dbmysqldexporter〕catstartmysqldexporter。shEOFnohup。mysqldexporterconfig。mycnf。exporterconnmysql。confEOF〔rootmysql8dbmysqldexporter〕查看创建好的启动脚本〔rootmysql8dbmysqldexporter〕catstartmysqldexporter。shnohup。mysqldexporterconfig。mycnf。exporterconnmysql。conf〔rootmysql8dbmysqldexporter〕开始启动〔rootmysql8dbmysqldexporter〕shstartmysqldexporter。sh启动后查看相关端口（默认的端口为9104）〔rootmysql8dbmysqldexporter〕netstattulnpgrepmysqltcp600：：：33060：：：LISTEN1916mysqldtcp600：：：3306：：：LISTEN1916mysqldtcp600：：：9104：：：LISTEN2073。mysqldexpor这个就是啦！〔rootmysql8dbmysqldexporter〕〔rootmysql8dbmysqldexporter〕
　　说明：咦！config。mycnf这个参数我咋知道的？当然是可以使用help啦！这样。mysqldexporterhelp就可以知道有哪些选项啦！
　　还有一个奇怪的问题，怎么只有ipv6在监听？没有IPV4？其实不是啦！centos7以上，都是ipv6优先的原则，对ipv6的支持默认是开启的，ipv4其实也是有在监听的啦！启动后，通过浏览器访问指标页面暴露的HTTP服务地址（http：192。168。11。150：9104metrics）
　　看到这些指标了吗？Prometheus服务端会周期性的从Exporter暴露的HTTP服务地址（通常是metrics）拉取监控样本数据。
　　指标内容简单说明：HELP：用于解释当前指标的含义TYPE：说明当前指标的数据类型
　　比如下面的一个指标HELPmysqlupWhethertheMySQLserverisup。MySQL服务器是否启动TYPEmysqlupgauge指标的数据类型是gauge，测量、检测的意思，也有仪表盘的意思？mysqlup1mysqlup反应当前的状态，当前的值为1，说明是启动的，也可能为0（停止状态）
　　笔者去把Mysql给停止了，再次刷新指标页面，查看这个指标，发现确实变成了0
　　查看采集过程输出的相关信息
　　刚刚是通过nohup将mysqldexporter程序丢入到后台启动的，所以相关的输出信息默认是会写入nohup。out文件中〔rootmysql8dbmysqldexporter〕tailfnohup。outts20220521T13：40：01。735Zcallermysqldexporter。go：277levelinfomsgStartingmysqldexporterversion（version0。14。0，branchHEAD，revisionca1b9af82a471c849c529eb8aadb1aac73e7b68c）ts20220521T13：40：01。735Zcallermysqldexporter。go：278levelinfomsgBuildcontext（gogo1。17。8，userroot401d370ca42e。。。。。。
　　到此为止，在Mysql服务器主机上部署mysqldexporter的任务算是大功告成。
　　接下来回到PrometheusMaster中继续以下的操作在PrometheusMaster中配置从mysqldexporter收集监控数据
　　在Master中的prometheus主配置文件中的scrapeconfigs配置项添加基于文件的自动发现job
　　一定要注意：只需在master上做相关配置，slave主机会定时拉取master的配置目录和master保持同步，且slave的配置发生变更还会自动热重启使其生效，也就是说slave不用你操心，你只需管理好你的master就好。
　　再罗嗦一次：以下操作仅在master上操作。
　　在主配置文件usrlocalprometheusconfprometheus。yml中添加测试业务A的job
　　说明：下面的jobname为prometheusserver是拉取prometheus本身的指标数据（也就是监控其本身），IP地址是指向VIP：192。168。11。203，指向VIP这是建议的做法。scrapeconfigs：jobname：prometheusserverstaticconfigs：targets：〔192。168。11。203：9090〕jobname：测试业务Afilesdconfigs：files：。businesstestbusajob。ymlrefreshinterval：1s
　　参数说明：测试业务A的jobname：定义自发现的采集任务名称，按业务的维度进行定义名称，笔者这里叫测试业务Afilesdconfigs：这是基于文件的自动发现，即，下面这块配置都是和filesdconfigs有关的，详细说明如下：filesdconfigs：指定这是基于文件的自动发现files：。businesstestbusajob。yml指定自动发现配置文件的路径，这里表示在该路径下发现所有。yml格式的配置文件refreshinterval：1s自动发现间隔，时间默认是5秒，笔者这里设置了1秒。在规划好的业务目录（business）下创建对应的业务文件夹：testbusa，以及在业务目录testbusa下面创建job目录，并进入job目录创建mysql。yml（该名称可自定义，也可叫monmysql。yml或者其他，主要你喜欢就好！）在mysql。yml中定义拉取mysql的监控指标数据。confbusinesstestbusajobmysql。yml的内容如下：targets：192。168。11。150：9104labels：ip：192。168。11。150monitype：mysqlproject：测试业务Abusiness：测试业务A
　　参数说明：targets：拉取目标，这里指向mysql服务器的IP地址，mysqldexporter的端口是9104labels：这是标签，标签的主要作用是可以通过指定的标签查询指定的数据。
　　标签的作用：Prometheus中存储的数据为时间序列，是由Metric的名字和一系列的标签（键值对）唯一标识的，不同的标签代表不同的时间序列，即通过指定标签查询指定数据。不同的标签代表不同的时间序列，即通过指定标签查询指定数据。指标标签实现了查询条件的作用，可以指定不同的标签过滤不同的数据。
　　在PrometheusUI中对应的Labels信息如下图可见：
　　假设有个需求，需要知道被监控的mysql服务器所在的机房位置，那么就可以增加一个自定义标签，如下：。confbusinesstestbusajobmysql。ymltargets：192。168。11。150：9104labels：ip：192。168。11。150monitype：mysqlproject：测试业务Abusiness：测试业务Aregion：广州机房
　　在PrometheusUI中可以看到：不管你是用VIP、还是master、slave的物理IP去访问UI，结果都一样的，不信你试试。
　　自定义标签的主要应用场景：有了这些标签可以针对特定的标签去查询，比如笔者在上面的假设需求中，需要定义一个根据自定义标签region作为标识机房位置。总而言之，添加的标签越多，查询的维度就会越细。
　　在UI界面中的Graph面板中使用PromQL表达式查询特定监控指标的监控数据，如下查询mysqlup指标，如下图：
　　PromQL是Prometheus自定义的一套强大的数据查询语言，除了使用监控指标作为查询关键字以为，还内置了大量的函数，帮助用户进一步对时序数据进行处理。例如使用rate（）函数，可以计算在单位时间内样本数据的变化情况即增长率，通过PromQL我们可以非常方便的对数据进行查询，过滤，以及聚合，计算等操作。通过这些丰富的表达式语句，监控指标不再是一个单独存在的个体，而是一个个能够表达出正式业务含义的语言。当然，关于更多的PromQL知识，以后笔者会慢慢分享，本篇的重点是主备架构，可别跑题了呢！五、监控主机案例
　　为了能够采集到主机的运行指标如CPU，内存，磁盘等信息。可以使用NodeExporter。NodeExporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。下载nodeexporter并解压以及部署到指定目录wgethttps：github。comprometheusnodeexporterreleasesdownloadv1。3。1nodeexporter1。3。1。linuxamd64。tar。gztarzxfnodeexporter1。3。1。linuxamd64。tar。gzmvnodeexporter1。3。1。linuxamd64usrlocalexporternodeexportercdusrlocalexporternodeexporter可通过help查看一堆启动参数〔rootmysql8dbnodeexporter〕。nodeexporterhelpusage：nodeexporter〔flags〕Flags：h，helpShowcontextsensitivehelp（alsotryhelplongandhelpman）。collector。bcache。priorityStatsExposeexpensiveprioritystats。collector。cpu。guestEnablesmetricnodecpuguestsecondstotalcollector。cpu。infoEnablesmetriccpuinfo。。。。。。启动nodeexporter丢入后台运行〔rootmysql8dbnodeexporter〕nohup。nodeexporter查看监听的端口〔rootmysql8dbnodeexporter〕netstattulnpgrepnodeexportetcp600：：：9100：：：LISTEN1935。nodeexporte〔rootmysql8dbnodeexporter〕通过nohup丢入后台运行，相关的输出会追加到nohup。out文件中，必要时可查看该文件诊断相关问题〔rootmysql8dbnodeexporter〕tailfnohup。outts20220604T00：45：58。822Zcallernodeexporter。go：115levelinfocollectorthermalzonets20220604T00：45：58。822Zcallernodeexporter。go：115levelinfocollectortimets20220604T00：45：58。822Zcallernodeexporter。go：115levelinfocollectortimexts20220604T00：45：58。822Zcallernodeexporter。go：115levelinfocollectorudpqueues。。。。。。
　　笔者没啥特殊的需求，所以无需额外在给定启动参数，直接丢入后台运行即可，默认的监听端口是9100通过浏览器查看nodeexporter暴露的指标
　　在prometheus的master服务器中配置从nodeexporter收集监控数据
　　假设笔者的这台主机是测试业务b（testbusb）的一台主机，请按照之前的业务目录规范，在规范的业务目录（confbusiness）下创建业务文件夹testbusb。
　　再次罗嗦一次：仅需在master上做配置即可，slave会定时拉取masetr的配置目录，不要去管slave，OK？一个大男人那么罗嗦，真的很惹人讨厌啊！
　　在主配置文件中添加业务B的job主配置文件：usrlocalprometheusconfprometheus。ymlscrapeconfigs：jobname：prometheusserverstaticconfigs：targets：〔192。168。11。203：9090〕jobname：测试业务Afilesdconfigs：files：。businesstestbusajob。ymlrefreshinterval：1sjobname：测试业务B这是新增加的测试业务Bfilesdconfigs：files：。businesstestbusbjob。ymlrefreshinterval：1s
　　在规范的业务目录（confbusiness）下创建业务文件夹testbusb，然后创建host。yml，增加targets（拉取目标）的配置〔rootprosvrmasterbusiness〕cdusrlocalprometheusconfbusiness〔rootprosvrmasterbusiness〕mkdirtestbusb〔rootprosvrmasterbusiness〕cdtestbusb〔rootprosvrmasterbusiness〕mkdirjob〔rootprosvrmasterbusiness〕cdjob〔rootprosvrmasterjob〕cathost。ymltargets：192。168。11。150：9100labels：ip：192。168。11。150monitype：linuxcentos7project：测试业务Bbusiness：测试业务Bregion：深圳机房
　　在PrometheusUI中查看新增的测试业务B不管你是用VIP、还是master、slave的物理IP去访问UI，结果都一样的，不信你试试。
　　非常不错，只要检测到配置文件发生变化，master会自动热重启，slave也会自动拉取配置目录然后热重启，非常的省心、省力。自我感觉这个DIY的主备方案几乎接近完美，虽然没有用很高大上的语言、工具去实现，但笔者的这个思路自我感觉是非常的不错，这难道就是传说中的自我感觉良好？当然，笔者以后会通过Go或者Python打造一个管理Promtheus主备的工具，且是带UI的管理工具，敬请期待推出！我不造车，我只造零件。六、AlertManager警报组件配置
　　说明：基于二进制包的alertmanager组件请自行在master和slave中安装部署到规范的目录，之后继续下面的步骤。移动master和slave上的警报组件的主配置文件alertmanager。yml在master和slave服务器上，alertmanager组件的二进制包解压到规范的目录后，将警报的主配置文件alertmanager。yml移动到prometheus组件的conf目录下移动后（也就是用mv命令移动），查看如下：〔rootprosvrmasterconf〕pwdusrlocalprometheusconf〔rootprosvrmasterconf〕lltotal12rwrr134343434348Jun413：26alertmanager。yml警报组件的主配置文件已经也在prometheus组件下的conf目录drwxrxrx4rootroot42Jun409：18businessrwrr1343434341033Jun412：27prometheus。yml〔rootprosvrmasterconf〕
　　特别注意：上述操作，在master和slave上都要操作，且在slave服务器移动alertmanager。yml配置文件后，往后就可以不用去管slave上的alertmanager。yml配置文件了，主要的配置变更都在master上进行就好，如果有变更，slave会自动拉取配置目录。通常警报组件的alertmanager。yml配置文件一旦配置好后，改动的频率比较少。
　　特别说明：之所以这么设计，有两个好处：1）配置的变更都在同一个目录下进行；2）利用了现有master和slave的配置目录同步能力在master上配置警报的主配置文件usrlocalprometheusconfalertmanager。yml在警报组件中配置告警消息发往的接口地址，让其可以调用接口，配置方式很简单，只需要指定一下接口地址即可global：resolvetimeout：5mroute：groupby：〔。。。〕groupwait：1sgroupinterval：1srepeatinterval：1000dreceiver：web。hookreceivers：name：web。hookwebhookconfigs：url：http：127。0。0。1：5001webhooksendresolved：true
　　上述配置中，主要包含两大部分，路由（route）和接收器（receivers），所有的告警信息都会从配置中的顶级路由（route）进入路由树，根据路由规则将告警信息发送给相应的接收器。本篇主要是配置接收器，使用webhook的方式，假设是将告警消息推送到第三方平台。当然，在本篇仅为示例，打印出来而已。在master和slave上创建Alertmanager组件启动脚本注意：该步骤一定要进入到usrlocalalertmanager目录下进行操作创建脚本，名称：startAlertManagerSvr。sh！binshnohup。alertmanagerconfig。fileusrlocalprometheusconfalertmanager。yml。logsalert。log〔rootprosvrmasteralertmanager〕
　　注意：startAlertManagerSvr。sh脚本在masetr和slave中都要创建，且config。file使用绝对路径指向alertmanager。yml
　　通过该脚本拉起alertmanager组件shstartAlertManagerSvr。sh
　　注意：master和slave都要拉起
　　启动后，通过VIP或master和slave的物理IP都可以访问到警报的页面，笔者这里是使用VIP进行访问，如下图：
　　关联Prometheus与Alertmanager
　　注意：仅在master上配置即可，因为slave会从master上拉取usrlocalprometheusconfprometheus。ymlalerting：alertmanagers：staticconfigs：targets：192。168。11。203：9093
　　笔者这里通过VIP跟Alertmanager组件通信，当prometheus中的警报规则触发了告警后，告警消息就会发送到警报组件监听的9093端口，由alertmanager组件进行处理配置警报规则文件的自动发现
　　注意：仅在master上配置即可usrlocalprometheusconfprometheus。ymlrulefiles：。businesstestbusarule。rules。businesstestbusbrule。rules配置mysql的警报规则，当mysql挂掉后，使其触发警报
　　注意：仅在master上配置即可usrlocalprometheusconfbusinesstestbusarulemysql。rulesgroups：name：mysqlalertrules：alert：MysqlDownexpr：mysqlup｛job测试业务A｝0for：1mlabels：annotations：summary：MySQL数据库服务：｛｛labels。ip｝｝发生停止告警description：测试业务A的环境MySQL数据库服务：｛｛labels。ip｝｝已停止，当前UP状态值为：｛｛value｝｝，已触发告警条件：mysqlup0，持续时间：1m。alertLevel：5
　　上面的案例很简单，expr是表达式，该表达式是说：如果mysqlup指标的值等于0那么就触发该警报
　　可以通过promtool工具检查警报规则配置文件是否有误〔rootprosvrmasterprometheus〕。promtoolcheckrules。confbusinesstestbusarulemysql。rulesChecking。confbusinesstestbusarulemysql。rulesSUCCESS：1rulesfound
　　配置文件发生了变更后，master会自动热重启，slave会自动拉取配置并热重启，直接在UI界面上可以查看到该规则
　　笔者在这里假设用python编写了一个最简单的webhook接口，让其可以接收来自alertmanager的警报消息，然后打印出来
　　特别说明：只需在master上编写的webhook接口脚本，并且也放在规范的conf目录下：usrlocalprometheusconfwebhook。py，该API脚本会被slave拉取到webhook。py简单的API代码如下：importjsonfromflaskimportFlask，requestappFlask（name）app。route（webhook，methods〔POST〕）defwebhook（）：datajson。loads（request。data）print（data）ifnamemain：app。run（0。0。0。0，5001）
　　特别说明1：此示例API只是演示使用，请根据实际情况编写相关代码，本实例仅仅只是打印出来，并没有将告警推送到其他平台，如钉钉、邮件、或其他告警收敛平台。
　　特别说明2：如果您也想在您的测试环境将笔者的这个webhook。py跑起来，请自行安装python的flask库，笔者不在本篇讲解python的相关知识。python编程笔者后续会专门抽时间作为专题给大家分享，敬请您的关注。创建webhookAPI的启动脚本
　　说明：在master和slave都要创建startWebHook。sh脚本！binshnohuppython。confwebhook。py。logswebhook。log仅在master上启动webhookAPI〔rootprosvrmasterprometheus〕shstartWebHook。sh
　　特别注意：千万不要在slave上启动webhookAPI，具体原因在本篇的最前面已经有过解释（避免告警重复推送），只有当master不可用了，slave才拉起webhookAPI脚本进行承担告警推送的任务。模拟mysql故障，验证告警是否可以正常触发，验证由webhook是否可以正常接收在master上用tailf命令实时监测。logswebhook。log〔rootprosvrmasterprometheus〕tailf。logswebhook。logServingFlaskappwebhook（lazyloading）Environment：productionWARNING：Thisisadevelopmentserver。Donotuseitinaproductiondeployment。UseaproductionWSGIserverinstead。Debugmode：offRunningonhttp：0。0。0。0：5001（PressCTRLCtoquit）
　　登录Mysql主机，停掉mysql〔rootmysql8db〕catstopmysql。sh！binbashusrlocalmysql8binmysqladminSusrlocalmysql8mysql。sockurootpRoot。123456shutdown〔rootmysql8db〕〔rootmysql8db〕shstopmysql。shmysqladmin：〔Warning〕Usingapasswordonthecommandlineinterfacecanbeinsecure。〔rootmysql8db〕
　　没过多久，webhookapi就接收到了告警消息
　　同样，在Alertmanager告警页面中，也能看到告警消息
　　写在最后
　　到目前为止，该DIY的prometheus主备方案的全程搭建过程就已经完结了，期间涉及到很多知识点都还没有去深入的剖析，比如：PromQL，Metric类型，告警的分组、抑制、静默等等知识点。本篇的核心主题是把这个DIY的方案给搞起来，后续笔者会逐一分享更多关于prometheus的技能点，敬请大家的关注。谢谢！感谢您的关注，望多多转发、点赞。谢谢！
　　重磅！DIY的Prometheus主备方案，全网唯一。生产未上，测试先行。