Streams2 implementation that inputs plain strings, bunyan records, glossy records, and outputs syslog formatted strings
npm install syslog-streams2Syslog protocol as a Node Transform stream.
var SyslogStream = require('syslog-streams2');
var stream = new SyslogStream();
stream.write('foo');
Some options are supported:
new SyslogStream({
decodeBuffers:
decodeStrings:
useStructuredData:
defaultSeverity:
PEN:
type:
facility:
{host|hostname}:
{name|appName}:
{msgId|msgID}:
pid:
});
The first set of options apply to the stream itself and how it handles incoming data. The second set of options are curried into the glossy instance that performs the translation.
local0. Can be overridden in .write().Valid facilities are:
KERN - Kernel messages
USER - User-level messages
MAIL - Mail system
DAEMON - System daemons
AUTH - Security/authorization messages
SYSLOG - Messages generated internally by syslogd
LPR - Line printer subsystem
NEWS - Network news subsystem
UUCP - UUCP subsystem
CLOCK - Clock daemon
SEC - Security/authorization messages
FTP - FTP daemon
NTP - NTP subsystem
AUDIT - Log audit
ALERT - Log alert
LOCAL0 - Local use 0
LOCAL1 - Local use 1
LOCAL2 - Local use 2
LOCAL3 - Local use 3
LOCAL4 - Local use 4
LOCAL5 - Local use 5
LOCAL6 - Local use 6
LOCAL7 - Local use 7
os.hostname(), falls back on the nil value(-). Can be overriden in .write().From RFC5424:
The HOSTNAME field SHOULD contain the hostname and the domain name of
the originator in the format specified in STD 13 [RFC1034]. This
format is called a Fully Qualified Domain Name (FQDN) in this
document.
In practice, not all syslog applications are able to provide an FQDN.
As such, other values MAY also be present in HOSTNAME. This document
makes provisions for using other values in such situations. A syslog
application SHOULD provide the most specific available value first.
The order of preference for the contents of the HOSTNAME field is as
follows:
1. FQDN
2. Static IP address
3. hostname
4. Dynamic IP address
5. the NILVALUE
process.pid, falls back on the nil value(-). Can be overridden in .write(). process.title, falls back on process.argv[0] followed by the nil value(-). Can be overriden in .write(). The APP-NAME field SHOULD identify the device or application that
originated the message. It is a string without further semantics.
It is intended for filtering messages on a relay or collector.
.write(). The MSGID SHOULD identify the type of message. For example, a
firewall might use the MSGID "TCPIN" for incoming TCP traffic and the
MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same
MSGID should reflect events of the same semantics. The MSGID itself
is a string without further semantics. It is intended for filtering
messages on a relay or collector.
Data is handled slightly differently based on the input. Bunyan-style records are identified by the presence of a msg key and validated against Bunyan's record format. Glossy-style records are identified by the presence of a message key and validated against Glossy's record format.
Records that fail validation, or that return false when run through Glossy will be converted to JSON and written as a plain string.
- When you provide a key matching a defined SDID in the RFC, such as 'timeQuality', 'origin', or 'meta'
- When you provide a PEN
Note: Object properties that do not contain objects cannot be converted to structured data (e.g. { custom: 'foo', msg: 'hello' }; neither can properties with keys that violate the acceptable characters for an SDID, e.g. { 'foo@bar': 'baz', msg: 'hello' }.
Standardized SDIDs will be validated and converted. Any remaining keys will be treated as custom structured data and formatted with your PEN.
Example:
log.write({ meta: { ip: '127.1.1.1' }, msg: 'hello' })
outputs:
<149>1 2014-12-05T23:01:36.170Z myndzi node 20465 - [meta ip="127.1.1.1"] hello
while
log.write({ custom: { key: 'val' }, msg: 'hello' })
outputs:
<149>1 2014-12-05T23:03:58.957Z myndzi node 20492 - [custom@32473 key="val"] hello
Clone and run npm test. Currently 75 tests and 100% coverage.