V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Mianmiss
V2EX  ›  程序员

是否应该把程序日志写入到 Mysql 数据库中

  •  
  •   Mianmiss · 22 天前 · 5043 次点击

    RT 我发现我司很多开发以及一些外采的系统 都很喜欢把程序日志写入到数据库中。

    数据库压力、性能开销等都会受到影响

    49 条回复    2024-04-03 19:14:32 +08:00
    cnsdytedison
        1
    cnsdytedison  
       22 天前 via Android
    我认为应该,压力,性能开销花钱可以解决。持久化的日志没有的话锅就会在你身上。
    ewpui
        2
    ewpui  
       22 天前   ❤️ 2
    @cnsdytedison 中肯!
    isno
        3
    isno  
       22 天前   ❤️ 5
    日志如果要持久化,选择 es 、Loki 或者 Clickhouse 。选择 MySQL 肯定不合适。

    https://www.thebyte.com.cn/Observability/logging.htm
    Ayanokouji
        4
    Ayanokouji  
       22 天前
    关键是有给提供其他选择吗
    sakilascott
        5
    sakilascott  
       22 天前   ❤️ 2
    @isno 小系统用不着这么复杂的架构。
    lstz
        6
    lstz  
       22 天前 via Android
    过早的性能优化是万恶之源
    lstz
        7
    lstz  
       22 天前 via Android
    不过我不建议 db 存日志,听起来挺奇怪的,sftp 加文件更合理点
    adoal
        8
    adoal  
       22 天前
    用 syslog 协议写到专门的日志服务器去,那边再怎么处理归专人负责
    beneo
        9
    beneo  
       22 天前
    1. 看需求,如果你只有存的需求,MySQL 只要能抗住有空间,也无妨
    2. 有能力有时间就折腾 ELK 那套,毕竟用户可能提需求说要做分析
    idontnowhat2say
        10
    idontnowhat2say  
       22 天前
    我只见过审计和操作日志需要写 db 的,程序日志写 db 那也太奇葩了吧。日志这种顺序写的东西,存 db 还不如直接写磁盘吧。
    nuk
        11
    nuk  
       22 天前
    还行吧,得看日志多少,主要是如果要在页面查询会比较方便
    nqlair
        12
    nqlair  
       22 天前
    量少无所谓 大的话存 s3 然后 es 加对应的索引用来查询
    hui9000
        13
    hui9000  
       22 天前
    存是肯定得存,选择什么也有个先后顺序,工作是干不完的,不要一次解决,持续优化。
    不关你的事情别管。自己知道应该存哪就好。
    potatowish
        14
    potatowish  
       22 天前 via iPhone
    @isno MongoDB 适合吗
    isno
        15
    isno  
       22 天前
    @potatowish

    如果是标准化的日志系统(有分析、检索、告警),用传统的数据库不论是 MongoDB, 还是 MySQL 都不合适,索引太占内存,副本机制太占存储。

    看看 Loki 吧,有报警插件,有视图 Grafana ,搞出一套也不复杂。
    YaD2x
        16
    YaD2x  
       22 天前 via iPhone
    这是你考虑的吗,日志收集转换不是运维的工作吗
    Garphy
        17
    Garphy  
       22 天前
    把日志结构化,插入数据库更合适
    potatowish
        18
    potatowish  
       22 天前 via iPhone
    @isno 谢谢
    jiangzm
        19
    jiangzm  
       22 天前
    操作日志可以写数据库, 系统日志还是不要存数据库。
    FawkesV
        20
    FawkesV  
       22 天前
    需要追溯的可以写,不需要的临时日志不用了
    wheat0r
        21
    wheat0r  
       22 天前
    直接写数据库意义不大,处理过之后存进去就不错
    via
        22
    via  
       22 天前 via iPhone
    阿里云的 sls 很香
    dongzhuo777
        23
    dongzhuo777  
       22 天前
    看你现场实施运维的水平,如果你司现场实施运维只会数据库,那写入 mysql 没问题,反正都是异步丢进去 出问题了 他自己知道去捞日志。尤其是一些对外的接口调用的日志。
    salmon5
        24
    salmon5  
       22 天前
    日志也是数据的一种,比如计费日志、操作日志等,这些都要长期保存。也不是不可以。
    egfegdfr
        25
    egfegdfr  
       22 天前
    如果是业务上需要的日志,可以记,我司有些系统把程序日志也存里面了, 不过好像除了花钱,也没啥问题, 因为那个表也不对外提供服务
    cctv1005s927
        26
    cctv1005s927  
       22 天前
    转存别的吧,重要的资产扔 rds ,日志类的,扔 es 或者 clickhouse 就行,避免对主业务的影响。
    wanguorui123
        27
    wanguorui123  
       22 天前
    定期自动清理就行
    miaotaizi
        28
    miaotaizi  
       22 天前
    最烦这种把日志写到数据库的低级行为了, 正事儿不干, 就在那研究怎么写留言板

    接个 SLS 很难吗
    skywalkerfc
        29
    skywalkerfc  
       22 天前
    写到无所谓,弄个脚本定期清理就可以
    guo4224
        30
    guo4224  
       22 天前
    @lstz 日志就是为了存,不是为了用是吧
    cdlnls
        31
    cdlnls  
       22 天前
    我觉得这个是一种很 low 的行为。
    lx0758
        32
    lx0758  
       22 天前
    刚刚部署了一个 loki
    johnhuangemc2
        33
    johnhuangemc2  
       22 天前
    审计日志可以存数据库.
    运行日志就还是选传统方式吧, 轻量服务存文件, 大型服务存日志中心
    eastjoehan
        34
    eastjoehan  
       22 天前
    可以记,例如关键的增删改操作日志
    程序日志就没必要了,像楼上说的直接搞个日志采集组件,再搞个面板看看就好
    qW7bo2FbzbC0
        35
    qW7bo2FbzbC0  
       22 天前
    @potatowish 简单查查的话 OK 的,我有这样用。复杂的查询还是建议 loki es 啥的。mongodb 的数据压缩率还是可以的
    luozic
        36
    luozic  
       22 天前
    真为了性能+追踪,那都是用 kakfa 等 mq 去异步写入,至于之后存在啥地方,看公司规划
    xinshoushanglu
        37
    xinshoushanglu  
       22 天前
    看有没有价值,如果日志很关键,后续有查询需求,不管放 mysql 还是 es ,mongodb 都值得
    mezhangkai
        38
    mezhangkai  
       22 天前 via iPhone
    es ,省心就阿里云 sls 花不了几个钱,比 s3 还便宜
    lxdlam
        39
    lxdlam  
       22 天前
    日志需要持久化,尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案,但是不是最好的方案。

    将日志当作事件流,思考日志的使用场景:
    - 问题定位:最常见的 case ,通过请求、用户、设备等等维度抽取一个特定的事件流分析,哪一步出现了问题,这种 case 通常需要对一些特定的 field 当作 key ,抽取查询相关联的事件。
    - 数据分析:通过对特定事件进行聚合,计算出来一些业务或者技术指标,诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代,但是在错误日志聚合上仍然有价值。

    同时,日志有一些自己的特性:
    - Append only:日志绝大部分情况下不会有并发读写,且是 Append only ,我们更多考虑
    - 丢失冗余:根据日志量的关系,其实允许一定程度的日志丢失和冗余,也就是没有严格事务要求。
    - 量级和查询需求:很多日志都是大海捞针,允许一定的查询延迟和一定延长的运行时间

    从上面的角度,其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统,搭配 Kafka 之类将日志落进去;而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ;如果量小,使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。
    lxdlam
        40
    lxdlam  
       22 天前
    @lxdlam 没写完发出去了。补充一下特性第一条:日志绝大部分情况下不会有并发读写,且是 Append only ,我们更多考虑可以读写分离的架构,使用一些缓存、分片的技术难度会大幅下降,且能在合理资源量内得到一个不错的效果。
    securityCoding
        41
    securityCoding  
       21 天前 via Android
    边缘内部系统 qps 不过 10 爱咋存咋存,挂了也是靠人吼
    huijiewei
        42
    huijiewei  
       21 天前
    数据库只存操作日志和审计日志

    系统的日志都是单独存的
    wenye123
        43
    wenye123  
       21 天前
    看项目 小项目咋搞都行 大项目肯定还是得规范化
    akira
        44
    akira  
       21 天前
    有存就行,至于好不好,看实际情况再说。。。

    业务没起来前,存哪不重要,重要的是要存。
    业务起来了,钱到位怎么改都行。。。
    bthulu
        45
    bthulu  
       21 天前
    具体问题具体分析. 如果是公司内部部署到公网服务器, 对外提供服务, 那肯定不合适.
    如果是像我司这种, 都是部署在客户普通 PC 机上的, 不写数据库你写哪? 还整什么 es, loki, clickhouse, 你这不是让现场实施找罪受么, 不怕人家回公司打死你?
    dog82
        46
    dog82  
       21 天前
    关键的操作日志可以写进去,不过日志表的引擎换成 myisam
    nutting
        47
    nutting  
       21 天前
    直接写太侵入了吧,先正常写日志,到文件。再用采集模块到 es 什么的入库,这样解藕
    snitfk
        48
    snitfk  
       21 天前
    感觉放 ES 是比较合适的方案。速度快,查询也方便。支付的量级也比较大。数据库单表一大就会卡。
    julyclyde
        49
    julyclyde  
       21 天前
    写到关系型数据库,基本上可以认为是整个项目组没见过什么世面吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3245 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 12:42 · PVG 20:42 · LAX 05:42 · JFK 08:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.