我写的开源监控项目,有用吗?

tsingke 24天前 14

项目地址: https://github.com/AutohomeCorp/frostmourne

  • Elasticsearch 数据监控, 你只需要写一条查询就可以轻松搞定监控
  • 多种数值聚合类型监控(count,min,max,avg,sum,unique count,percentiles,standard deviation)
  • 数值同比监控
  • HTTP 数据监控, js 表达式判断是否报警
  • UI 功能,简单易用
  • 监控管理,测试,另存。执行日志,历史消息。
  • 灵活的报警消息 freemarker 模板定制,支持变量;消息模板管理
  • 多种报警消息发送方式(email,短信,钉钉(机器人),企业微信(机器人), HTTP 请求)
  • 多数据源(Elasticsearch 集群)支持
  • Elasticsearch 数据查询,分享,下载
  • 报警消息附带日志查询短链接,直达报警原因
  • 报警消息抑制功能,防止消息轰炸
  • 每个监控都是独立调度,互不影响
  • 自带账号,团队,部门信息管理模块,也可自己实现内部对接
  • 集成 LDAP 登录认证
  • 权限控制,数据隔离,各团队互不影响
最新回复 (26)
  • 楼主 tsingke 20天前
    引用 2
    为啥没人用起来,问题出在哪里?
  • fangyuanyoudu 20天前
    引用 3
    我觉得可能是需要用监控系统的自己就有实力搭建这种监控系统,没有实力的根本用不到这个级别的监控报警系统
  • prenwang 20天前
    引用 4
    功能太强,elasticsearch 太重, 运维成本过高
  • 楼主 tsingke 20天前
    引用 5
    @fangyuanyoudu 嗯,可能适用范围有点窄
  • 楼主 tsingke 20天前
    引用 6
    @prenwang 要是支持 mysql 数据监控呢?是不是就会轻一些了
  • parser 20天前
    引用 7
    数据量不大的话,可以选择在数据进入 Elasticsearch 之前就做分析监控
  • chinvo 20天前
    引用 8
    elastarlt
  • chinvo 20天前
    引用 9
    不过说实话,es 太笨重了
  • wangyzj 20天前
    引用 10
    不是你的问题
    监控这个行当就是不好干
    oneapm 这类的活的也都不好
  • 楼主 tsingke 20天前
    引用 11
    @chinvo 嗯,不知道除了 es,都用啥轻量一些的数据存储
  • tomsun28 20天前
    引用 12
    @tsingke 可以考虑 influxdb 存储
  • damngood 20天前
    引用 13
    监控不都 prometheus 和 grafana 搭配吗
  • prenwang 20天前
    引用 14
    @tsingke 我之前也是使用 elasticsearch 做监控,用起来很爽, 但是 es 是真的重, 不是每个项目都能给你 4 核 32g 的服务器让你爽, 这种情况下 ES 特别尴尬, 所以我觉得 ES 至少不适合小型项目使用, 还不如直接用 zabbix 。

    但是如果要自己来撸监控系统,又要在一定范围内用起来,覆盖到大部分场景,就是选择 mysql, 原因就是学习成本低, 百分之 80 的人可以轻松搭建配置 mysql,并且都有自己熟悉的一套维护方法。

    而其他的比如 mongodb,pg 系的 timescale,influxdb 等可能更合适做这个事情, 但是有个重要的原因, 他需要使用者去多学习一项额外的技能, 而这项技能即使比 mysql 简单也不一定能被认可, 这个是一种惰性, 就是不想学, 不想用, 我们自己或许可以突破,但是很多人还是不愿意, 比如我自己,能用 mysql 解决的我就不碰 MongoDB, 我就是不想维护两个数据库,哪天让另一个人去维护, 他先来一句“为啥用 mongodb 啊”, 那时你就想抽他一巴掌,再抽自己一巴掌。

    我总结了一下,这叫心智负担, 大部分比较喜欢技术和钻研技术的人,不会在意多用几种技术, 但是面向长期的使用场景, 越简单稳定的越好, 越不要自己折腾越好。

    如果有便宜的云 elasticsearch,mongodb,timescale 可以随便用, 因为云平台解决了基础维护, 不会给使用者太多心智负担。


    所以,总结下来, 其实 mysql 就很好, 也许有人说 mysql 真不适合存储日志类数据, 但是别忘了 MySQL 内置有 archive 存储引擎,那是专喂日志的, 压缩存储量只有 20%, 又不会有 CPU 压力,写入并发高的不得了, 虽然不能删除,没有索引支持, 但是通过按日期、月份分表就可以很轻松解决了, 程序里自动建表,控制单表数据量, 删除数据就直接删除历史表, 这也是符合日志型数据的管理方法的, 备份迁移直接拷贝数据文件, 不能再简单了,

    至于聚合,可以对固定类型的做预先聚合存储, 比如对秒级实时数据做分钟间隔,小时间隔的聚合计算后存储, 前端对实时数据就小范围查询, 大范围数据就去查询分钟间隔,小时间隔的统计数据, 这样就很快, 实际上工业物联网不少领域就是这么存储和处理数据的。

    前端可视化的可以输出到一些第三方系统, 比如 grafana, 或者直接使用 mapreduce,linq 、ReactiveX,echart 等方式输出。

    很多小型的项目, 数据量不大, 基于 mysql archive (甚至都不用),是最合适的, 最后顺便鄙视开口闭口就是 mysql 绝对不适合存日志的, 很多连百万级的量都没有碰过, 几十万的数据优化都不会。
  • aaa5838769 20天前
    引用 15
    尽量轻量化
  • 楼主 tsingke 20天前
    引用 16
    我后面会考虑对接轻量一些的存储,比如 mysql,influxdb 。现在的方案确实对部分团队来说太重了。
  • PUBG98k 20天前
    引用 17
    我看了下,觉得还是不错的一个开源项目.希望楼主继续努力.
  • foam 20天前
    引用 18
    我觉得主要还是要看你的监控落地后给业务部门带来了什么收益,如果收益太少就不足以让业务部门花精力。
  • 楼主 tsingke 20天前
    引用 19
    @PUBG98k 好的,多谢鼓励
  • meinjoy 20天前
    引用 20
    没人用 netdata?
  • cszchen 20天前
    引用 21
    我们用 rancher 部署 k8s 应用,基本的监控就够用了,还有普罗米修斯等等,应用的监控报警,用日志 + grofana 搞定,可能轮子比较多。
  • 楼主 tsingke 20天前
    引用 22
    大家都用的啥监控方案?
  • tikazyq 20天前
    引用 23
    @tsingke 参考这个 https://v2ex.com/t/659970#reply97
  • Chenamy2017 20天前
    引用 24
    要我用,我还是希望尽量轻量化,13#说的对, 越简单稳定的越好, 越不要自己折腾越好。
  • ErwinCheung 20天前
    引用 25
    监控不都 prometheus 和 grafana 搭配吗
  • 楼主 tsingke 20天前
    引用 26
    @tikazyq 看了你的贴子,获益良多,感谢。
  • 楼主 tsingke 20天前
    引用 27
    @ErwinCheung 应用日志监控,我这个项目应该会比 grafana 易用一些
  • 游客
    28
返回