新接入服务忘了加监控，别慌从流量入口、进程清单、注册中心三个方向反向排查，半小时内就能锁定漏网服务，补上监控巡检的缺口。
服务漏监控，问题出在哪儿
业内专家指出,大多数线上故障的根因不是监控工具不行，而是 服务压根没被纳管，新服务上线时，开发自测通过、接口调通、数据正常，唯独忘了在监控平台登记，等流量高峰一来，没人提醒你CPU飙了、内存爆了、接口超时了，用户投诉了才发现服务已经挂了几个小时。
这类事故很典型,也最憋屈，查了一圈发现不是代码问题，不是架构问题，就是监控巡检名单里没有它。
新服务漏监控的场景往往集中在这么几类：
- 临时应急加的补丁服务,跑在测试机上直接转发流量了
- 某个内部工具型接口,没有走正式的发布流程
- 微服务架构下,新拆分的模块只在自己本地起了进程
- 第三方对接的Webhook回调接收端,配完就忘了
这些服务有个共同特征：有流量、有进程、有依赖，但监控系统里没名分，运维巡检时盯着已有的大盘，新服务自然不会出现在视野里。
如何排查未纳管服务
要找出漏网之鱼,得换个思路，既然监控系统里没有它，那就从其他一定会记录服务痕迹的系统反推。
从流量入口翻
流量入口是第一个能暴露服务的地方,Nginx、SLB、API网关，这些中间件兜住了所有进来的请求，不管监控平台知不知道这个服务，网关一定有它的转发记录。
操作路径：
- 登录Nginx服务器,查看
access.log中近24小时出现过的server_name或location字段，找出未在监控平台登记过的域名或路径 - 在SLB（负载均衡）控制台，查看后端服务器组列表，逐个比对是否都在监控平台有对应条目
- 检查API网关的发布记录,每个发布的API都应该有对应的监控大盘
具体命令示例：
# 提取最近一天访问日志中出现过的server_name
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
# 提取访问日志中的所有URI路径，找出不在监控范围的
awk '{print $7}' /var/log/nginx/access.log | cut -d'?' -f1 | sort | uniq -c
比对方式：把提取出来的域名和路径整理成列表，去监控平台搜索，搜不到的，就是漏网服务。
从进程清单查
流量入口能找到接入流量的服务,但有些内部服务不到网关，只在内网互相调用，这时候得看服务器上的进程清单。
操作步骤：
- 批量登录核心服务器,执行
ps -ef或ss -lntp列出现场监听端口 - 用
netstat -tlnp收集所有监听端口对应的进程名 - 拿端口列表和监控平台的端口监控列表逐项比对
# 列出所有监听端口及对应进程
ss -lntp | awk '{print $4, $6}' | sort
比较高效率的写法是写一个批量脚本,把所有服务器的监听端口收集到一张表里，然后导入到Excel或Notion里，和监控清单做VLOOKUP，匹配不上的，基本就是漏网服务。
从注册中心找
微服务架构下有注册中心,服务上线必须注册，这是天然的台账。
操作方式：
- 登录Nacos、Consul、Eureka或ZooKeeper控制台，导出当前所有已注册的服务列表
- 从监控平台导出已配置服务监控的全量名单
- 两个列表做差集,差集部分就是漏网服务
这个方法的精确度最高,因为注册中心里的服务一定在运行，而监控平台里不一定有，可以直接作为数据源。
从DNS解析入手
还有一个更隐蔽的入口DNS解析记录，很多服务对外暴露时用子域名区分，比如report.internal.example.com、callback.example.com，这些域名在DNS服务商或内网DNS服务器上有记录，但未必加了监控。
操作方式：
- 在内网DNS服务器查看最近一周新增的解析记录
- 对比这些域名是否都有对应监控
服务接入监控巡检清单
查出漏网服务之后,得有一套机制防止下次再漏，最直接的办法是把“接入监控”从口头提醒变成流程节点
，在服务上线流程中新增监控注册确认环节，统一接入流程，把监控巡检纳入验收条件，标准化的服务接入监控巡检清单是有效的手段。
上线前的监控预检
服务上线前需要完成一系列检查,确认监控就位后才能对外放流量，建议在团队内部建立一份对接清单，每上线一个新服务都按清单逐项打钩确认，把监控接入当作上线前置条件，未接入不允许发布，具体包括：
- 基础监控：CPU、内存、磁盘、网络出入流量是否接入
- 应用监控：JVM/Go Runtime的GC、协程、堆内存等指标
- 中间件监控：Redis、MySQL、Kafka的客户端连接数、慢查询
- 日志监控：错误日志是否接入ELK或Loki，并配置了关键词告警
- 拨测监控：核心接口是否有外部拨测任务
- 告警通知：是否配置了正确的告警接收人
服务接入后的复查机制
上线后一周内,需要做一次复查，确认监控数据确实在正常上报：
- 检查监控大盘是否有数据曲线
- 确认告警规则已生效,没有处于“未启用”状态
- 验证告警通知链路通畅
用巡检脚本自动比对
手动比对容易漏,可以写个简单的巡检脚本定期跑，思路是周期性同步注册中心全量服务列表到监控平台，自动生成差异报告。
# 伪代码示意 services_from_registry = fetch_from_nacos() services_from_monitor = fetch_from_prometheus() diff = set(services_from_registry) - set(services_from_monitor) send_report(diff)
用Python的requests库调用两边接口，二三十行代码就能搞定，跑起来后，每周自动收一封邮件，列出未接入的服务清单，定期人工确认一次即可。
日常巡检别只盯着已经亮灯的
监控巡检本身就是一项需要持续投入的长期工作,日常巡检不能只盯着已经在大盘上亮灯的服务，要留出专门时间检查“有没有新东西没纳入”。
巡检频率建议
- 每周：抽10分钟检查注册中心服务列表与监控平台名单的差异
- 每次发布后：确认本次上线的所有服务都已接入监控
- 每月：翻一遍Nginx和SLB的配置，找找有没有新增的转发规则
巡检工具配合
可以借助现有的一些工具辅助排查,比如Python脚本批量抓取注册中心的API数据（curl "http://nacos-server:8848/nacos/v1/ns/service/list?pageNo=1&pageSize=100"），或者使用Ansible批量执行端口采集命令并汇总结果，这些操作都是能落地的，不需要额外开发复杂系统，用脚本把手工比对的动作变成每天自动执行，效率会提升一个台阶。
把“防漏”变成自动化流程
查一次漏网容易,难的是每次都查，让监控接入成为发布流程的必经环节，配合日常巡检，系统才能稳定运营。
具体的自动化思路可以是：
- 在CI/CD流水线的最后一步加入一个检查任务，查询当前服务是否已在监控平台注册
- 未注册则构建失败,并在日志中提示监控配置缺失
- 已注册则自动通过,继续部署
实现上可以在Prometheus中通过服务注册中心自动发现新目标,在Grafana中配置自动生成看板，让监控平台本身就具备自动纳管新服务的能力，配置完自动发现规则后可加上告警规则，对未匹配到监控配置的服务主动告警，形成闭环。
常见问题
服务接入监控巡检清单应该包含哪些内容？
基础监控（CPU、内存、磁盘）、应用监控（JVM、GC、线程）、中间件监控（连接数、慢查询）、日志监控、拨测监控、告警接收人配置，共六项核心内容，每一项都要有明确的负责人和完成状态。
如何排查未纳管服务时不影响线上正常业务？
排查操作以只读为主,查看日志、查询注册中心列表、比对监控平台数据，不涉及修改配置或重启服务，不会对线上造成影响，注意避免在业务高峰期跑大量的日志分析脚本，建议在低峰期进行。
监控体系的价值在于“稳定兜底”，不遗漏任何一个新接入的服务，不放过每一条巡检记录，故障才会无从遁形，运维工作里最怕的不是故障本身，而是不知道它什么时候会来把每一个新服务都纳入监控视野，才能让这个“不知道”变成“可预期”。