Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
laiwei opened this issue Apr 2, 2022 · 34 comments
Labels
good first issue Good for newcomers

Comments

@laiwei
Copy link
Member

laiwei commented Apr 2, 2022

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

示例

  • 企业或者组织: 夜莺
  • 地点:北京
  • 使用场景和经验分享:你们最看重夜莺的哪些功能,解决一个什么样的问题,以及使用规模和范围,使用夜莺监控构建企业级监控体系的过程中,有哪些好的经验分享。
  • 需求建议:希望哪些点上夜莺监控能做的更好,更契合您的使用场景。
@laiwei laiwei added the good first issue Good for newcomers label Apr 2, 2022
@laiwei laiwei pinned this issue Apr 2, 2022
@loveyang2012
Copy link

loveyang2012 commented Apr 2, 2022

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

@Puma000009

This comment was marked as off-topic.

@bbaobelief
Copy link
Contributor

bbaobelief commented Apr 15, 2022

  • 企业或者组织: inke

  • 地点:北京

  • 使用场景和经验分享:

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

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

  • 架构:简单抽象为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
Copy link
Contributor

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

@bbaobelief
Copy link
Contributor

bbaobelief commented Apr 19, 2022

@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
Copy link
Contributor

GitHamburg commented Apr 27, 2022

  • 企业或者组织: 方正证券
  • 地点:北京
  • 使用场景和经验分享:
  • 最看重夜莺的哪些功能:
    • 云原生监控,无缝对接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
Copy link

itlaborer commented Oct 1, 2022

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

@charles-liming
Copy link

charles-liming commented Oct 8, 2022

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

@harvey945
Copy link

harvey945 commented Oct 12, 2022

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

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

祝发展越来越好。

@alangong114
Copy link

alangong114 commented Oct 13, 2022

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

@wknb
Copy link

wknb commented Oct 13, 2022

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

@JellyTony
Copy link
Contributor

JellyTony commented Oct 13, 2022

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

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

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

@resigmund
Copy link

resigmund commented Oct 13, 2022

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

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

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

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

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

@Etckey
Copy link

Etckey commented Oct 13, 2022

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

@DoraCloud2012
Copy link

DoraCloud2012 commented Oct 14, 2022

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

@manneting
Copy link

manneting commented Oct 17, 2022

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

@markqin01
Copy link

markqin01 commented Oct 17, 2022

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

@qthrones
Copy link

qthrones commented Oct 28, 2022

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

@yyongwh
Copy link

yyongwh commented Oct 28, 2022

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

@starsliao
Copy link

starsliao commented Nov 7, 2022

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

@qiqiaobin
Copy link

qiqiaobin commented Nov 9, 2022

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

@opslinux
Copy link

opslinux commented Nov 22, 2022

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

@bigblue0
Copy link

bigblue0 commented Nov 22, 2022

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

@ccfos ccfos deleted a comment from opslinux Nov 22, 2022
@laoke91
Copy link

laoke91 commented Nov 22, 2022

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

@jicki
Copy link

jicki commented Nov 23, 2022

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

@zmkobe
Copy link

zmkobe commented Dec 8, 2022

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

@ljw999
Copy link

ljw999 commented Dec 13, 2022

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

@zhoubingdata
Copy link

zhoubingdata commented Dec 13, 2022

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

@shenghuofei
Copy link

shenghuofei commented Dec 27, 2022

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

@QooGeek
Copy link

QooGeek commented Feb 14, 2023

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

@cdy668
Copy link

cdy668 commented Feb 15, 2023

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

@cdy668
Copy link

cdy668 commented Mar 8, 2023

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

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

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

@wodedipan
Copy link

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

@710leo 710leo changed the title Who is Using Nightingale | 分享您使用夜莺监控的经验和最佳实践 Who is Using Nightingale | Share your experience and best practices with using Nightingale Monitoring Aug 15, 2023
@sunailong
Copy link

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

@710leo 710leo changed the title Who is Using Nightingale | Share your experience and best practices with using Nightingale Monitoring Who is Using Nightingale | 分享您使用夜莺监控的经验和最佳实践 May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests