Organizing Logging Between the Three IBM App Connect Form Factors

The App Connect product enables you to integrate anything to anything. Its core routing and transformation engine enables you to inspect and transform messages from a wide variety of industry-standard and custom message models. But with great power can come complexity! Being generic and having the ability to run your integration flows on different form factors can give you a lot of options. This article aims to help you coordinate your logging strategy across these different form factors and to clarify where and how you can get access to the more common form of logging across all the form factors. 

Form Factors

The App Connect runtime runs on 3 distinct form factors, all capable of running BAR files containing Integration Flows. These BARs can be moved between each form factor. You can create a BAR file using the ACE Toolkit or the App Connect Designer UI.

1. App Connect Enterprise (ACE)

This is a single runtime that can be administered by connecting to the WebUI port (default: 7600). Generally, it runs on Virtual Machines and servers so the complete environment is visible to an administrator, but visibility and actions can be restricted for individual users.

2. App Connect Enterprise Certified Container (ACEcc)

These are multiple ACE runtimes running in k8s pods so they cannot connect directly to all at once for administration. They are configured using an IntegrationRuntime Custom Resource, which is used by the App Connect Operator in a k8s environment to create runtime objects. All pods are visible by the k8s administrator and standard RBAC rules can be applied. Extra configuration can be provided to supply extra server.conf.yaml settings, for example.

3. App Connect iPaaS (ACEaaS)

As with ACEcc, ACEaaS is orchestrated in a k8s environment, but this environment is more restricted with no direct visibility of the k8s pods. All logs need to be output to the IntegrationRuntime's console log and then they can be scraped into a Prometheus log storage which is queried and viewed in the ACEaaS Log viewer. This can be configured in the same way as the ACEcc runtime using configurations.

Logging

Logging has a level of verboseness, ranging from very verbose Service Trace to User Trace and then to a more succinct user-focused Activity Log. All this logging can be turned on and off, as there can be a performance impact to it, as there is within any integration runtime.

Logging Nodes

These are nodes that are used exclusively to output user-defined log messages. They can be customized to output to various locations and can contain information from the flow runs. For example:

	ACE	ACEcc	ACEaaS
ACELog Node (Created in the ACE Toolkit)	Outputs to the ActivityLog Viewable by default in the ACE web ui which shows the in-memory ActivityLog; but ActivityLog can cope with one too many additional loggers at once with output to a wide variety of locations if needed. Can be ERROR, INFO, or DEBUG tagged but one thing to note is that debug logs are not output by default for performance reasons as they are expected to be more verbose. The minSeverityLevel needs to be set to DEBUG in the server.conf.yaml for the ResourceManagers ActivityLog to make these appear: ResourceManagers:   ActivityLogManager:     minSeverityLevel: 'DEBUG'	Outputs to the ActivityLog. This is viewable in the App Connect Dashboard via the servers and drilling down to the individual pod replicas message flow level. E.g., Dashboard/Servers/Server: ir-01-acelog/Replicas/Server: ir-01-acelog/Applications/Application: ACELog/Message flows Can be ERROR, INFO, or DEBUG tagged but one thing to note is that debug logs are not output by default for performance reasons as they are expected to be more verbose.  The minSeverityLevel needs to be set to DEBUG in the server.conf.yaml for the ResourceManagers ActivityLog to make these appear: ResourceManagers:   ActivityLogManager:     minSeverityLevel: 'DEBUG' These can also be redirected to the IntegrationRuntime pod console log with the following server.conf.yaml, this snippet also outputs the DEBUG level: ActivityLog: MyLoggingConfiguration:     filter: TYPE=LOG     consoleLog: true   consoleLogFormat: 'text' minSeverityLevel: 'DEBUG' NB. Removing the filter will send ALL ActivityLog to the console.	Outputs to the ActivityLog This is viewable in the Logs: Can be ERROR, INFO, or DEBUG tagged but one thing to note is that debug logs are not output by default for performance reasons as they are expected to be more verbose. You need to specify the following in your IntegrationRuntime server.conf.yaml for this to appear in the activity log. This then gets visualized in the logs view: ActivityLog:  MyLoggingConfiguration:     filter: TYPE=LOG     consoleLog: true   consoleLogFormat: 'ibmjson' NB. Removing the filter will send ALL ActivityLog to the console and you need ACE 12.0.12.3 or above for this functionality. The minSeverityLevel needs to be set to DEBUG in the server.conf.yaml for the ResourceManagers ActivityLog to make debug entries these appear: ResourceManagers:   ActivityLogManager:     minSeverityLevel: 'DEBUG' NB. For debug you need ACE 12.0.12.5 or above for this functionality.
Designer Log Node  (Created in Designer Authoring)	N/A	Outputs to the designer-flows container console log To view debug, you need to set SINGLE_TENANT_USER_TRACE = debug on the designerflows container in the IntegrationRuntime spec: spec:   template:     spec:       containers:         - name: designerflows           env:             - name: 'SINGLE_TENANT_USER_TRACE'             value: 'debug' or from 12.0.12.5 you can set the following: The minSeverityLevel needs to be set to DEBUG in the server.conf.yaml for the ResourceManagers ActivityLog to make these appear: ResourceManagers:   ActivityLogManager:     minSeverityLevel: 'DEBUG'	Outputs to the designer-flows pod console log This can be viewed in the ACEaaS Log viewer. The minSeverityLevel needs to be set to DEBUG in the server.conf.yaml for the ResourceManagers ActivityLog to make these appear: ResourceManagers:   ActivityLogManager:     minSeverityLevel: 'DEBUG' NB. For debug you need ACE 12.0.12.5 or above for this functionality.
Trace Node (Created in the ACE Toolkit)	Outputs to either User Trace (See User Trace section below on how to retrieve), File, or Local Error Log (console log)	Outputs to User Trace (retrieved through the Dashboard UI), File, or Local Error Log (console log)	Output to User Trace and then can be retrieved through the Dashboard UI as with ACEcc

Tracing

Tracing the integration flows allows you to see what path any messages have taken through your flow and can be very verbose like service trace (normally only to investigate any product issues) or less verbose like user trace.

ActivityLog

The ActivityLog can be viewed in ACE and ACEcc in the admin UI. (For ACEcc, you need to specify a specific replica to be able to view this). This is stored in memory but can be configured in the server.conf.yaml to output to several places all in parallel, ranging from file to an ELK stack, for example. You can consolidate the view in ACEcc or ACEaaS by sending the output to the console.

For ACEcc there is also the consideration of your k8s RBACs, the Dashboard and Designer here run as a single user.

More details on configuring the ActivityLog output are here.

There are a large number of ActivityLog types that can be found in the Activity log structure and types documentation. For example, the CICS ActivityLog: 

They can all be configured to output across all three of the App Connect form factors by using the ActivityLog stanza in the ACE runtime server.conf.yaml.

The 'ActivityLogTemplate' name can be anything you want, and you can then configure the filter to output what you want; for example, filter: RM=CICS;RM=JMS to output the CICS and JMS ActivityLog to a specific location. As mentioned in the table above, to see these entries in ACEcc or ACEaaS, you then need to specify consoleLog: true and consoleLogFormat: 'ibmjson' so that the entries are output to the console. For ACEaaS these can then be viewed in the Logs view.

Advanced Tracing Links 

• App Connect Enterprise component level tracing
• Switch Server tracing

Conclusion

The granularity of logging and tracing is very customizable within the App Connect product, so this can make it complex to get to the exact logging you require. We have tried to make the common flow logging as accessible as possible with the Activity Log being a common factor, but we are constantly looking to improve the useability of App Connect in all our 3 form factors.

If there is anything you would like to see improved, please raise a request for a feature improvement.