hi all, I have just created a FAQ entry on how to configure SEC sending data into Graphite: http://simple-evcorr.sourceforge.net/FAQ.html#26
Comments from people who are using Graphite are welcome :) kind regards, risto On 02/07/2013 09:54 AM, Alberto Cortón wrote: > Hi, > > I also think these actions would be useful, specially those related with > socket outputs. I am currently using the kind of wrapper scripts that > David mentioned in order to send data to remote syslog servers or to our > graphite/carbon server. > > Regards, > > El 06/02/13 22:59, David Lang escribió: >> On Wed, 6 Feb 2013, Risto Vaarandi wrote: >> >>> hi all, >>> >>> as you know, currently there are number of outputs which are not >>> directly supported by sec. For example, with 'pipe' action one can feed >>> only one event to an external program (with most programs exiting after >>> the 'pipe' action closes the pipe). Also, the 'write' action opens a >>> given file before each access and closes it afterwards. While this makes >>> output file rotation worry-free, it is not very efficient. Finally, sec >>> does not directly support various sockets as output (for example, it is >>> not possible to connect directly to a syslog server on another host and >>> issue syslog events without any intermediaries). >>> >>> Therefore, would there be any interest to an output action which would >>> leave the output open/running/connected, so that the next access of the >>> same output would not have to do reopen/restart/connect again? This >>> action would have to support a number of output types, e.g., >>> >>> write2 udp myserver:514 This is my event >>> write2 tcp myserver:514 Another event >>> write2 file /var/log/myevents Third event >>> write2 program /bin/logger -p user.notice Fourth event >>> >>> It is probably easy to see that with sockets and files it is not that >>> hard to distinguish them from each other, since the filename or server >>> name plus port number can serve as unique identifiers. With command >>> lines, however, it is somewhat more difficult, since an extra space or >>> different ordering of options makes two command lines different, even if >>> their effect is exactly the same. Also, since sec uses positional >>> parameters, there is an issue with parsing, although this could be >>> solved with the use of (). In addition, one workaround for both issues >>> would be storing command line in an action list variable. >>> The action outlines above would also need an output rotation mechanism, >>> but this could be implemented with adding this to SIGUSR2 handler >>> (closing all currently open outputs). >>> >>> Would the action above be of interest, and are there any other ideas for >>> handling these situations? >> I think this sort of thing would be useful, a lot of 'action scripts' end up >> being trivial wrappers to do these sorts of things, and opening/closing files >> and starting programs can have a surprisingly large effect on performance (I >> suspect that SEC has other bottlenecks, but even if it's not a bottleneck, >> speeding it up will leave more time for the bottleneck code :-) >> >> I would not try to match up command lines, as you note it's hard to tell when >> you really have two identical ones, and it makes it hard to have multiple >> connectons open to the same destination (important for network connections) >> >> This crys out for a filehandle approach, have something define the output and >> then write2 can use it. You can have calendar events close and re-open the >> files >> for log rotation >> >> >> >> now, as to specific output options. My first thing is make this extendable, >> people will have lots of strange outputs they want to talk to. Make it so >> they >> can define a perl subroutine and use that. >> >> you need pipe to command line (think |gzip -c ->/var/log/alerts.gz) >> >> you need send to syslog, but this may not be just send the raw string. Syslog >> message formatting is common across the different transport types, so it >> would >> be more 'open syslog destination' than 'open tcp destination' >> >> In formatting the syslog message, options that jump out at me include: >> >> facility/priority >> >> syslog tag (program name) >> >> source hostname (it's useful to be able to generate alert messages with >> the >> name of the relavent server, not just the SEC box) >> >> syslog format (historic syslog rfc3164, new syslog rfc5424, lumberjack >> JSON, >> CEE, CEF, ....) >> >> how to handle multiline (report) data (send as multiple log messages, >> send as >> one message with newlines, send as one message with a different separator >> character,...) >> >> for these, there should be a default set at open time, but it can make sense >> to >> override these for particular messages. >> >> Much of this formatting stuff is useful even if just writing to files, >> so it >> may be that the right thing is to define the transport at open time and then >> have a function call to format the message at log time. >> >> >> thoughts? >> >> David Lang >> >> ------------------------------------------------------------------------------ >> Free Next-Gen Firewall Hardware Offer >> Buy your Sophos next-gen firewall before the end March 2013 >> and get the hardware for free! Learn more. >> http://p.sf.net/sfu/sophos-d2d-feb >> _______________________________________________ >> Simple-evcorr-users mailing list >> Simple-evcorr-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> > ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
