How to configure Debug Logging for Terminal Adapter Activities

[juacosta]

Everyone,

I need to troubleshoot some connection issues I am seeing using the PO Terminal Target to connect to a Nexus Network Device(5K & 7K).  I need to know if there is a way to only set Debug logging for the Terminal Adapter such that I can only capture details for all Terminal activities and not the entire PO Server.

All the help will be gladly appreciated

--Juan

[Shaun Roberts]

You need to go into the Tidal.Automation.Server.Exe.Config file located in the main directory where CPO is installed. Look for the logging section and change

Level="Error" to Level="Debug" and restart the CPO service.

Should look like this (in the file):

Logging

    directorypath="C:\Windows\system32\config\systemprofile\AppData\Local\Cisco\Cisco Process Orchestrator\"

    FileNameBase="Tidal.Automation.Server"

    MaxFileSizeMB=""

    InitialSeconds=""

    NumberOfBackups=""

    WriteAssemblyName=""

    WriteMethodName=""

    Level="Debug"

    Enabled="true"

    ShareDirectory="true" />

--Shaun

[juacosta]

Shaun,

Thanks a lot for the quick response. The process you mentioned is the one I follow to turn the entire PO Server logging into Debug mode. I want to know if there is a procedure to only turn on Debug logging for the "Terminal Target Adapter" similarly to how it is done for the Web Target Adapter.

--Juan

[Shaun Roberts]

Well since that adapter is java it is built off TES AHF and such(or at least in the same model). In TES there was a .props file per java adapter that could control logging levels and CPO has a service.props built for each java adapter too. Looking at the one for Terminal Adapter though, all those logging levels are commented out, so I'm not sure even if you uncommented and changed them that they would work.

The web services adapter would be unique because it's fully .net and can have additional configuration added. Terminal adapter is a java based adapter and works through the Adapter Host Framework.

Svetlana or one of the dev would have to comment if this is even possible with the service.props file config, as I don't know if it is.

Is there a major issue in turning debug on for the server? You have to restart either way and the logs don't take up more room than non-debug, they just roll faster.

[juacosta]

Shaun,

The concern is to enable Debug tracing for things we are not trying to trouble shoot adding unecessary overhead to the server and we do not want to be consumming more CPU, Memory and disk space than necessary. Specialliy since the issue we are tracking is some what intermitent. The other aspect we are troubleshooting on the customer pre-production environment an the environment is as restricted as production.

--Juan

[Svetlana Kryukova]

Hi, Juan!

I am curious what kind of issues you are seeing in using the Terminal adapter. The additional debug logging may not provide you with information you are looking for. The exceptions (errors) and output should be captured for the individual activity instances and will probably provide enough information to trouble shoot.

There is no easy way to enable debug logging JUST for a single adapter, and as Shaun pointed out disk is not an issue. Logs are limited in size, and so debug logs won't take more space or memory. CPU impact might be of a concern if you are trying to do scalability/performance testing and I wouldn't recommend leaving logging at Debug level for ever, but it should be acceptable for short time.

Svetlana

[juacosta]

Svetlana,

Thanks for responding. The situation we are facing is somthing intermitent and we do not have a pattern identified to repro consistently but we have some synthoms that indicate the problem will occur.

The issue is that some times any SSH connect attmpts to either the Nexus 5K or 7K times outs when the Terminal "Open Session" activity executes. However using straight an SSH client or Putty the connection immediatelly connects.

We have reviewd the network device syslog and the TACACs server that runs authentication for the devices and in no case there are either failed attempts or connection rejects.

However, some times ( but  not all the times) we have seen ligering connections on the device and definitely we have seen some Sockets(Port 22) at the PO  Server in LISENTING state when there is no active SSH connections to the network device.

My goal with debug tracing of the adapter is to be able to trace step by step from connetions stablishment to connection teardown and be able to match up with the device connection traces in the syslog and be able to pair lingering connections to initiated connections in PO.

Since this happens over time I need to have Debug logging available all the time for that piece of functionality until we encounter a new instance of the issu and we can root cause the issue.