<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>I was involved in a number of projects where syslog-ng was used in a relatively complex setup: we wanted to structure incoming log messages and transform them into nice & clean JSON messages.<br><br></div>In a number of cases, this required several parsers to get right (csv-parser, db-parser and sometimes regexps) and the resulting configuration was pretty complicated.<br><br></div>I've figured, that if we have a domain specific language in the form of the syslog-ng configuration file, we should also have a debugger that makes it easy to find out what went wrong. And this is what I have did, some proof-of-concept code is available on the f/debugger branch on github:<br><br><a href="https://github.com/balabit/syslog-ng/tree/f/debugger" target="_blank">https://github.com/balabit/syslog-ng/tree/f/debugger</a><br><br></div>Here's how it works:<br><br></div><div><span style="font-family:monospace"># start up syslog-ng with the -i option to indicate we <br># want the debugger enabled</span><br></div><span style="font-family:monospace">$ sbin/syslog-ng -iFe</span><br><br></div>Once syslog-ng starts up, you'll see something like this:<br><span style="font-family:monospace">Waiting for breakpoint...</span><br><br></div>For now, all processing elements within syslog-ng (called LogPipe) breaks into the debugger. Later, I want to implement real breakpoints, where you can selectively attach breakpoints to elements in the configuration file.<br><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"># on another console send a log message to syslog-ng:<br></span></div><span style="font-family:monospace">$ logger almafa</span><br><div><div><div><div><br></div><div>This is what happens on the syslog-ng side:<br><span style="font-family:monospace"><br>Breakpoint hit etc/syslog-ng.conf:11:2<br>11 unix-stream("log");<br>Dec 15 16:14:05 bazsi: almafa<br>(syslog-ng) </span><br><br></div><div>At a breakpoint, syslog-ng displays where the break has occurred, quotes the source line and displays the message that is being processed.<br><br></div><div>Now it becomes interactive, you can inspect the message with various commands:<br><br><span style="font-family:monospace">(syslog-ng) help<br>syslog-ng interactive console, the following commands are available<br><br> help, h, or ? Display this help<br> continue or c Continue until the next breakpoint<br> print, p Print the current log message<br> drop, d Drop the current message<br> quit, q Tell syslog-ng to exit<br>(syslog-ng) p $MSG<br>almafa<br>(syslog-ng) p<br>MESSAGE=almafa<br>PROGRAM=bazsi<br>LEGACY_MSGHDR=bazsi: <br>.unix.pid=18703<br>.unix.uid=1000<br>.unix.gid=1000<br>TAGS=</span><br><span style="font-family:monospace"><br>(syslog-ng) p "$(format-json --key *)"<br>{"_unix":{"uid":"1000","pid":"18703","gid":"1000"}, ... }</span><br><br></div><div><br></div><div>With the "continue" command, you can request syslog-ng to proceed to the next LogPipe, where it stops again. "drop" drops the current message, "quit" tells syslog-ng to exit.<br><br></div><div>I would really like to extend this to further ways, like:<br><ul><li>real breakpoints, instead of stopping everywhere</li><li>inject messages</li><li>change messages to make configuration testable<br></li><li>single-step (to the next primitive LogPipe) and step-over (to the next 'real' LogPipe that is found in the configuration file)</li><li>interactive REPL to template functions to make it easier to interact with them<br></li></ul><p>What do you think?<span class="HOEnZb"><font color="#888888"><br></font></span></p></div><span class="HOEnZb"><font color="#888888"><div><div><div><div><div><div><div><div><div dir="ltr">-- <br>Bazsi<br></div></div></div>
</div></div></div></div></div></div></font></span></div></div></div></div>
</div></div>