on ghc-8.10 help sign in
typeable/katip/TODO.org
105 lines 3.5 kB history raw
3* katip
5** TODO Should we remove orphan IO instance and add a LoggingT?
6** DONE Add a "Maybe LocInfo" using a TH version of logF
7 CLOSED: [2015-02-28 Sat 21:23]
8** DONE Log current PID in Item
9 CLOSED: [2015-02-28 Sat 20:01]
10** DONE Rethink important fields
11 CLOSED: [2015-02-28 Sat 20:01]
13*** Maybe add a logF variant that uses the class, but it's not
14 mandatory
16*** Another variant that explicitly passes the fields of interest
18** DONE Add Verbosity to the mix
19 CLOSED: [2015-02-28 Sat 20:01]
21** DONE AppName -> [Text]
22 CLOSED: [2015-02-28 Sat 20:21]
24- LogEnv defines the base name-space
25- logF gets a [Text] argument for AppName namespace
26- Whe two are concatted for each message
30* katip-elasticsearch
32** DONE Efficient UUID generation (don't use system rng)
33 CLOSED: [2015-03-17 Tue 10:27]
35 Make RNG once, store it behind an mvar and use it in all uuid
36 generation. Use the rng-utils module for this.
38 Turns out =uuid= is already doing some clever stuff in their random
39 instance to make this plenty fast. Benchmarks show we can generate
40 > 1M ids/sec.
42** DONE Async size-capped buffer for incoming items
43 CLOSED: [2015-03-20 Fri 17:08]
44 Don't block log requests for server connection, add to buffer and
45 move on. If buffer fills up, drop further logs until there's space.
47 We can use a limited chan with a pre-check to make sure that if
48 the size limit is reached, we drop the request instead of blocking
49 until limit is reached.
51** TODO Be resilient to server disconnects and crashes
52 The async buffer method described above certainly helps with this.
53 In addition, make sure that nothing out of the ordinary happens if
54 the server is unreachable. Logging should not be an element in any
55 stack that can potentially induce a crash - that would defeat the
56 purpose!
58 This means:
59 - No slowdowns, no crashes even if server is unreachable
60 - No file descriptor hogging (tight loop retries, etc.)
61 - Gently try once in a while to see if the server has become
62 reachable again
64** DONE Connection pooling (bloodhound)
65 CLOSED: [2015-03-20 Fri 17:09]
67 Exposing Manager would solve this, as it does internal pooling.
69** DONE Stop using Strings everywhere (bloodhound)
70 CLOSED: [2015-03-20 Fri 17:09]
72 Seems to be a limitation of http-client that we'll have to live
73 with for now.
75** DONE update index settings on setup (when the API becomes available in bloodhound)
76 CLOSED: [2015-11-12 Thu 08:33]
78** TODO by-day or user scheduled index sharding
79 Consider using templates and write to indexes per-day. So rather
80 than building the direct index the user asks for, set up a template
81 that automatically gets applied to indices matching the prefix,
82 then create an index per day. Apparently this allows more efficient
83 searches. Its yet to be seen when one-big-index breaks down
84* katip-rotated-log
86** TODO Create a rotated-log scribe
88 This works just like the built-in Handle scribe, but pushes the log
89 through the rotated-log packages and therefore rotates files when
90 they get too large
93* katip-retry
95** TODO Implement combinator for creating exception Handler that log to katip
97 Along the lines of the built-in 'logRetries' in retry, but instead
98 captures structured information through katip.
100 Explicitly capture fields to aid in filtering:
102 - Retry number
103 - The exception
104 - The exception type - maybe via Typeable's typeOf?
105 - Decision result: Crashing vs. Retrying