The Logging Service aims to centralize logs, and offer an interface for consulting and monitoring log applications. It functionalities are exposed as web service and can be deployed in an IOD environment.
The project contains the following parts:
The logging web service is a module integrated into Stardust application as a plug-in containing web page and exposed web service.
Figure: Web Page
WSDL in IOD: https://www.infinity.com/iod1/a/5a666f90-2d2f-469f-b3ef-38b54eba0986/services/soap/LoggingServiceHttpBasicAuth?wsdl
| Method | Parameters | Result |
|---|---|---|
| addLogEntry | LogEntry logEntry | Void |
| addLogEntryList | List | Void |
| findLogEntries |
|
List |
| Attribute | Type | Description |
|---|---|---|
| systemGuid | String | The system guid |
| systemName | String | The system name |
| timestamp | Date | Date of the log entry |
| hierarchyIndicator | Int |
The log tree is composed by three levels :
|
| businessCaseGuid | String | The business case guid |
| drillDownUri | String | URI |
| tags | Map | Each log entry may accept a non determinate number of tags (key/value), which can be visualized when pointing the document icon. |
| duration | String | The duration column is calculated based on the time between LogEntry.IN and LogEntry.OUT |
| Message | String | The log message |
| Level | Enumeration |
The log level can Be
|
The ws client contains 2 packages, one contains web service and its configuration like wsdl location and jaxb object, and the other contain a Junit class to show developer how to use web service.
The following example shows how to call the logging web service through camel route. A JMS message is intercept in the queue and a camel interceptor will route the message and call the logging web service through callLoggingWS (call the web service and log into the application).
from("activemq:queue:test.queue").convertBodyTo(String.class).process(new Processor() {
public void process(Exchange e) {
LoggingServiceClient logServiceClient = new LoggingServiceClient();
logServiceClient.callLoggingWS(e.getIn().getBody());
}
The message describing the log is based on csv notation as following: SystemGuid,SystemName,ServiceName,Timestamp,HierarchyIndicator,BusinessCaseGuid,DrillDownUri,message,level,key_1=value_1,...,key_n=value_n
31babc6e-5be9-452d-817d-9cf03aa16997,IPP,Process C,1315663200000,1,d2496f47-f8e7-4ce4-b61d-3d0868d4a49b10,http://localhost:8080/bla,trade=4711,counterparty=Bla
The client interceptor for Stardust is an Event Handler which uploads logs via the Logging web service. The camel route intercepts the message from an endpoint (file, jms, etc.) and routes it to the LoggingProcess using Camel IPPConnector. The content of the message is passed to the process, the process will parse the message and call the logging web service using the addLogEntry method.
Figure: Logging Process
The following figure represents the logging process history
Figure: Process History
<route>
<from uri="file://C:/temp/incomingLogs?delete=true" />
<setHeader headerName="ippProcessId">
<constant>LoggingProcess</constant>
</setHeader>
<setHeader headerName="ippUser">
<constant>motu</constant>
</setHeader>
<setHeader headerName="ippPassword">
<constant>motu</constant>
</setHeader>
<convertBodyTo type="java.lang.String" />
<to uri="ipp:authenticate:setCurrent"/>
<to uri="ipp:process:start?data=LogContents::${body}" />
</route>
Logs are being persisted into a database in the following table.
-- Create table create table LOG_SERVICE_ENTRIES ( SYSTEM_NAME varchar2(2000), SERVICE_NAME varchar2(2000), SYSTEM_GUID varchar2(2000), BUSINESS_CASE_GUID varchar2(2000), DRILL_DOWN_URI varchar2(2000), TAGS varchar2(2000), HIERARCHYINDICATOR number, LOG_DATE timestamp(6), LEVEL varchar2(10), MESSAGE varchar2(4000) )
Figure: Log Service entries
The search can be performed by start time, end time, business Case Guid, Tag name and Tag value, and ability to search with any number of parameters.
Example of search by start time, end time, business Case Guid :
Figure: Search screen
The log duration is calculated based on the time between LogEntry.IN and LogEntry.OUT. The duration is displayed in this format hh:mm:ss:SSS
Figure: Calculate duration
The following example shows how some data are masked when displaying the LogEntries in the table:
In the following example we are masking the social security number (ssn) tag.
Figure: Mask Some Tag
The log statistics screens shows the occurrence number for a logEntry defined by "systemName" and "serviceName".
In the figure below, logs generated by System B/Service W occurred 3 times.
Figure: Log statistics screen
The occurrence number is a link, once clicked we get all logEntries having (system B, Service W), see following screen.
Figure: Log search screen
The application offers the user the possibility to repair a Log list in case a log.IN or log.OUT is missing. The added logs can be persisted.
Knowing that the logs are grouped by bloc and each bloc have a Log.IN and a Log.OUT, the problem that can occure during application crash is that a Log will lose it's Log.IN or Log.OUT.
So : In order to repair, user has to select the broken Log and choose which type of log (IN or OUT) to insert.
As we can see in the figure below, the Log defined by (System D1, Service Z1) has a missing Log.IN
Figure:Log repair initial screen
To repair this log, user has to click on repair icon that will display a popup panel asking user to choose the log type to insert.
Figure: log adding log.in
Once the user has validated his request, the application update the log tree by adding an internal log. This log, as show in the figure "log.in added" has an icon (delete), this will offer the possibility to the user to delete it.
We can notice that the added log is displayed as a parent of the repaired log
Figure:log.in added
After repairing the log tree, the user has the ability to persist the new logs, to do so, user has to click on persist Internal Logs button.
Figure:Persisting logs
Once persisted, the log's delete icon is removed.
In the previouse example we have corrected the unit log by adding a Log.in, by the same way we can correct an unit log missing a Log.out
User can repair multiple log in same time and can persiste more than one log in one operation.
The message column in the data table has a maximun size (N), once it is exceeded the N characters are append by "..." and a tooltip is available to show the entire message.
Figure:message tooltip
The logging service offers the ability to any client to use log4j or slf4j, by including the infinity WebService Appender. This appender allows the communication between any client using log4j and the logging service.
How to configure and use Log4J property file to benefit from ipp logging service and initializing the Service parameters (systemName, serviceName and businessCaseGuid):
log4j.rootCategory = INFO, default, console, WS .... #Infinity web service appender log4j.appender.WS=com.infinity.log4j.databaseappender.WSAppender #Declaring systemName,serviceName and businessCaseGuid parameters. log4j.appender.WS.systemName=SystNameFromLog4j log4j.appender.WS.serviceName=ServiceLog4j log4j.appender.WS.businessCaseGuid=abc-Log4j-java-client
Other than using properties files to initialize service parameters, the web Service Appender support the use of MDC to dynamically initialize the SystemName, ServiceName and the guid from any java client.
MDC.put("systemName","IPP");
MDC.put("serviceName","Service Name");
MDC.put("businessCaseGuid","abc-xyz-java-client");
If the client does not use MDC to override the parameters defined in log4j properties file, the logging service will use the values as defined in the Log4J.properties.
The service offers user the aiblility to purge logs, by choosing the date, all logs till the choosed date will be removed.
Figure:Logs Purge
The service is successfully deployed in IOD and the plugin and WS are accessible through this URL
Plug-in: https://www.infinity.com/iod1/a/5a666f90-2d2f-469f-b3ef-38b54eba0986/plugins/common/main.iface