在云服务器环境中，监控体系如果割裂成应用性能和底层资源两块，排障时就要在多个后台之间反复横跳。New Relic基础设施监控（Infrastructure）与APM的集成部署，正是为了解决这种数据孤岛问题。通过在云主机上运行基础设施代理，并把应用侧的APM代理指向同一账号和相同的实体标签，运维团队可以在一个界面里同时看到某台云服务器的CPU抢占情况和它上面跑的Java服务慢调用，大幅提升定位效率。
一、云服务器上安装New Relic基础设施代理
New Relic基础设施代理负责采集云服务器的操作系统级指标，包括CPU使用率、内存占用、磁盘IO、网络吞吐以及进程列表。在主流Linux发行版上，官方提供了脚本化安装方式，只需准备好License Key即可。以Ubuntu为例，先下载安装脚本并执行，脚本会自动添加软件源、安装newrelic-infra包并写入配置文件。配置文件通常位于/etc/newrelic-infra.yml，其中license_key字段必须填对，否则数据无法上报。
对于Windows云服务器，需要下载MSI安装包，运行后在配置界面填入License Key，或手动编辑C:ProgramDataNew Relicnewrelic-infranewrelic-infra.yml。安装完成后，代理会以系统服务形式自启。此时登录New Relic控制台，进入Infrastructure页面，就能看到该主机出现在主机清单中，并实时刷新指标。如果主机位于私有网络，需确保出站HTTPS到infra-api.newrelic.com和metric-api.newrelic.com的443端口通畅。
为了让后续APM数据能和这台主机关联，建议在基础设施代理配置中添加自定义标签，例如environment: production、role: order-service。标签是New Relic里串联不同遥测数据的纽带，没有统一标签，APM里的应用实例可能和主机认不上亲。配置标签后重启代理，主机卡片上就会显示这些维度，方便在告警策略里做分组。
二、APM代理与基础设施监控的关联部署
APM侧需要在云服务器上部署对应语言的应用代理，例如Java用newrelic.jar配合yaml配置，Node.js用@newrelic/node-agent模块。关键动作是在APM配置里设置相同的license_key，并尽量复用基础设施代理打上的主机标签思路，在APM的app_name和labels里保持环境一致。New Relic后端会根据上报IP和主机代理的心跳，自动把同一台云服务器上的APM应用实体和基础设施主机实体做映射。
实际集成中常遇到应用跑在容器里的情况。这时基础设施代理若只装在宿主机，能看到容器占用，但APM里的容器名可能和主机视图对不齐。解决办法是在宿主机装基础设施代理并开启容器集成，同时APM代理里设置相同的environment标签，这样在Entity Explorer里点开主机，侧边栏就能列出该主机上所有容器化的APM服务。某电商团队曾因测试环境漏打标签，导致APM报错率飙升却找不到对应云主机，补上标签后十分钟就定位到是一台缩容后的机器磁盘写满。
另外，若使用AWS、阿里云等云厂商的云服务器，New Relic基础设施代理还能通过云厂商元数据接口拉到实例ID、可用区、规格类型。这些信息会自动变成基础设施实体的属性，APM里也能通过关联查询到。建议在部署文档里写明：先装基础设施代理并验证主机在线，再发版带APM代理的应用，避免顺序颠倒导致关联延迟。
三、统一监控视图与告警联动实践
集成部署完成后，最核心的收益是统一视图。在New Relic的Explorer页面，选择一台云服务器，不仅能看CPU、内存曲线，还能直接看到该机上部署的APM应用最近的错误率和吞吐量。当基础设施代理报出某台机器网络丢包时，右侧APM面板若同步出现数据库调用延时长，基本可断定是网络层抖动拖慢了事务，而不用分别查两个系统再靠脑补对应。
告警方面，可以建立跨类型的告警策略。例如设定规则：当主机CPU持续高于85%且同一environment标签下的APM应用Apdex低于0.8，就触发紧急通知。这种组合条件靠单一APM或单一基础设施工具都难实现，集成后只需在New Relic的Alerts里用NRQL把infraMetric和apmMetric做join。某SaaS公司用此法把平均故障恢复时间从四十分钟压到十二分钟，因为值班人收到的通知直接带了双向证据链。
日常运维中还应定期审查标签规范和代理版本。基础设施代理和APM代理都有更新，旧版本可能不支持新的云服务器规格元数据。建议用配置管理工具统一推送代理升级，并在变更单里检查标签是否遗漏。只有把集成部署当成持续动作而非一次性任务，云服务器上的New Relic体系才能一直保持APM与基础设施监控的紧密咬合。
| 组件 | 部署位置 | 主要采集内容 | 关联方式 |
|---|---|---|---|
| Infrastructure代理 | 云服务器操作系统 | CPU、内存、磁盘、网络、进程 | License Key与标签 |
| APM代理 | 应用进程或容器内 | 事务耗时、错误率、外部调用 | 同账号与相同环境标签 |
| 云厂商元数据 | 代理自动获取 | 实例ID、可用区、机型 | 平台自动绑定 |
四、常见部署误区与排查思路
不少团队在云服务器上装完基础设施代理就以为集成好了，结果APM里应用还是孤零零的。常见原因是APM的license_key复制错账号，或者应用跑在代理安装前就已启动且没重载。排查时先查主机是否出现在Infrastructure清单，再查APM应用设置里的Account ID是否一致，最后确认两者标签里的environment值完全相同。哪怕大小写不同，New Relic也会视为两个维度。
另一个误区是防火墙只开了APM上报端口却堵了基础设施的域名。基础设施代理除metrics外还要拉取实体状态和日志配置，若HTTPS出站被限，主机可能间歇性掉线。可用curl从云服务器测试 infra-api.newrelic.com 的连通性。还有人把代理装进容器却没挂主机PID namespace，导致采集到的进程全是容器自身，失去对宿主机资源的可见性。正确做法是用官方容器镜像并授权host PID，或在宿主机裸装代理再加容器集成。
当所有检查都通过但仍不关联，可借助New Relic的Entity Relations图人工比对。点开主机实体看Linked entities里有没有应用，若为空，多半是上报时间间隔未重叠。让APM应用制造一点流量，等两分钟刷新，关联通常会自动出现。把这些误区写进内部运维手册，能减少新人重复踩坑。