Jeff Utter <[email protected]> wrote: > The earliest, promising solution I considered was raindrops, but it looks > as though you need to know all of the possible metrics up front - which > won't necessarily work as prometheus could use metrics based on parameters > which could vary.
You don't have to return all the data you'd aggregate with raindrops, though. Just what was requested. GDBM (in the stdlib), SQLite, RRD, or any "on-filesystem"[1] data store should work, even. If you do have a lot of stats; batch the updates locally (per-worker) and write them to a shared area periodically. I'd even batch incrementing the shared counters with raindrops if you have too many stats. Atomic increments (implemented with GCC intrinsics) may get expensive (as they require SMP memory barriers). [1] Definitely put any on-disk stats files on tmpfs (/dev/shm on most GNU/Linux setups) to avoid wearing out hard drives or SSDs. Otherwise disable fsync in GDBM (off by default, I think...) or SQLite (set the synchronous pragma to "off"). -- unsubscribe: [email protected] archive: http://bogomips.org/unicorn-public/
