Newest at the top
| 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 |
| 2025-10-19 16:04:51 +0200 | <davean> | I don't actually find metrics to be a thing I ever look at with haskell services. There isn't ever anything to track down and they're performant. I can't recall the last time I had to pay attention to any metrics for them |
| 2025-10-19 16:03:43 +0200 | <davean> | As for metrics reporting, it depends on what metrics you care about. Like EKG is a pretty standard one. |
| 2025-10-19 16:02:33 +0200 | <davean> | I have a little internal library for some graceful shutdown handling, but its nothing that isn't already supported but not like cleanly hooked up |
| 2025-10-19 16:01:51 +0200 | <davean> | deployment? Just have nix build the cabal package and create a systemd service |
| 2025-10-19 16:01:20 +0200 | <ggVGc> | what does your deployment setup look like, davean? And what do you use for metrics reporting? |
| 2025-10-19 16:01:10 +0200 | trickard_ | (~trickard@cpe-57-98-47-163.wireline.com.au) |