1。目前的困境是作为云平台运维，牵扯到公司多个事业群的监控事宜。复杂的业务带来各种类型的指标处理，比如LB/MySQL/MongoDB/Redis/Pika/Kafka等几十种中间件或者业务自己上报的指标。这种情况给我们带来了一些挑战。将讨论以下四个方面：代理部署和监控。中间件维护方式多样，如何在多云环境下部署agent？统一采集，如何监控不同类型中间件的数据统一采集？统一标签，如何统一处理不同类型的指标，确保监控视图/告警能够路由到正确的业务团队？安全收集。对于需要auth的中间件，agent需要有独立的账号密码来采集监控指标。如何加密账户密码以确保安全？2、优化前exporter2.1agent的部署是基于混合云架构。同一个中间件，不同的业务组使用方式不同。比如mysql，A业务选择云工厂提供的托管RDS，B业务选择服务器上自建的MySQL。使用mysql_exporter进行索引采集时，native组件无法提供一对多的方式，即单个exporter只能采集单个数据库。资源的索引。对于自建MySQL，我们将exporter部署在中间件所在的服务器上；对于cloudfactorymanagedRDS，我们在每个VPC下选择了一台server，在这台机器上启动了不同的exporter进程来监控多个，由于实例的agent部署方式不一致，增加了资源变化时的运维成本，监控发现/离线等配置文件需要人工维护。虽然使用ansible来编排监控配置文件，但是需要编写多套playbook来为不同部署方式下的资源提供支持。通过file_sd将实例信息写入target，在prometheus中读取，而pika_exporter将实例信息维护在单独的配置文件中，agent直接读取配置抓取数据。Prometheus只需要配置jobnode_exporter[root@*~]#cat/etc/prometheus/file_sd/node.yml|head-n10-labels:public_cloud:"huawei"region:"***"team_id:"***"team_name:"***"host_name:"***"host_ip:"1.1.1.1"targets:-1.1.1.1:9100[root@~]#cat/var/lib/pika_exporter/pika.host-job_name:"node_exporter"file_sd_configs:-files:-"/etc/prometheus/file_sd/node*.yml"pika_exporter[root@~]#cat/var/lib/pika_exporter/pika.host1.1.1.1:6300,passwd,cluster_name[root@~]#cat/etc/prometheus/prometheus.yml-job_name:'pika_exporter'scrape_interval:30sstatic_configs:-targets:['127.0.0.1:9099']agent类型有几十种时，运维成本急剧上升，工作变得由经验和Manpower积累的辛勤工作决定监控资源类型：收集器服务器node_exporterredisredis_exportermysqlmysql_exportermongodbmongo_exporter......2。3标签统一对于每一个指标，我们希望能够溯源定位到具体的业务下，这样在监控视图/告警的时候，可以准确定位到团队，让团队专注于自己的监控和告警。底层标签的统一也方便了后续的上层运维应用更好的抽象各种业务特征。使用prometheus给job或者job下的target附加业务相关的标签，比如team_id=***,team_name=***标签怎么配置回到上面的问题，以MySQL为例，RDS单个云工厂的实例需要启用一个单独的expoter进程收集数据，所以在配置prometheus时，只能在job级别附加lable。对于云工厂提供的托管RDS/Redis/Mongo等实例，我们无法通过exporter收集一些主机相关的指标。exporter收集中间件接口返回的数据，没有能力收集中间件所在宿主机指标。例如无法获取CPU使用率/磁盘使用率/磁盘IOPS等指标。同时，我们不能使用社区导出器来采集一些资源指标，比如LB/VPC等相关的云原生组件。当然，成熟的云工厂会提供API或者他们定制的exporter来获取监控数据，但是metric/lable和社区的exporter是完全不一致的。即使我们可以通过cloudfactoryexporter获取到数据，我们也无法使用prometheus准确地将标签附加到每个资源上。比如AWS提供的cloudwatch，在对接prometheus时不需要配置target，所以只能在job层写label，给所有的资源贴上同一个label，不能满足我们的需求。如果配置的差异无法平衡，通过不同的方式获取metric/lable的差异，不仅增加了运维的复杂度，而且对于同一个中间件的监控/告警体验也是碎片化的，并不完善。2.4安全采集对于需要auth才能使用的中间件，我们需要维护一个密码配置文件供exporter使用，将密码明文保存在服务端是不安全的。3.优化后使用telegraf收集，使用telegraf解决痛点。https://github.com/influxdata/telegraf3.1Agent部署&统一采集对于常用的中间件资源，telegraf社区进行了适配，启用统一的telegraf二进制包，启动不同的systemds来管理不同类型的中间件，监控agent和telegraf输入原生支持一对多，单机部署即可满足所有中间件资源的监控指标抓取[root@~]#systemctlstatustelegraf-telegraf-mongo.servicetelegraf-mysql.servicetelegraf-pika。服务telegraf-redis.service[root@~]#cat/etc/prometheus/prometheus.yml-job_name:"telegraf-mysql"scrape_interval:15smetrics_path:"/metrics"static_configs:-targets:-127.0.0.1:9274-job_name：“telegraf-pika”scrape_interval：15smetrics_path：“/metrics”static_configs：-目标：-127.0.0.1:9275-job_name：“telegraf-mongo”scrape_interval：15smetrics_path：“/metrics”static_configs：-t：-127.0.0.1:9280[root@~]#cat/etc/systemd/system/telegraf-mysql.service[Un它]Description=TelegrafExporterAfter=network.target[Service]WorkingDirectory=/opt/apps/telegraf-mysqlExecStart=/usr/local/bin/telegraf--config/opt/apps/telegraf-mysql/telegraf.conf--config-directory/opt/apps/telegraf-mysql/telegraf.dRestart=on-failure[Install]WantedBy=multi-user.target3.2统一telegraf的处理器支持value映射，新的可以根据已有的key映射-valuelabels到metrics的参考链接：https://docs.influxdata.com/telegraf/v1.23/configuration/#metric-filtering这里我们使用mapping构造team_id、team_name、instance_name三个label，会查询allcapture如果检索到的mysqlmetrics中有server=1.1.1.1，将上面三个指定的key-value映射到metrics中的配置文件[root@~]#cat/opt/apps/telegraf-mysql/telegraf.conf[global_tags]region="***"[agent]interval="10s"round_interval=truemetric_batch_size=1000metric_buffer_limit=10000collection_jitter="0s"flush_interval="10s"flush_jitter="0s"precision="0s"hostname=""omit_hostname=false[[outputs.prometheus_client]]listen=":9274"[[inputs.mysql]]gather_global_variables=truegather_slave_status=trueinterval_slow="10s"servers=["username:password@tcp(1.1.1.1:3306)/"][[processors.enum]][[processors.enum.mapping]]tag="server"dest="team_id"default="null"[processors.enum.mapping.value_mappings]"1.1.1.1:3306"="123"[[processors.enum]][[processors.enum.mapping]]tag="server"dest="team_name"default="null"[processors.enum.mapping.value_mappings]"1.1.1.1:3306"="test-team"[[processors.enum]][[processors.enum.mapping]]tag="server"dest="instance_name"default="null"[processors.enum.mapping.value_mappings]"1.1.1.1:3306"="test-instance"test[root@~]#curl127.0.0.1:9274/metrics|grepmysql_up{mysql_up{instance_name="test-instance",region="***",server="1.1.1.1:3306",team_id="123",team_name="test-team"}1.生成配置文件，需要写一个脚本去资源中心获取具体的实例信息，进行自动渲染，实现监控的自动发现。这个要看运维需要有统一的资源平台，可以对内服务，就不细说了。当使用同一个监控代理时，脚本维护会很简单，否则不同类型的监控中间件需要编写不同的脚本来实现自动发现。同时，telegraf支持多种input数据输入。对于华为云的awscloudwatch或者cloudesye，我们可以使用它们先以job的形式在prometheus中抓取数据。此时不添加lable然后使用telegraf的映射输入prometheus数据，使用从资源中心获取的key-value对数据进行二次格式化添加需要的lable实现标签的统一引用链接:https://docs.influxdata.com/telegraf/v1.23/data_formats/input/3.3安全采集不幸的是，telegraf本身不支持密码加密。优点是telegraf各个组件的代码风格是统一的，不像各种exporter。对于telegraf的二次开发，只要实现一个INPUT模块的密码编解码，就可以快速复用到其他INPUT模块，高效实现各种中间件在使用监控时的密码安全。4.总结本文是近期监控采集器从exporter迁移到telegraf的总结，主要从代理部署、统一采集、标签统一、安全采集四个方面，对比前后差异优化。但是，telegraf也存在一些问题。Telegraf原生支持200多个模块，并提供各种高级功能。在实际使用中，发现部分模块抓取的指标并不尽如人意。比如mysql_exporter中的up指标（probingactivity），在telegraf没有收集使用的时候，可以根据需要剪掉，需要的模块可以保留，否则用起来会很重（二进制几百M）。对于更高级的用法，需要进行一些二次开发，以更好地适应业务需求。同时telegraf中的Grafana面板比较少，需要我们花点时间手动绘制。
