jenkinsci/syslog-java-client

A Syslog Client written in Java

Syslog Java Client

Description

Client library written in Java to send messages to a Syslog server.

• SyslogMessageSender: send messages to a Syslog Server. Support implementations
  • UdpSyslogMessageSender: RFC 3164 - The BSD syslog Protocol and RFC 5426 - Transmission of Syslog Messages over UDP
  • TcpSyslogMessageSender: RFC 6587 - Transmission of Syslog Messages over TCP (including SSL support)
  • TcpSyslogMessageSender: RFC 5425 - Transport Layer Security (TLS) Transport Mapping for Syslog (including SSL support)
• com.cloudbees.syslog.integration.jul.SyslogHandler: java.util.logging handler to output log messages to a Syslog server.

Release Notes and downloads

See https://github.com/CloudBees-community/syslog-java-client/releases/

Using the Syslog Java Client with Maven

Add the following dependency in your pom.xml:

<dependency>
    <groupId>com.cloudbees</groupId>
    <artifactId>syslog-java-client</artifactId>
    <version>1.1.7</version>
</dependency>

Sample UDP sender using RFC 3164

import com.cloudbees.syslog.Facility;
import com.cloudbees.syslog.MessageFormat;
import com.cloudbees.syslog.Severity;
import com.cloudbees.syslog.sender.UdpSyslogMessageSender;

...

// Initialise sender
UdpSyslogMessageSender messageSender = new UdpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("myapp");
messageSender.setDefaultFacility(Facility.USER);
messageSender.setDefaultSeverity(Severity.INFORMATIONAL);
messageSender.setSyslogServerHostname("127.0.0.1");
// syslog udp usually uses port 514 as per https://tools.ietf.org/html/rfc3164#page-5
messageSender.setSyslogServerPort(514);
messageSender.setMessageFormat(MessageFormat.RFC_3164); // optional, default is RFC 3164

// send a Syslog message
messageSender.sendMessage("This is a test message");

Sample UDP sender using RFC 5424

import com.cloudbees.syslog.Facility;
import com.cloudbees.syslog.MessageFormat;
import com.cloudbees.syslog.Severity;
import com.cloudbees.syslog.sender.UdpSyslogMessageSender;

...

// Initialise sender
UdpSyslogMessageSender messageSender = new UdpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("myapp");
messageSender.setDefaultFacility(Facility.USER);
messageSender.setDefaultSeverity(Severity.INFORMATIONAL);
messageSender.setSyslogServerHostname("127.0.0.1");
messageSender.setSyslogServerPort(1234);
messageSender.setMessageFormat(MessageFormat.RFC_5424);

// send a Syslog message
messageSender.sendMessage("This is a test message");

Sample TCP sender using RFC 3164

import com.cloudbees.syslog.Facility;
import com.cloudbees.syslog.MessageFormat;
import com.cloudbees.syslog.Severity;
import com.cloudbees.syslog.sender.TcpSyslogMessageSender;

...

// Initialise sender
TcpSyslogMessageSender messageSender = new TcpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("myapp");
messageSender.setDefaultFacility(Facility.USER);
messageSender.setDefaultSeverity(Severity.INFORMATIONAL);
messageSender.setSyslogServerHostname("127.0.0.1");
messageSender.setSyslogServerPort(1234);
messageSender.setMessageFormat(MessageFormat.RFC_3164); // optional, default is RFC 3164
messageSender.setSsl(false);

// send a Syslog message
messageSender.sendMessage("This is a test message");

Sample TCP over SSL sender using RFC 3164

import com.cloudbees.syslog.Facility;
import com.cloudbees.syslog.MessageFormat;
import com.cloudbees.syslog.Severity;
import com.cloudbees.syslog.sender.TcpSyslogMessageSender;

...

// Initialise sender
TcpSyslogMessageSender messageSender = new TcpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("myapp");
messageSender.setDefaultFacility(Facility.USER);
messageSender.setDefaultSeverity(Severity.INFORMATIONAL);
messageSender.setSyslogServerHostname("127.0.0.1");
messageSender.setSyslogServerPort(1234);
messageSender.setMessageFormat(MessageFormat.RFC_3164); // optional, default is RFC 3164
messageSender.setSsl(true);

// send a Syslog message
messageSender.sendMessage("This is a test message");

Sample TCP over SSL sender using RFC 5425

import com.cloudbees.syslog.Facility;
import com.cloudbees.syslog.MessageFormat;
import com.cloudbees.syslog.Severity;
import com.cloudbees.syslog.sender.TcpSyslogMessageSender;

...

// Initialise sender
TcpSyslogMessageSender messageSender = new TcpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("myapp");
messageSender.setDefaultFacility(Facility.USER);
messageSender.setDefaultSeverity(Severity.INFORMATIONAL);
messageSender.setSyslogServerHostname("127.0.0.1");
// syslog-tls usually uses port 6514 as per https://tools.ietf.org/html/rfc5425#page-11
messageSender.setSyslogServerPort(6514);
messageSender.setMessageFormat(MessageFormat.RFC_5425);
messageSender.setSsl(true);

// send a Syslog message
messageSender.sendMessage("This is a test message");

syslog-java-client's Issues

Generated RFC 3164 messages are not fine

Hello. The generated Message Sender:

UdpSyslogMessageSender messageSender = new UdpSyslogMessageSender();
messageSender.setDefaultMessageHostname("myhostname"); // some syslog cloud services may use this field to transmit a secret key
messageSender.setDefaultAppName("wz-"+ tag);
messageSender.setDefaultFacility(Facility.AUDIT);
messageSender.setDefaultSeverity(Severity.ERROR);
messageSender.setSyslogServerHostname("192.168.88.2");
messageSender.setSyslogServerPort(514);
messageSender.setMessageFormat(MessageFormat.RFC_3164); // optional, default is RFC 3164

send incorrect information to log szerver:
Time: Dec 20 12:35:23
IP: 192.168.88.236
Host: myhostname
Facility: mail
Priority: emerg
Tag: wz-StreamingShaderActivity
Message: HELLO Fomr Issues

I check te network traffic with Wireshark and the syslo-java-client generate an incorrect message.

0000 dc fe 07 2d 4f 21 a4 e4 b8 b0 61 0b 08 00 45 00 ...-O!....a...E.
0010 00 67 2e b2 40 00 40 11 d9 94 c0 a8 58 ec c0 a8 .g..@[email protected]...
0020 58 02 91 99 02 02 00 53 69 43 3c 31 36 3e 44 65 X......SiC<16>De
0030 63 20 32 30 20 31 32 3a 34 30 3a 33 39 20 6d 79 c 20 12:40:39 my
0040 68 6f 73 74 6e 61 6d 65 20 77 7a 2d 53 74 72 65 hostname wz-Stre
0050 61 6d 69 6e 67 53 68 61 64 65 72 41 63 74 69 76 amingShaderActiv
0060 69 74 79 3a 20 48 45 4c 4c 4f 20 46 6f 6d 72 20 ity: HELLO Fomr
0070 57 6f 77 7a 61 Wowza

Priority calculation wrong for rfc3164

The priority calculation is documented as the same for both formats:
https://tools.ietf.org/html/rfc3164#section-4.1.1
https://tools.ietf.org/html/rfc5424#section-6.2.1

However when I look in the code (SyslogMessage.java), I see this:
public void toRfc5424SyslogMessage(Writer out) throws IOException {

    int pri = facility.numericalCode() * 8 + severity.numericalCode();

    out.write('<');
    out.write(String.valueOf(pri));
    out.write('>');
    out.write('1'); // version
    out.write(SP);
    out.write(rfc3339DateFormat.format(timestamp == null ? new Date() : timestamp)); // message time
    out.write(SP);
    out.write(hostname == null ? localhostNameReference.get() : hostname); // emitting server hostname
    out.write(SP);
    writeNillableValue(appName, out); // appname
    out.write(SP);
    writeNillableValue(procId, out); // PID
    out.write(SP);
    writeNillableValue(msgId, out);// Message ID
    out.write(SP);
    writeStructuredDataOrNillableValue(sdElements, out);
    if (msg != null) {
        out.write(SP);
        msg.writeTo(out);
    }
}

VERSUS

public void toRfc3164SyslogMessage(Writer out) throws IOException {

    int pri = facility.numericalCode() + severity.numericalCode();

    out.write('<');
    out.write(Integer.toString(pri));
    out.write('>');
    out.write(rfc3164DateFormat.format(timestamp == null ? new Date() : timestamp)); // message time
    out.write(SP);
    out.write((hostname == null) ? localhostNameReference.get() : hostname); // emitting server hostname
    out.write(SP);
    writeNillableValue(appName, out); // appname

    if (msg != null) {
        out.write(": ");
        msg.writeTo(out);
    }
}

toString on fresh SyslogMessageSenders causes NPE

Whenever I used (TcpSyslogMessageSender.) in my exploratory Clojure REPL session, I got NullPointerExceptions. I traced this back to the toString:

https://github.com/CloudBees-community/syslog-java-client/blob/master/src/main/java/com/cloudbees/syslog/sender/TcpSyslogMessageSender.java#L242

this.getSyslogServerHostname() will raise NPE on uninitialized objects, because it's implemented as:

 return syslogServerHostnameReference.get().getHostName();

I'm not sure if the correct behavior would be to catch that exception and return null in that method, or in toString; either way, NPEs when toStringing a fresh object is probably a bug. If we can reach consensus on the fix, I'd be happy to contribute it.

TcpSyslogMessageSender.toString throws NPE in getSyslogServerHostname() if hostname is null

What it says on the tin.

Discovered this using it in a Scala worksheet, which automatically calls toString on the result of each source line.

Do syslog client Cloudbees support message format 5426 for UDP

We are currently using the latest version of cloudbees- v1.1.7 in this there is no 5426 message format support, in which version of cloudbees we can expect this message format support.

RFC5424 SyslogMessageFormat does not support structured data

This library does not seem to fully support RFC5424 syslog messages, i.e. you cannot send structured data in a message, as you can with syslog4j, http://www.syslog4j.org/docs/examples/examples.html.

Messages may be lost when the server proactively closes the socket.

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

centos7

Reproduction steps

When the server proactively closes the socket, the client does not detect the EOF and fails to close the socket. When the next syslog message is sent, the application layer does not throw an exception. As a result, the client considers that the message has been sent successfully, but the server does not process the message.

Expected Results

The client can identify that the server proactively closes the socket.

Actual Results

but not

Anything else?

No response

Cloudbees logs some loggers to tomcat console is there a way can this be redirected to any other file or path?

Hi, below code is logging information to tomcat console but we want it to be printed to some other file or path, are there any provision given by cloudbees inorder to achieve this instead of printing to tomcat console.

private synchronized void ensureSyslogServerConnection() throws IOException {
InetAddress inetAddress = syslogServerHostnameReference.get();
if (socket != null && !Objects.equals(socket.getInetAddress(), inetAddress)) {
logger.info("InetAddress of the Syslog Server have changed, create a new connection. " +
"Before=" + socket.getInetAddress() + ", new=" + inetAddress);

    }}

Ciphersuites are not in order

What feature do you want to see added?

In java there is an option (jdk.tls.client.cipherSuites) to provide list of ciphersuites that should be used during client hello message. But the order of ciphers are decided by JVM. This can be overridden using the method javax.net.ssl.SSLParameters.setUseCipherSuitesOrder(boolean honorOrder). This configuration we can set only during socket connection. Since Socket creation happens at the "syslog-java-client" library, there is no option for end-user to set this up.
It would be helpful to provide option or callback function to resolve this.

Upstream changes

No response

Generated RFC 3164 messages are not valid CEF messages (was "toRfc3164SyslogMessage appends bogus ':' suffix to syslog header")

toRfc3164SyslogMessage appends bogus ": " suffix to syslog headers. This makes it impossible to send proper CEF messages (which expect " CEF: " string right after the header).

MessageFormat.RFC_5425 is not found in provided java syslog client

Hi,

I have placed provided syslog java client
"""
com.cloudbees
syslog-java-client
1.1.7
"""

I am not finding RFC_5425 message format and I am seeing same entry in source code.

Do i need to go for any latest version of syslog java client?

Not able to find "SyslogMessageUdpSender" source class for UDP RFC 5424

Hi Sir,

I have used your Syslog Java Client with Maven and able to execute all sample codes except "Sample UDP sender using RFC 5424" as SyslogMessageUdpSender class is not available.

I am not even able to see SyslogMessageUdpSender class in source folder.

Please check and confirm sample code is correct for "UDP sender using RFC 5424".

add close() method to SyslogMessageSender

based on version: 1.1.2

In our use case, task is used to manage TcpSyslogMessageSender/UdpSyslogMessageSender.
When task run into error or need restart due to configuration update, we want to release connection hosted by SyslogMessageSender to avoid connection leak. To my limited knowledge, I cannot find a way to close connection on current version. It would be great if close() method be added to both TcpSyslogMessageSender/UdpSyslogMessageSender?

Support external SSLContext

In our particular case, we need to use SSL but bypass the certificate check. When TcpSyslogMessageSender is set to use SSL it creates a secure socket using default SSLSocketFactory. It could be better if I can provide a custom SSLContext and that is used to open the socket.

In TcpSyslogMessageSender:

ensureSyslogServerConnection(){
...
    if(sslContext == null) {
        socket = SSLSocketFactory.getDefault().createSocket();
    } else {
        socket = sslContext.getSocketFactory().createSocket();
    }
...
}

...

public synchronized void setSSLContext(SSLContext sslContext) {
    this.sslContext = sslContext; 
}    
public synchronized SSLContext getSSLContext() {
    return this.sslContext; 
}

Provide option to not flush TCPSender socket on every message

Flushing stream buffers when using the TCPSender is the only way to ensure data is not lost if the socket to the syslog server becomes invalid (eg. syslog server reboots) after the syslog client is instantiated.

Flushing "onSend" does have a performance penalty though, and in some cases end-users may be willing to do without that safety in return for greater performance.

TLS Version in syslog-java-client-1.1.7

Hi,

I would like to know which version of TLS(1.2 or 1.3) is using in CloudBees syslog java client(syslog-java-client-1.1.7).

Thanks,
Arjun.

Not able to find "SyslogMessageUdpSender" source class for UDP RFC 5424

Hi Sir,

I have used your Syslog Java Client with Maven and able to execute all sample codes except "Sample UDP sender using RFC 5424" as SyslogMessageUdpSender class is not available.

I am not even able to see SyslogMessageUdpSender class in source folder.

Please check and let me know how can I use java maven client for UDP RFC 5424.

Do cloudbees produce any additional entry for 5425 message format for TLS(TCP)

I am using Winsyslog as syslog server, if we use message format RFC_5425 for TLS communication one additional empty entry is appearing with each message sent this is only happening for 5425, 5424 format there is no any additional entry. So is this the expected behaviour using cloudbees as syslog client.Please can anyone confirm on this.

Not able to test TCP communication over TLS

Hi,

Can you please provide us clear steps to test TCP over TLS.

I have tried by loading certificates which are available but with that syslog server is not running and getting below error. I know we get below error when server is not running on particluar address and port

InetAddress of the Syslog Server have changed, create a new connection
       Exception in thread "main" java.net.ConnectException: Exception connecting to /127.0.0.1:6514

I have tried by setting another certificate but getting below error

Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Where is provision to configure SSL certs in given class TcpSyslogMessageSender.?

I need to complete testing TCP over TLS to incorporate this syslog-java-client into my application.

Thanks and Regards,
Arjun

Multiple things could slowdown drastically TcpSyslogMessageSender

TcpSyslogMessageSender has three things that need to be change in order for that class to be more reliable regarding performance

1. Connection timeout should be configurable and have a default value of 5ms (or even less)
2. Inner retry mechanism should be remove or be configurable
3. sendMessage should not be a synchronize method (actually one thread at a time can sent a log and could lead to huge slowdown when there is high volume of event being log)

• my recommendation is to start using non-blocking socket and remove the synchronization in order to avoid any performance issue

Does TcpSyslogMessageSender support self-signed certificates?

I am evaluating using this library to read a log file and send its contents off to a syslog receiver I've already built.

My understanding is that TcpSyslogMessageSender can be used to send messages over TLS using SSL certificates. However I don't see any "trust" configurations anywhere, which makes me wonder if self-signed (non-CA-signed) certificates are supported by this library at all?

If my syslog receiver on the other end presents this client with a self-signed certificate, how can I configure the TcpSyslogMessageSender to trust it?

Support Octet Counting message transfer method

Support Octet Counting message transfer method as defined in RFC 6587, section 3.4.1 as an alternative to the older Non-Transparent-Framing method.

Infinite loop in java.util.logging when logging is enabled on UdpSyslogMessageSender

  at com.cloudbees.syslog.sender.UdpSyslogMessageSender.sendMessage(Lcom/cloudbees/syslog/SyslogMessage;)V (UdpSyslogMessageSender.java:79)
  at com.cloudbees.syslog.integration.jul.SyslogHandler.publish(Ljava/util/logging/LogRecord;)V (SyslogHandler.java:109)
  at java.util.logging.Logger.log(Ljava/util/logging/LogRecord;)V (Unknown Source)
  at java.util.logging.Logger.doLog(Ljava/util/logging/LogRecord;)V (Unknown Source)
  at java.util.logging.Logger.log(Ljava/util/logging/Level;Ljava/lang/String;)V (Unknown Source)
  at java.util.logging.Logger.finest(Ljava/lang/String;)V (Unknown Source)
  at com.cloudbees.syslog.sender.UdpSyslogMessageSender.sendMessage(Lcom/cloudbees/syslog/SyslogMessage;)V (UdpSyslogMessageSender.java:79)
  at com.cloudbees.syslog.integration.jul.SyslogHandler.publish(Ljava/util/logging/LogRecord;)V (SyslogHandler.java:109)
  at java.util.logging.Logger.log(Ljava/util/logging/LogRecord;)V (Unknown Source)
  at java.util.logging.Logger.doLog(Ljava/util/logging/LogRecord;)V (Unknown Source)
  at java.util.logging.Logger.log(Ljava/util/logging/Level;Ljava/lang/String;)V (Unknown Source)
  at java.util.logging.Logger.finest(Ljava/lang/String;)V (Unknown Source)

Date format is getting changed after converting syslog object to toRfc5424SyslogMessage

Hi,

Require date as below format in my Syslog message

"2019-07-18T18:56:38.001+05:30"

Setting date using below API.

syslogMessage.setTimestamp

But After converting syslogMessage object to toRfc5424SyslogMessage and my format of date is changed as below.
"2019-07-18T13:26:38.001Z".
Is there any way to achieve my requirement?

is it possible to provide setTimestamp(String date) API which accepts string instead of Date object?

NPE if there is no connection established.

If I specify a hostname/port combination that does not result in a successful connection, a NullPointerException gets thrown when I call sendMessage():

java.lang.NullPointerException: null
    at com.cloudbees.syslog.sender.TcpSyslogMessageSender.ensureSyslogServerConnection(TcpSyslogMessageSender.java:121) ~[syslog-java-client-1.0.3.jar:na]
    at com.cloudbees.syslog.sender.TcpSyslogMessageSender.sendMessage(TcpSyslogMessageSender.java:90) ~[syslog-java-client-1.0.3.jar:na]
    at com.cloudbees.syslog.sender.AbstractSyslogMessageSender.sendMessage(AbstractSyslogMessageSender.java:53) ~[syslog-java-client-1.0.3.jar:na]
    at com.cloudbees.syslog.sender.AbstractSyslogMessageSender.sendMessage(AbstractSyslogMessageSender.java:60) ~[syslog-java-client-1.0.3.jar:na]

I suspect there needs to be another null check in the if condition here: https://github.com/CloudBees-community/syslog-java-client/blob/master/src/main/java/com/cloudbees/syslog/sender/TcpSyslogMessageSender.java#L121

(e.g. if (socket != null && socket.getInetAddress() != null && ...).

According to the Java docs:

the remote IP address to which this socket is connected, or null if the socket is not connected.

Facility uses incorrect integer values

The Facility class uses integer values 0-23, multiplied by 8. This is incorrect, they are defined as 0-23. The time to multiply them by 8 is when calculating the Priority value, facility * 8 + severity, per RFC 5424 (https://tools.ietf.org/html/rfc5424#section-6.2.1).

muting timestamp ?

Hi, first of all , thanks for this utility

Syslog viewers like kiwi already timestamp their record display and therefore currently at least the way I'm constructing the message a timestamp displays in the message column for Kiwi i.e. appended to my msg text. Is there a way of turning this off ? I tried passing null i.e. withTimestamp but that did not work.

thanks

Send message (TCP) failure after connection was closed by server

Affected version: 1.0.2
Steps to reproduce:

1. Connect to syslog server.
2. Succesfully send message.
3. Drop connection on server side.
4. Try to send message to server.
5. Restart server.
6. Try to send message to server.
   Results:
   Message on step 6 (and all subsequent messages) is lost. So there is no recovery if we encounter some problems on server side.
   Also see unit test (it is not wellformed with assertions, see console output)
   https://gist.github.com/TanyaGaleyev/47345007269429e5653e

TcpSyslogMessageSender close does not null check this.socket and will throw a NPE

TcpSyslogMessageSender close does not null check this.socket and will throw a NPE if not initialized

setSyslogServerHostname/setSyslogServerPort: could be declared in AbstractSyslogMessageSender

Hi.
Just curious: is there a reason why a/m methods were not declared abstract in AbstractSyslogMessageSender?

IllegalMonitorStateException when attempting to connect to hostname that does not resolve.

For example, if I set the the syslog server hostname to abc.def, and use an arbitrary port, I see the following exception:

Caused by: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
    at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447)
    at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340)
    at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883)
    at com.cloudbees.syslog.util.CachingReference.get(CachingReference.java:93)
    at com.cloudbees.syslog.sender.TcpSyslogMessageSender.ensureSyslogServerConnection(TcpSyslogMessageSender.java:121)
    at com.cloudbees.syslog.sender.TcpSyslogMessageSender.sendMessage(TcpSyslogMessageSender.java:91)
    at com.cloudbees.syslog.sender.AbstractSyslogMessageSender.sendMessage(AbstractSyslogMessageSender.java:53)
    at com.cloudbees.syslog.sender.AbstractSyslogMessageSender.sendMessage(AbstractSyslogMessageSender.java:60)

procid not being set for tcp RFC_5425 syslog message

Hello,

I've encountered a problem that the procid is not being set correctly -> procid seems to be either empty or "-" where long is expected.

        messageSender = TcpSyslogMessageSender()
        messageSender.syslogServerHostname = host
        messageSender.defaultMessageHostname = host
        messageSender.syslogServerPort = port
        messageSender.defaultAppName = appName
        messageSender.defaultFacility = Facility.LOCAL0
        messageSender.messageFormat = MessageFormat.RFC_5425
        messageSender.isSsl = true
        messageSender.sslContext = sslContext
       messageSender.defaultSeverity = Severity.INFORMATIONAL
        messageSender.sendMessage(message)
        messageSender.close()

Code used as above, everything else seems to be working correctly.

I'd be grateful for any help in this matter.

Does it support ipv6

RFC3164 timestamp are UTC instead of localtime

Hi,

I noticed that the RFC3164 format is logging time as UTC.
But the RFC (http://tools.ietf.org/html/rfc3164#section-4.1.2) says it should be local time:

The TIMESTAMP field is the local time and is in the format of "Mmm dd
hh:mm:ss" (without the quote marks)

https://github.com/CloudBees-community/syslog-java-client/blob/master/src/main/java/com/cloudbees/syslog/SyslogMessage.java#L75
The issue is the “TimeZone.getTimeZone("GMT"),” here. It should be “TimeZone.getDefault()”

Exception handling can be improved while closing socket(closeQuietly)

What feature do you want to see added?

Require to log error message and stack trace when we get exception while closing the socket.

Upstream changes

No response

Are you interested in contributing this feature?

Yes. Will make the changes and raise PR.

How to reuse TCP-TLS session?

` We are creating the context and setting to TCPSyslogMessageSender object, How to reuse the session and port number in TCP-TLS communication using Cloudbees- TcpSyslogMessageSender. Will it be handled by Cloudbees or we have to configure any settings explicitly. Here is our code. With this code, it is using a new port everytime.

TcpSyslogMessageSender messageSendertcp = new TcpSyslogMessageSender();
messageSendertcp.setSyslogServerHostname("localhost");
messageSendertcp.setSyslogServerPort("6514");
messageSendertcp.setMessageFormat(MessageFormat.RFC_5425);
messageSendertcp.setDefaultMessageHostname(this.getHostName());
messageSendertcp.setDefaultAppName("test");
messageSendertcp.setDefaultFacility("local0"));
messageSendertcp.setDefaultSeverity("notice");
logger.info("entering getsslcontext");
SSLContext context = getSSLContext(); //SSLContext is formed using client keystore and trustores
logger.info("context object");
messageSendertcp.setSSLContext(context);
messageSendertcp.setSsl(true);
}
try {

            logger.info("sending message tcp");
            messageSendertcp.sendMessage(syslogMessage);
        
        } catch (IOException e) {
        return false;
        } finally {
            try {
                if (messageSendertcp != null)
                    messageSendertcp.close();
            } catch (IOException e) {
                return false;
            }
        } `

README.md has errors in documentation

The headlines in the README.md do not match the actual topic they are describing. In addition throughout the document (and in some comments within the project as well), the RFC3164 has a typo (spelled RFC3613)

RFC 3164 dates with single digit day should pad with ` ` instead of `0`

Actual: Aug 07 16:53:16
Expected: Aug 7 16:53:16

https://tools.ietf.org/html/rfc3164#page-10

4.1.2 HEADER Part of a syslog Packet
...
The TIMESTAMP field is the local time and is in the format of "Mmm dd
   hh:mm:ss" (without the quote marks) where:

         Mmm is the English language abbreviation for the month of the
         year with the first character in uppercase and the other two
         characters in lowercase.  The following are the only acceptable
         values:

         Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

         dd is the day of the month.  If the day of the month is less
         than 10, then it MUST be represented as a space and then the
         number.  For example, the 7th day of August would be
         represented as "Aug  7", with two spaces between the "g" and
         the "7".
...

Log4J2 Configuration is being ignored by com.cloudbees.syslog.sender.TcpSyslogMessageSender

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

Hi,

We're using the syslog library through this maven dep:

       <dependency>
            <groupId>com.cloudbees</groupId>
            <artifactId>syslog-java-client</artifactId>
            <version>1.1.7</version>
            <exclusions>
                <exclusion>
                    <groupId>com.github.spotbugs</groupId>
                    <artifactId>spotbugs-annotations</artifactId>
                </exclusion>
            </exclusions>
       </dependency>

I'm trying to filter out error log writes such as this one:

com.cloudbees.syslog.sender.TcpSyslogMessageSender - INFO: InetAddress of the Syslog Server have changed, create a new connection. Before=null, new=XXXXXXX

But no matter what I add to the log4j2.xml file, this error persists. Here's log4j2 appenders:

        <Logger name="com.cloudbees.syslog" level="OFF" />
        <Logger name="com.cloudbees.syslog.sender.TcpSyslogMessageSender" level="OFF" />

Michael

Reproduction steps

1. add the dep
2. set log appenders to :

        <Logger name="com.cloudbees.syslog" level="OFF" />
        <Logger name="com.cloudbees.syslog.sender.TcpSyslogMessageSender" level="OFF" />

3. try to send a syslog message with a faulty IP
4. see the log still writes the error

Expected Results

No log messages when adding:

        <Logger name="com.cloudbees.syslog" level="OFF" />
        <Logger name="com.cloudbees.syslog.sender.TcpSyslogMessageSender" level="OFF" />

Actual Results

Error log writes appear

Anything else?

No response

Are you interested in contributing a fix?

Sure, can do.

How to set ciphersuite for a SSLContext object?

We are trying to set only those ciphers required for us in client hello , so trying to set ciphers in context object as shown in below code but our changes are not reflecting still client uses default ciphers only, can you suggest ways to set ciphers to context and client should offer only those ciphers in request?
public SSLContext getContext() {
String[] cipherSuites = Arrays.asList("Ciphers");// required Ciphers list
SSLContext context = SSLContext.getInstance("TLSv1.2", "SunJSSE");
context.init(keyManagerFactory.getKeyManagers(), trustMgrFactory.getTrustManagers(),
SecureRandom.getInstance("DEFAULT", provider));
context.getDefaultSSLParameters().setCipherSuites(cipherSuites);
}

TCP/UDP base class/interface

Would it be possible to add an interface or class to the hierarchy so that I could use TCP/UDP interchangeably depending on application settings with the same message sending code? AbstractSyslogMessageSender is close but does not have the 2 properties syslogServerName or syslogServerPort so I have to have 2 complete code blocks that are exactly the same except the type of the message sender being declared.

Does syslog client TcpMessageSender opens connection for each message?

Does syslog client TcpMessageSender supports opening connection with a authorized server once for all instead of opening connection everytimeDoes syslog client TcpMessageSender supports opening connection with a authorized server once for all instead of opening connection everytime

NullPointerException when closing the TCP socket before the first message is sent

Jenkins and plugins versions report

We're using the TcpSyslogMessageSender to send audit logs in the RFC5424 format to a local rsyslog server.

Our service creates an instance of TcpSyslogMessageSender when it starts and begins emitting events once the start-up procedure has been completely successful.

In cases where our service is shutdown before the first audit event is dispatched, we've noticed that the close method on the TcpSyslogMessageSender can throw a null point exception as the socket hasn't been assigned yet and is indeed null at that stage.

There are other parts of this class that leverage com.cloudbees.syslog.util.IoUtils#closeQuietly, which looks like a suitable solution to this issue.

Keen to get your thoughts on this,
Thanks

What Operating System are you using (both controller, and any agents involved in the problem)?

Error happening on a Windows Feature Experience Pack 1000.19053.1000.0

Reproduction steps

1. Create a project using com.cloudbees:syslog-java-client:1.1.7
2. Create an instance of TcpSyslogMessageSender
3. Invoke the close() method on the TcpSyslogMessageSender instance

Expected Results

Not exception to be thrown

Actual Results

Null pointer exception is thrown

Anything else?

No response

Are you interested in contributing a fix?

Happy to contribute and fix this issue if the solution is adequate enough