Hi, I have been using it since 2.7.1 was released and it works smoothly. Given that data is sent to Carbon in near real time I omit the timestamp parameter (%u) so the point is added with the timestamp of the insertion itself.
The only thing that bothers me is having to add the newline character at the end of the message, but this is a Graphite requirement. Your example also showed me how to solve an unrelated problem which I was figuring out how to solve :D Kind regards, El 04/06/13 16:06, Risto Vaarandi escribió: > 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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >>> >> > > -- Alberto Cortón Dept. Security Operations Center (S.O.C.) Tlf: 902 222 521 www.s21sec.com Comprometidos con la seguridad. La información contenida en este mail, así como los archivos adjuntos, es CONFIDENCIAL. Grupo S21sec Gestión, S.A. garantiza la adopción de las medidas necesarias para asegurar el tratamiento confidencial de los datos de carácter personal. En el caso de que el destinatario del correo no sea usted, le rogamos envíe una notificación al remitente y lo destruya de forma inmediata. La lectura y/o manipulación de esta información en la situación señalada anteriormente será considerada ilegal, permitiendo a la empresa remitente realizar acciones legales de diferente envergadura. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
