Who is Using Nightingale | 分享您使用夜莺监控的经验和最佳实践

[laiwei]

可以通过在当前 issue 登记您的使用情况，并分享您使用夜莺监控的经验，将会自动进入 END USERS 列表，并获得社区的 VIP Support。

示例

• 企业或者组织: 夜莺
• 地点：北京
• 使用场景和经验分享：你们最看重夜莺的哪些功能，解决一个什么样的问题，以及使用规模和范围，使用夜莺监控构建企业级监控体系的过程中，有哪些好的经验分享。
• 需求建议：希望哪些点上夜莺监控能做的更好，更契合您的使用场景。

[loveyang2012]

• 企业或者组织: 中移动
• 地点：北京
• 使用场景：可视化监控报警配置
• 需求建议：急需巡检报表，可根据主机，监控项导出报表

[Puma000009]

你这么大的企业,付费吧,别跟我们抢开源了

[bbaobelief]

• 企业或者组织: inke

• 地点：北京

• 使用场景和经验分享：

• 最看重夜莺的哪些功能： 1.更契合云原生场景。 2.能节约大量成本。目前用的open-falcon, falcon-graph对disk.io和mem需求太高。使用n9e可以节约70%的成本。 3.更灵活的告警配置，更多聚合算法。

• 使用规模和范围： 使用规模：目前vm中的series数量有4亿+，实际应该是2亿+（之前为业务组打上标签导致很多指标重新上报了）。

• 架构：简单抽象为3个机房。国内有A,B机房，国外C机房。

  • A机房部署thanos，采样之后保存历史数据。

  • B机房部署VictoriaMetrics，提供3个月原始数据。

  • C机房部署Prometheus，量比较小。

  • 使用了telegraf采集基础监控，业务监控暂时通过falcon的/v1/push接口转发至n9e,后期下掉falcon由sdk直接上报。

  • telegraf加壳部署为n9e-agent,每个机器都往各自机房server写数据。

  • A,B机房的数据双写(集群：Default)，读写地址是通过srv域名做的区域解析。A区的server读自己的TSDB(thanos)，B区的server读(B机房部署VictoriaMetrics，提供3个月原始数据)。

• TSDB:

  • 时序存储测试了thanos,VictoriaMetrics,m3db。m3db因资源占用太高被下掉了。
  • m3db: m3 Coordinator节点经常oom,扩容到5台*256G的内存都不行，换了vm 5台128G的机器还有50%空闲。
  • thanos: 用的Receive模式，保存3个月原始数据，历史数据会采样之后上传到oss,压力主要在receive服务。

    thanos有个问题：query无法按时间就近查询receive,而是查询所有store地址然后合并数据(是否我的用法不当)？假如receive存7天数据，store存30天数据，我只想查最近7天的数据，他会同时查询receive和store,因为store数据可能保存在oss所以会很慢。为了解决查询速度慢的问题，加了query-frontend,store地址也合并为1个lb地址，初次查询会慢，后面就走缓存了。

  • VictoriaMetrics：vm我测试下来挺满意的，目前用了8台机器，总体资源使用不足40%。

• 需求建议：可以更易用，当然这个是大家共同探索的方向。

[chenginger]

@bbaobelief 请教几个问题 1、业务监控暂时通过falcon的/v1/push接口转发至n9e(将原来agent推送到transfer的压力都转发到n9e,为什么不考虑直接推送到vm或者Prometheus).后期下掉falcon由sdk直接上报(这块agent聚合能力放到sdk去处理吗？还是采取一分钟推送一次？感觉这块逻辑放到sdk是否会影响原来应用的资源使用) 2、之前falcon的nodata处理你们有遇到这块的问题嘛？

[bbaobelief]

@bbaobelief 请教几个问题 1、业务监控暂时通过falcon的/v1/push接口转发至n9e(将原来agent推送到transfer的压力都转发到n9e,为什么不考虑直接推送到vm或者Prometheus).后期下掉falcon由sdk直接上报(这块agent聚合能力放到sdk去处理吗？还是采取一分钟推送一次？感觉这块逻辑放到sdk是否会影响原来应用的资源使用) 2、之前falcon的nodata处理你们有遇到这块的问题嘛？

• 问题 1
  • 写n9e-server是为了配置多个远程写，还有n9e-server有ident注册逻辑，自动按业务组打标签功能。目前观察n9e-server没啥压力。
  • 我们现有的框架sdk是计算好之后1分钟上报一次falcon,为了n9e能快速上线，减少业务代码改动，用了falcon-agent转发n9e-server。
• 问题 2
  • nodata目前没有太好的方案。对于一些精确labels使用了absent_over_time函数告警。

[GitHamburg]

• 企业或者组织: 方正证券
• 地点：北京
• 使用场景和经验分享：
• 最看重夜莺的哪些功能：
  • 云原生监控，无缝对接Prometheus的能力，支持多种、多个数据源
  • 开源、活跃的社区、有问必答的专业监控咨询，构建了一个比较好的监控生态圈，能放心使用
  • 从Open-Falcon到夜莺，监控组件一直很稳定
  • 更有效的告警策略配置
  • 完善的监控数据查询、监控大盘构建能力
  • 按业务线进行读、写权限控制
• 使用规模和范围：
  • 测试环境监控对象接入1500+,生产环境监控对象接入近6000台
  • 测试环境监控策略700+项,生产环境监控策略3300+项
• 架构：目前是在同时使用Open-falcon和夜莺监控系统
  • 6机房，保留Open-falcon监控系统：Transfer组件转发到中心Transfer
  • 主机房夜莺server、webapi按官方推荐，根据需求多节点部署
  • agent：历史监控一直使用Open-falcon，涉及agent较多，且falcon-agent的适配和稳定性较好，采用夜莺facon push接口，进行数据同步；K8S使用grafana-agent采集；telegraf根据需求进行部署，进一步推广
  • 监控数据：中心Transfer 同步到夜莺；默认采用Prometheus TSDB，接入多个研发、运维的Prometheus数据源；VictoriaMetrics作为长期存储
• 需求建议：
  • 管控能力，更少的人管理更多的监控
  • 更容易上手，降低研发、运维等使用门槛
  • agent管理：状态、部署、更新、命令下发等能力
  • 插件或工具的管理及流程化

最后特别感谢夜莺监控团队对监控领域的辛勤付出和耐心解答！

[itlaborer]

企业或者组织: 深圳艾派 地点：西安 使用场景：可视化监控报警配置 需求建议：app或者小程序

[charles-liming]

企业或者组织: 人人公司 地点：北京 使用场景：可视化监控报警配置，日志监控，对接K8S ，做多集群prometheus 存储 需求建议：日志mtail 本身是日志告警的，有个组件叫loggie ，做日志告警以及日志收集，看是否可以整合，两个开源团队能否碰触火花

[harvey945]

企业或者组织: 诺瓦星云科技股份有限公司 地点：西安 使用场景：主要是监控VMware云的虚机，做可视化监控报警配置，应用日志监控，多集群prometheus 存储。 需求建议：可一边使用快捷查询，一边可提示语法方式制作、测试监控模板。碰到过好多，告警模板制作好了，许久没有告警。

最重要的是，作为一个监控系统，虽然不做大而全，但至少能提供一个批量处理集群的命令执行工具。比如ansible能集成就好了。

祝发展越来越好。

[alangong114]

• 企业或者组织: 路特斯
• 地点：武汉
• 使用场景和经验分享：
• 最看重夜莺的哪些功能：
  • 云原生监控，无缝对接Prometheus，grafana能力，支持多种、多个数据源
  • 开源、活跃的社区、有问必答的专业监控咨询，构建了一个比较好的监控生态圈，能放心使用
  • 灵活的告警策略配置，以及告警记录回溯能力
  • 企业级 SSO 无缝集成能力，按业务线，团队管理能力
• 使用场景：
  • 目前主要使用夜莺告警管理能力，以及和自研应用集成, 监控对象持续接入中
• 架构：目前是在同时使用kube-promethues和夜莺监控系统
  • 混合云：每个机房kube-promethues，夜莺server 进行部署
  • 主机房夜莺server、webapi按官方推荐，根据需求多节点部署
  • agent：使用grafana-agent 进行数据采集，telegraf 探索中
  • 监控数据：同步到夜莺server；各个机房采用Prometheus TSDB，每个机房单独的一台grafana做历史可视化查看；VictoriaMetrics作为长期存储
• 需求建议：
  • k8s 中服务监控告警集成能力支持，降低研发、运维等使用门槛
  • 告警收敛能力，告警风暴避免的方案
  • 电话告警能力支持

[wknb]

企业或者组织: 西安轻网 地点：西安 使用场景和经验分享： 使用k8s进行部署夜莺，categraf作为采集器采集数据。 最看重夜莺的哪些功能： 集采集器、告警、平台展示于一体，开箱即用。而且都是开源项目，可以从中学到很多东西。 使用场景： 使用k8s部署夜莺的nwebapi和nserver，categraf负责采集数据推送到nserver 需求建议： 1.在页面上支持对categraf采集器的配置，并可以通过配置内容反向查询agent 2.helm部署夜莺暴露nserver 3.活跃告警、历史告警列表支持从外部接入告警信息进行展示

[JellyTony]

企业或者组织: 分秒帧 地点：北京 使用场景和经验分享：

最看重夜莺的哪些功能： 云原生监控，无缝对接Prometheus，grafana能力，支持多种、多个数据源 开源、活跃的社区、有问必答的专业监控咨询，构建了一个比较好的监控生态圈，以及强大的 agent Categraf，丰富多彩的中间件插件。可以一键式接入监控平台。 使用场景： 目前主要使用夜莺告警管理能力，以及和自研微服务框架集成, 因为服务发现使用的 etcd，所以不能复用 Prometheus 已有实现 pull 发现，采用框架定时器 push 到 Categraf，然后 Categraf 再 push 到夜莺 server。 需求建议：

• 开源版本增加日志告警功能
• 增加告警升级功能，防止某个团队没人值班告警被忽略
• 企业版本增加排班功能等
• agent 增加 etcd 发现 pull 模式
• webbook 报警内容增加报警时刻的图表截图

[resigmund]

企业或者组织: 云算时代 地点：厦门

使用场景和经验分享： ·从open falcon开始接触 ·由于人力和规模情况；当前是v3的最终版本，等社区v6上线后准备迭代到v5的最终版本 ·M3其实不适合每个公司，内存消耗大，而且原生对接会跳过一个调度器的组件，如果不是开箱的话，会带来一定的工量摸索 ·结合Prometheus Thanos 对象存储做了一些冷热数据分离归档的调整 ·使用的历代版本都有很大的工量投入在自定义上报功能订制 ·说句无关技术的话，带宽和数据量，控本的问题要最开始规划好

最看重夜莺的哪些功能： 其实最看重企业版层层下钻的灭火图

使用场景： 数据量和成本问题有意只开启了一部分metrics，裸机量2k+这样子

需求建议： 实话实说，v2 v3 v4更像是三个产品，各有侧重和优势；v5则是拥抱生态 恳切建议产品经理要认真思考这个问题 或者说一句很外行的话，有没有一种可能做成本体和插件的形式来实现个人需求定制

[Etckey]

企业或者组织：中电信数智科技有限公司 地点：长沙 使用场景：可视化监控报警配置，日志监控，对接K8S,做多集群prometheus存储 需求建议：还学习摸索中，争取应用到公司多项目监控环境中

[DoraCloud2012]

企业或者组织: Freetalen 地点：BJ 使用场景：可视化监控报警配置 需求建议：学习中

[manneting]

企业或者组织：上海联合产权交易所有限公司 老卢 地点：上海 使用场景：可视化监控报警配置，日志监控，对接K8S,做多集群prometheus存储 需求建议：学习摸索

[markqin01]

企业或者组织：北京远舢智能科技有限公司 地点：北京 使用场景：可视化监控报警配置，日志监控，对接K8S 需求建议：我是夜莺V4用户，目前在调研V5，还在学习摸索阶段中。

[qthrones]

• 企业或者组织: Bespin
• 地点：北京
• 使用场景：混合云监控
• 需求建议：可支持报表导出功能；管理界面易用性期待改善，可支持更多的业务场景，开箱即用；

[yyongwh]

企业或者组织: 北京华宇信息技术有限公司 地点：北京 使用场景：k8s、私有云监控 需求建议：还在学习摸索中

[starsliao]

企业或者组织: 深圳开#思#时#代科技有限公司 地点：深圳 使用场景：K8S告警，日志监控告警 需求建议：可支持动态告警，时序预测

[qiqiaobin]

企业或者组织: 传化智联 地点：杭州 使用场景和经验分享： 用夜莺替换了原先使用的zabbix和owl监控系统，categraf作为采集器采集数据。 最看重夜莺的哪些功能： 云原生监控，无缝对接Prometheus，grafana能力，支持多种、多个数据源 开源、活跃的社区、有问必答的专业监控咨询，构建了一个比较好的监控生态圈，以及强大的 agent Categraf，丰富多彩的中间件插件。可以一键式接入监控平台。 使用场景： 可视化监控报警配置，k8s监控，监控对象持续接入中 需求建议： 1.支持报表统计，能进行资源使用量报表展示。 最后特别感谢夜莺监控团队对监控领域的辛勤付出和耐心解答！

[opslinux]

企业或者组织: 格创#东智 地点：深圳 使用场景：K8S告警，智能告警 需求建议：可支持动态阈值，报表分析，指标管理，agent管理

[bigblue0]

企业或者组织: 中移动 地点：苏州 使用场景：可视化监控报警配置，网络设备监控 需求建议：设备端口变动及时告警

[laoke91]

企业或者组织: 浙江强云 地点：金华 使用场景：可视化监控报警配置，网络设备监控、可视化监控报警配置，日志监控 需求建议：设备端口变动及时告警，全景能否像grafana 展示更直观

[jicki]

企业或者组织: 魔线科技(深圳)有限公司 地点：深圳 使用场景：K8S告警，日志监控告警 需求建议：支持动态告警，动态告警阈值，告警升级。

[zmkobe]

企业或者组织: 亚信 地点：南京 使用场景：Categraf采集器，采集windows一些性能指标，k8s云监控 需求建议：夜莺展示性能指标时候能更加具体点。类似grafana

[ljw999]

企业或者组织:深圳卓望数码 地点：深圳 使用场景：可视化监控报警配置 需求建议：还学习摸索中，争取应用到公司多项目监控环境中

[zhoubingdata]

企业或者组织:中国电信天翼电子商务有限公司 地点：上海 使用场景：可视化监控报警配置 需求建议：功能目前符合预期，整体还在探索使用中

[shenghuofei]

企业或者组织:https://www.odaclass.com/ 地点：北京 使用场景：可视化监控报警配置 需求建议：目前基本能满足线上需求

[QooGeek]

企业或者组织: 烽#云#信#息科技有限公司 地点：广州 使用场景：日常监控服务器 需求建议：还学习摸索中

[cdy668]

企业或者组织: 中国电信 地点：福州 使用场景和经验分享：n9e丰富的web界面功能配置，极大降低运维人员的运维门槛，即使是开发人员也能快速上手。目前接入服务器数量规模超过500+，后续考虑大规矩接入 需求建议： 1、希望可以支持kubernetes事件监控和告警，参考opsgenie/kubernetes-event-exporter 2、希望内置kubernetes_by_categraf监控大盘 3、针对n9e的监控大盘dashboard发布社区，可以提供给广大优秀创作者一个作品展示平台

[cdy668]

企业或者组织: 中移动 地点：苏州 使用场景：可视化监控报警配置，网络设备监控 需求建议：设备端口变动及时告警

• 企业或者组织: 中移动
• 地点：北京
• 使用场景：可视化监控报警配置
• 需求建议：急需巡检报表，可根据主机，监控项导出报表

巡检报表这块其实可以考虑支持监控对象-对象列表中支持根据业务组导出或者生成pdf文件

[jackshzhao]

企业或者组织: 品众互动 地点：北京 使用场景和经验分享：监控对象丰富，但对国产化数据库监控不足，其次图表中时序数据曲线突刺太多，可再优化一下。 需求建议：希望可以优化领导视图，大屏展示监控整体概况。

[sunailong]

企业或者组织:千桦资本 地点：上海 使用场景：可视化监控报警、监控数据分析及优化 需求建议：正在使用zabbix向N9E迁移，功能目前符合预期

[chenyunda218]

企业或者组织: 博維智慧科技 地点：澳門 使用场景和经验分享：接入victoriametrics數據源，使用N9E配置告警規則並將告警轉發至公司自研的系統。 需求建议：目前使用v6.7.3，通知模板管理UI和邏輯略為混亂，因此我們將告警轉發至公司自研的系統作處理。