2025/10/19

Newest at the top

2025-10-19 17:23:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-10-19 17:20:42 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-10-19 17:19:23 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-19 17:18:51 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds)
2025-10-19 17:15:45 +0200krei-se(~krei-se@p200300f1cfff1817000000000000c8c6.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2025-10-19 17:15:36 +0200trickard_trickard
2025-10-19 17:05:19 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-10-19 17:04:19 +0200Lycurgus(~juan@user/Lycurgus) Lycurgus
2025-10-19 17:01:52 +0200img(~img@user/img) img
2025-10-19 17:00:47 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-19 17:00:33 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-10-19 16:50:02 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-10-19 16:44:59 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-19 16:42:53 +0200Pozyomka(~pyon@user/pyon) (Quit: WeeChat 4.7.1)
2025-10-19 16:39:51 +0200weary-traveler(~user@user/user363627) user363627
2025-10-19 16:39:29 +0200weary-traveler(~user@user/user363627) (Quit: Konversation terminated!)
2025-10-19 16:33:43 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-10-19 16:31:35 +0200chromoblob(~chromoblo@user/chromob1ot1c) chromoblob\0
2025-10-19 16:31:19 +0200chromoblob(~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds)
2025-10-19 16:30:43 +0200Fijxu(~Fijxu@user/fijxu) fijxu
2025-10-19 16:29:12 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-19 16:22:06 +0200Fijxu(~Fijxu@user/fijxu) (Quit: XD!!)
2025-10-19 16:21:12 +0200 <davean> So modular, so very very bad code design
2025-10-19 16:21:00 +0200 <davean> partially because it keeps all its data in memory, transactionally, and doesn't retire references until requests complete.
2025-10-19 16:20:40 +0200 <davean> hackage reminds me of running python services :(
2025-10-19 16:18:42 +0200 <davean> hatz hackage I does, hatz it
2025-10-19 16:18:23 +0200 <davean> Actually the only service I run that *isn't* nice is hackage, and I REALLY REALLY want to finish a replacement for it
2025-10-19 16:18:07 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-10-19 16:16:00 +0200 <davean> but like things like HTTP response times, they're well characturized, if it goes above 10ms its just instantly tripping an alert.
2025-10-19 16:13:10 +0200 <davean> There is the standard tracing protocols if you want more detailed stuff
2025-10-19 16:11:43 +0200inline(~inline@2a02:8071:57a1:1260:99b9:102d:fb79:f90b) Inline
2025-10-19 16:11:11 +0200 <davean> That I do look at some EKG based stuff for
2025-10-19 16:11:10 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-19 16:10:47 +0200 <davean> to see service uptake rate
2025-10-19 16:10:37 +0200 <davean> I'm actually SLIGHTLY interested in that for launches
2025-10-19 16:10:16 +0200 <davean> personally
2025-10-19 16:10:12 +0200 <davean> I mean that would be a stats issue, though also why would I care? How many users I have overall might matter, but why do I care which hours generally? And if I did I can get that out of analytics, but which hour is never really relivent to me
2025-10-19 16:09:14 +0200 <ggVGc> how do you know how many users you have, for example, at during which hours?
2025-10-19 16:08:57 +0200 <ggVGc> for me, metrics is not something that has to do with errors/issues. It's a way to know things about the service
2025-10-19 16:08:51 +0200 <davean> don't need metrics for "if this ever happens, trip an alert on the first occurence"
2025-10-19 16:08:20 +0200morj(~morj@user/morj) morj
2025-10-19 16:07:38 +0200 <davean> well, my haskell code already uses a fixed DB pool and trades them out, so the only issue that could happen there is a DB error, thats a log issue not a metric issue
2025-10-19 16:07:10 +0200 <ggVGc> concurrent request numbers
2025-10-19 16:07:07 +0200 <davean> ggVGc: well think about the sort of problems you might have, most of them are error logs. Like a DB is down or something
2025-10-19 16:07:01 +0200 <ggVGc> what I mean is things like number of open DB connections, query times, HTTP response times, statistics on raturn codes etc.
2025-10-19 16:06:23 +0200 <davean> well the nix part is more significant
2025-10-19 16:06:21 +0200 <ggVGc> how do you know if you have or don't have problems without metrics?
2025-10-19 16:06:10 +0200 <ggVGc> Yeah, we also deploy as a systemd service at my current job, which I think is fine.
2025-10-19 16:05:30 +0200 <davean> god I spent so much time staring at metrics with python services ...
2025-10-19 16:05:05 +0200 <davean> One of the nice parts of haskell is never having problems