姿势一：只是把Nightingale作为WEBUI

只部署n9e-webapi和n9e-server，配合Prometheus以及各类Exporter，可以在夜莺WEBUI上查看监控数据，配置监控大盘，配置告警规则、屏蔽规则、订阅规则，查看活跃告警、历史告警。且各类配置可以按照业务组拆分归组，相互之间没有影响。

说只是作为WEBUI，其实不止，这种工作模式实际是替换掉了Prometheus内置的告警引擎+alertmanager，只需用Prometheus存时序数据，用Exporter抓取数据即可。

姿势二：使用Telegraf替代各类Exporter

Telegraf是个all-in-one的架构，一个二进制可以搞定机器、网络设备、中间件、数据库、Statsd等各种采集能力，相比散落的各类Exporter而言，维护成本更低一些，Telegraf支持通过OpenTSDB这个output plugin来对接夜莺。

此时就可以解锁夜莺的对象管理能力，因为Telegraf采集的数据，会流经n9e-server，n9e-server就可以从监控数据中解析出监控对象信息（标签中的ident或host，就表示监控对象标识），知道最近有哪些监控对象在上报数据，哪些监控对象已经失联了，就可以顺道做NODATA逻辑。

对象管理页面中，可以给监控对象打标签，这些标签会附到相关时序数据上，即：某个对象如果打了bg=cloud标签，这个对象有监控数据上报的时候，比如上报了cpu_usage_idle的监控数据，系统就可以从监控数据中解析出ident，然后根据ident找到页面上打的标签，然后把标签附到时序数据上。

过半的监控数据其实都可以关联到某个监控对象，看图的时候先找到监控对象，再查监控数据是个挺顺畅的路径，所以，这就是对象视角看图页面的设计初衷，用了Telegraf，也就可以解锁使用这个页面的功能了。

姿势三：使用VictoriaMetrics替换Prometheus时序存储

因为Prometheus时序存储是单机版，对于大规模场景，推荐使用VictoriaMetrics或者M3DB，因为M3DB有些复杂，一般建议使用VictoriaMetrics，VictoriaMetrics和Prometheus的查询接口完全兼容，所以夜莺也可以对接VictoriaMetrics，通过Prometheus协议的查询接口来查询VictoriaMetrics的数据。

所以大规模集群环境建议的组合方式是Nightingale+Telegraf+VictorMetrics，简称NTVM，如果是规模不大，组合方式是Nightingale+Telegraf+Prometheus，简称NTP，如果Telegraf的采集能力在某些场景下不足，可以用对应场景的Exporter来补齐。