On Tue, May 24, 2011 at 06:18:17PM +0200, Stephen Shirley wrote: > On Tue, May 24, 2011 at 11:05, Iustin Pop <[email protected]> wrote: > > As Ganeti matures, one of missing functionality is the ability to query > > it for things like: “What happened to this instance three days ago?”, > > “When was this instance powercycled?”, or “How many times was this > > OpCode executed in the past week?”. The lack of such background > > information hampers debugging of both the code and of the state of the > > fleet. > > Agreed, this is badly needed. In my case, i most frequently run into > it when i find an instance in ADMIN_down, but have no clue as to > *why*. > > > > Storage details > > ~~~~~~~~~~~~~~~ > > > > TO BE DONE > > > > Needs to be replicated. Needs to be time-limited or space-limited. > > > > Since the size of the audit log can be significant (e.g. 1000 > > instances * 2 operations per day * 365 = 730K entries. 1M entries with > > valid fields make a Python interpreter eat ~400MB RSS, and when > > converted to JSON it takes 200MB), we must allow download/expire on old > > entries. This means that long-term storage of audit logs is off-cluster. > > > > > > User interface > > ~~~~~~~~~~~~~~ > > > > The basic functionality is, of course, examining audit logs and being > > able to search them. Multiple ways of searching will be provided: > > > > - search by entity name > > - search by UUID > > - timestamp searches > > I'm wondering why use JSON
Ah, JSON was just an example. > , and why provide an interface? I'd be > perfectly happy with a plain text file with one line per entry that i > can just grep. The issue is that this definitely needs to be replicated. Do you think the replication should be just something alike to each node syslogg-ing to each other node? thanks, iustin
