LogPoint Normalisers are largely provided for specific devices and applications. Depending on the device’s log format, the normalisers are either standard or compiled normalisers - compiled normalisers offer better performance than standard normalisers for high-volume log sources and can support more complex formats.

In addition, there are some normalisers for generic data formats - namely JSON, XML, CEF and LEEF. That usually means that we can ingest key/value pairs, but as the key names are provided by the log format itself, they wouldn’t follow the LogPoint taxonomy. Therefore, for specific devices we might have specific XML, CEF etc. normalisers too.

I’m not sure where a stack trace would fit with LogPoint however. LogPoint is tailored towards structured data analysis, i.e. aggregations and correlations of data. Not sure what the use case would be for a stack trace.

For any log ingestion there are two steps:

1. Receive/Retrieve the log somehow
2. Normalise the log

For step a), there are fetchers and collectors. The most common way of getting logs into LogPoint are either receiving Syslog message, or collecting files - the latter through the LogPoint agent, SCP, FTP, CIFS etc.

For step b), you would apply a normalisation policy, selecting the correct normaliser.

Hi,

Thanks,

well, we are planning to use logpoint as a log management system and ship logs from our servers and applications there so they are stored in a secure manner and can be searched and analysed (automatically via reports or manually by support personnel).
The typical Jboss log would look like this:
-------
2021-06-18 13:01:39,064 INFO  �Owasp.CsrfGuard] CsrfGuard analyzing request /xxxx/CSI.ajax
2021-06-18 13:01:39,081 INFO  �se.marakanda.mutil.persistence.hibernate.SessionUtil] HibernateSessionFactory closed a hibernate session. ThreadID: 184
2021-06-18 13:01:39,081 ERROR Rorg.apache.catalina.core.ContainerBase.ejboss.web].]localhost].[/].]AjaxServlet]] Servlet.service() for servlet AjaxServlet threw exception
java.lang.RuntimeException: Unknown exception caught in com.ebuilder.xxxx.business.admin.AdminDelegate
        at se.marakanda.mutil.business.BaseDelegate.handleError(BaseDelegate.java:177)
        xxxxxxxxxxx
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
        at se.marakanda.mutil.access.ValidationHelper.handleError(ValidationHelper.java:156)
        xxxxxxxxxxxxx        at com.ebuilder.xxxx.business.admin.AdminDelegate.getSubscriptions(AdminDelegate.java:1035)
        ... 39 more
2021-06-18 13:01:41,902 INFO  2se.marakanda.jboss.LoginContextValve] Charactor encoding does not set
2021-06-18 13:01:41,902 INFO  >Owasp.CsrfGuard] CsrfGuard analyzing request /logout.do
2021-06-18 13:01:41,903 INFO  /STDOUT] logout: xxx - 641592
2021-06-18 13:01:41,963 INFO   se.marakanda.jboss.LoginContextValve] Charactor encoding does not set
----------------
Logs from Tomcat are similar 
----------------
25-May-2021 02:01:14.057 INFO bmain] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler c"ajp-nio-8009"]
25-May-2021 02:01:14.061 INFO bmain] org.apache.catalina.startup.Catalina.start Server startup in 8073 ms
26-May-2021 00:00:12.315 INFO bhttp-nio-8080-exec-10] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
        at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:463)
        xxxxxxxxxxxxx
        at java.lang.Thread.run(Thread.java:748)
26-May-2021 00:00:16.299 INFO ehttp-nio-8080-exec-3] org.apache.tomcat.util.http.parser.Cookie.logInvalidHeader A cookie header was received ikey="key" type="System.Data.Services.Internal.ExpandedWrapper`2="System.Web.UI.ObjectStateFormatter, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a],uxxxxxxxxxxxxx] that contained an invalid cookie. That cookie will be ignored.Note: further occurrences of this error will be logged at DEBUG level.
26-May-2021 00:00:40.340 INFO http-nio-8080-exec-9] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
--------------
I can send these logs to Logpoint via NXLog and preserve all the line breaks and indentations.
But logpoint either will strip out all the line breaks or will split the multiline mesage into multiple individual log records (one line will be an individual log records).

I would want to be able to see the ERROR mesage from Jboss and  the Exception message from Tomcat as one message in Logpoint with preserved line breaks and indentations,

I want to see them "as is", in the same format as I sent them. The logs need to be readable.
Is it doable?

How?
Are the plans to support multiline logs "out of the box" in logpoint ?

Hi @24Solutions Support,

having the exact same requirement (using lp for log management) and java exceptions in the logs, I wonder if you eventually found a way of resolving this. As syslog runs line-based, one idea would be to change the tomcat/jboss logging to support this. 

I had asked ChatGPT for its input and it came up with following suggestion (I did not validate so far), which takes me to the next question, ie. if the normalizer package “LP_Apache Tomcat” would still work or if we would need to define custom normalization packages.

Yes, it is possible to configure the logging of a Tomcat server to output logs in a single line, including stack traces for exceptions, so that they can be shipped to a central log management server via syslog.

To do this, you would need to configure the logging properties of Tomcat. Specifically, you would need to set the org.apache.catalina.util.LifecycleBase logger to output logs in a single line, and then configure syslog to capture these logs and send them to your central log management server.

Here's an example of how you might configure Tomcat's logging properties:

1. Open the logging.properties file in the conf directory of your Tomcat installation.

2. Add the following line to the file:

   code

   org.apache.catalina.util.LifecycleBase.level = INFO org.apache.catalina.util.LifecycleBase.handlers = org.apache.juli.SyslogHandler org.apache.catalina.util.LifecycleBase.useParentHandlers = false org.apache.juli.SyslogHandler.level = ALL org.apache.juli.SyslogHandler.facility = LOCAL0 org.apache.juli.SyslogHandler.ident = tomcat org.apache.juli.SyslogHandler.useFormat = true org.apache.juli.SyslogHandler.useLogMsgFormat = true org.apache.juli.SyslogHandler.logMsgFormat = %msg% %n% %throwable{short} org.apache.juli.SyslogHandler.encoding = UTF-8

   This configures the org.apache.catalina.util.LifecycleBase logger to output logs in a single line, including stack traces for exceptions. It also configures the logger to use the SyslogHandler for output, and sets the handler's format and encoding.

3. Save the logging.properties file and restart Tomcat.

Once Tomcat is running with this configuration, its logs should be output in a single line with stack traces for exceptions, and syslog should be capturing these logs and sending them to your central log management server.

Kind regards,

Peter