Newest at the top
2025-10-19 17:23:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-10-19 17:20:42 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
2025-10-19 17:19:23 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-19 17:18:51 +0200 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 252 seconds) |
2025-10-19 17:15:45 +0200 | krei-se | (~krei-se@p200300f1cfff1817000000000000c8c6.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
2025-10-19 17:15:36 +0200 | trickard_ | trickard |
2025-10-19 17:05:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-10-19 17:04:19 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
2025-10-19 17:01:52 +0200 | img | (~img@user/img) img |
2025-10-19 17:00:47 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-19 17:00:33 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
2025-10-19 16:50:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-10-19 16:44:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-19 16:42:53 +0200 | Pozyomka | (~pyon@user/pyon) (Quit: WeeChat 4.7.1) |
2025-10-19 16:39:51 +0200 | weary-traveler | (~user@user/user363627) user363627 |
2025-10-19 16:39:29 +0200 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
2025-10-19 16:33:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-10-19 16:31:35 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-10-19 16:31:19 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds) |
2025-10-19 16:30:43 +0200 | Fijxu | (~Fijxu@user/fijxu) fijxu |
2025-10-19 16:29:12 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-19 16:22:06 +0200 | Fijxu | (~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 +0200 | merijn | (~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 +0200 | inline | (~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 +0200 | merijn | (~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 +0200 | morj | (~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 |