1.简单介绍

服务监控作为运维的基本，是每个系统都必须要有的，那么如何针对相对来说系统没那么大，但是有需要监控设计一套方案呢？下面就是结合自己工作环境的情况，设计出符合当前技术栈的方案。
主要实现：

• 快速接入无代码修改
• 实现服务动态发现，减少手动配置

所以这次针对这些出一套相对简单易用的方案，减少接入的成本。

2.整体架构

image.png

这里的log日志组件正好是公司把所有服务都接入了日志的zk组件，这样我在这个zk就能拿到所有服务的ip，实现一个动态的服务发现。

3.技术细节

1.存放在zip包的内容存放了有2个文件，一个是prometheus的agent jar包，一个是导出的MBean定义配置

image.png

2.py的定时任务逻辑
整个流程的核心是从 ZooKeeper 中获取 服务注册信息，经过解析和转换，生成 Prometheus 可以识别的服务发现配置，实现对服务的自动发现

3.py的定时任务的配置

image.png

groups:
  - name: xxx_all_services
    zookeeper:
      hosts: "xxxxx:2181"  # ZooKeeper地址
      timeout: 10              # 连接超时时间（秒）
      # auth_data: [("digest", "username:password")]  # 认证信息（如果需要）

    dubbo:
      root_path: "/logs/logclient/"      # 服务在ZK中的根路径

    prometheus:
      #output_file: "dubbo_targets.json"  # 输出的Prometheus配置文件
      job_name: "xxx_services"         # Prometheus作业名称


# 采集端口配置
agent_ports:
  # OCS服务组
  SERVICE-GROUP1:
    engine-service: 19991
    data-service: 19992
    router-service: 19993
  #BSS服务组
    SERVICE-GROUP2:
     crm-service: 18932

这里配置了服务和端口就会自动采集对应的服务

4.接入步骤

1.gitlab添加prometheus的unzip maven下载地址

image.png

2.gitlab的构建docker镜像增加下载以及解压文件

1.找到docker build相关的构建镜像的地方

2.增加shell命令

mkdir -p ./agentJars;if wget --spider $prometheus_agent_jar_file_url 2>/dev/null; then wget -P ./$prometheus_agent_jar_file_url  && [-f ./%(basename $prometheus_agent_jar_file_url) ] && unzip ./$(basename $prometheus_agent_jar_file_url) -d ./agentJars; fi

image.png

这个shell命令就是下载文件并解压到构建机器上

3.dockerfile拷贝文件以及增加变量

image.png

这里的的MONITOR_AGENT_PORT端口必须全局唯一，也就是每个服务的都不一样。每次设置端口的时候请确保没有被别的服务使用，同时用的时候，请同步对应的运维让其添加到py定时任务，这样保证能被prometheus采集到**

4.启动脚本修改，增加agent

也就是dockerfile的ENTRYPOINT的start_docker.sh，增加以下内容:

image.png

5.prometheus部署 + grafana部署

1.prometheus的prometheus.yml文件增加配置

- job_name: "ucl_services"
  file_sd_configs:
   - files:
     - "/usr/local/prometheus/all_services.json"
   refresh_interval: 30s(base) 

2.将py定时任务放到部署prometheus的安装根目录，然后开个linux定时任务执行它，执行时间可30分钟一次
这样能保证周期性获取zk上面的服务

3.grafana部署
1.设置数据源为prometheus
2.导入预设好的面板
3.设置告警等

6.其他

1.目前的prometheus不是集群模式，如果做成集群可以应对更大服务规模
2.并不是所有的服务都有用zk、eureka这种注册中心，如果没有的话，就不好拿到服务的实例ip，这种情况下，需要考虑改造agent，直接和监控的后台建立起连接，通过上报ip，同时下拉监控后台的配置，完成更加轻量级的服务发现以及更灵活的配置
3.目前的方案只是一个适配于我司的方案，并不是都通用的，但是大体的监控接入都是逃不过这些方式的，大同小异，只不过是针对agent会做的更加完善，更加强大。例如可以将限流、垄断、监控等等都统一到一个agent，再通过agent后台管理端去管理接入了的服务，功能可以做到非常强大，这也是业界比较常见的一些处理方式。