On Tue, Sep 01, 2009 at 11:50:17AM -0700, Jordan Brown wrote: > [ I thought I asked this a year or two ago, but haven't been able to find > it. ] > > In the Brave New World of SMF, is it reasonable for a service to log by > writing messages to standard out or standard error, expecting SMF to > capture the output and dump it into the service log file? > > Argument for: > - Simple > - Automatically separated by service > - Automatically rotated > > Arguments against: > - No automatic date/time stamping > - No standard filtering mechanism (e.g. by priority) > - Not routable (can't send high priority messages to different > destinations, or send to a log server) > - Might confuse utilities attempting to parse svc.startd messages from log > files > - Might interact badly with log rotation, with service writing to a stale > log file after rotation > - Can't merge messages from multiple services into one log (to make > sequence visible and have a single place to look for problems)
Agree with your list. What is really needed is the floor wax and the dessert topping. There's a missing project which is a common, sensible API for error reporting, that would among other things: - If $SMF_FMRI is set, use stderr appropriately - Could be set externally to use syslog as needed by the deployment environment - Allows for structured payloads to transfer data to FMA - Could also capture data in a ring-buffer for post-mortem analysis, including key stuff like stack, errno, etc. - Can append/retrieve data from TSD or TLS such that a code path that dives through multiple complex libraries can attach multiple bits of error state to a single "token" and report it - Each call site is also a DTrace USDT probe site that can be enabled I started something like the first part in fmd when I wrote that: cscope for fmd_verror() to see at least a few of the above things. I'd like to see some of the folks in Fishworks and elsewhere in our org collaborate on this. When I think about how we should do error reporting when CIFS and Kerberos talk to each other, this is where I really see an increasing need for something like this. -Mike -- Mike Shapiro, Sun Microsystems Open Storage / Fishworks. blogs.sun.com/mws/
