Can the System Event Publisher be used in place of logging to the TM Database? i.e. in busy environments would it be possible to configure it so that debug logging went exclusively to Splunk or AWS without ever creating a record in the TM database?
This is an old thread but we had the same requirement and the same approach was recommended by our Temenos support person. We tried this but still groovy logs are not getting pushed to server.log file on our Linux platform. We updated the standalone.xml (single node environment) and restarted the JM instance.
Hello @Kalpesh Verma,
Thanks for submitting your question.
A couple of things:
1. Make sure that the Groovy ERROR log is actually logged in the JM, Services/GroovyLogs
2. To see if that line of the config read by the system at all or not,
- could you set it to DEBUG or INFO and see if you get those levels.
3. Could you attach the full standalone.xml and the server.log file?
4. Could you try WARN ?
I presume you are referring to Groovy Service Log Data in this questions, e.g. DEBUG and INFO messages recorded using the logger in Groovy Services.
The GroovyLogger class internally has a SLF/Log4J logger which logs messages to the TM service.log file. The Log4J level for this service is configured in the standalone.xml configuration file. The default logging level is ERROR, which means DEBUG, INFO and WARN messages are not logged to disk. The reason for this default setting is to prevent PII data being logged to disk.
If this is configured to INFO or DEBUG level then GroovyLogger statements at those levels will be logged to the server.log file. From here they can be feed into Splunk or other log management systems, regardless of the TM Groovy Service Logging configurations for the database.
With regard to the System Event Publisher can feed Groovy Service Log Data message to an AWS SQS endpoint to support integration with other log management systems without having to write PII data to disk. The Groovy Service Log Data messages will include the same content as would be included in the TM Groovy Service Log Data records, so it cannot be used as a complete substitute to the TM Groovy Service Log records.