Service log

The Conversion Service writes verbose information to a log file (or to the standard output in the case of Docker container). This allows the administrator to monitor the service's operation and troubleshoot problems after an event.

Location of the log file

Windows

The location of the standard log files can be configured using the Service configuration. The name of the log files is ConversionService-Service.log. After each day, the old log file is compressed and moved to the file ConversionService-Service-yyyy-mm-dd.log.zip. A maximum of 90 archived log files are kept.

Docker

The file containing all log entries is /var/log/convsrv/ConversionService-Service.log. This log file is primarily designed for support issues.

Example: See all critical errors that occurred in container ‹CONTAINER›

docker exec ‹CONTAINER› grep -e ",ERROR\|FATAL," /var/log/(*@\ctxDockerFolder @*)/(*@\ctxServiceShortName @*)-Service.log

Log properties

In addition to standard properties, log entries contain the following:

Property	Description
Level	Severity of the message. See Severity level.
Process name	The name or type of the process in which the log event occurred.
Message	The log message.
Exception	Critical log messages often have an exception associated that contains more detailed information on the message's cause.
Job ID	Using the job ID, all messages of a particular processing job can be filtered for analysis.
Task ID	This is an internal ID used by the service, which is useful for analysis by Pdftools Support team.
Remote ID	The IP address of the remote host (client). This is meaningful only for messages that are associated with a request at the REST API.

Severity level

The level indicates the severity of the message. The following severities are common:

Level	Description
Fatal	Severe error. See Error below.
Error	Error that prevents the service from operating, e.g. because of an incomplete installation or invalid configuration. Clients sending processing requests to the service receive an error code internal or configuration. It is recommended that the service administrator be notified whenever a message of severity level Error or higher occurs. This can be achieved by monitoring the standard service log file or creating a custom log.
Warn	Errors that are not critical and do not prevent the service from operating. Even though no immediate action by the service administrator is required, it is advisable to review warnings periodically and decide if an action is required.
Info	Informational events are useful to monitor the service's operation.
Debug	Debug and tracing messages are strictly for development purposes and analysis by the Pdftools Support team. During productive use of the service, messages of this level should be disabled for performance reasons.
Trace	See Debug above.

Reading the log file

The standard log file is in CSV format, which can be opened in several applications. Many of them offer a tabular view of CSV files, highlighting by log message severity, and filtering.

Custom logs

Windows

For logging, the Conversion Service uses NLog, a very flexible logging platform. This allows to create additional log outputs. For example, to write to a database or the Windows Event Log.

Layout renderers

The following additional layout renderers are available in the Conversion Service:

• ${gdc:processName}: Process name
• ${mdlc:jobId}: Job ID
• ${mdlc:taskId}: Task ID
• ${mdlc:remote-ip}: Remote IP

For more information on these properties, see Log properties.

Examples of layout renderers

To add a new log output, a file NLog.config can be created in the directory bin of the installation directory. For more information, see NLog documentation.

note

A new logging configuration can be tested by disabling the Conversion Service's license in the license manager. When the service is restarted and a job scheduled, an error is logged.

More information on logging configuration issues can be obtained by activating internal logging:

<nlog internalLogLevel="Info"
      internalLogFile="c:\path\to\nloglog.txt"
      ...

Example: A NLog.config that generates a log file C:\path\to\mylog.log

<?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<targets>
  <target name="mylog" xsi:type="File" fileName="C:/path/to/mylog.log">
    <layout xsi:type="CsvLayout" delimiter="Comma" withHeader="true">
      <column name="time" layout="${longdate}" />
      <column name="level" layout="${level:upperCase=true}"/>
      <column name="processName" layout="${gdc:processName}" />
      <column name="message" layout="${replace-newlines:${message}}" />
      <column name="exception" layout="${replace-newlines:${exception:format=ShortType,Message
                                         :innerFormat=ShortType,Message:maxInnerExceptionLevel=1}}"/>
      <column name="jobId" layout="${mdlc:job-id}"/>
      <column name="taskId" layout="${mdlc:task-id}"/>
       <column name="remoteIp" layout="${mdlc:remote-ip}"/>
    </layout>
  </target>
</targets>

<rules>
  <logger name="*" minlevel="Info" writeTo="mylog" />
</rules>

</nlog>

Example: A NLog.config that writes critical messages to the Windows Event Log

<?xml version="1.0" encoding="utf-8"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <extensions>
   <add assembly="NLog.WindowsEventLog"/>
  </extensions>

  <targets>
  <target name="eventlog" xsi:type="EventLog"
          source="(*@\ctxServiceShortName @*)"
          layout="${message}${newline}Process name: ${gdc:processName}${newline}Job ID: ${mdlc:job-id}${newline}Task ID: ${mdlc:task-id}${newline}${exception:format=ToString}"
           />
  </targets>

  <rules>
    <logger name="*" minlevel="Error" writeTo="eventlog" />
  </rules>

</nlog>

Example: A NLog.config that sends critical messages by email

<?xml version="1.0" encoding="utf-8"?>
  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <extensions>
      <add assembly="NLog.MailKit"/>
    </extensions>

  <targets>
     <target name="maillog" xsi:type="Mail"
             subject="(*@Conversion Service @*) Error: ${message}"
             body="${message}${newline}Process name: ${gdc:processName}${newline}Job ID: ${mdlc:job-id}${newline}Task ID: ${mdlc:task-id}${newline}${exception:format=ToString}"
             to="admin@example.com"
             from="system@example.com"
             smtpUserName="user"
             smtpPassword="password"
             smtpServer="smtp.example.com"
             smtpPort="587"
             smtpAuthentication="Basic"
             secureSocketOption="StartTls"
             />
   </targets>

   <rules>
     <logger name="*" minlevel="Error" writeTo="maillog" />
   </rules>

 </nlog>

Docker

For logging, the Conversion Service uses NLog, a very flexible logging platform. This allows to create additional log outputs. For example, to write to Amazon CloudWatch or Google Cloud Platform Logs.

Creating a support request using the service logs

When you create a support request, you need to provide Pdftools Support with information to effectively evaluate and troubleshoot your support case.

You can automatically export the service logs and other information using the Configurator. The Support Request tab in the Configurator lets you generate a ZIP file ("SupportRequestFiles") in your local machine that you can attach to your support request. The ZIP file contains data such as active workflows, jobs recently performed by the service, service log files, and service debug log files that help us to identify the origin of your issue, and perform troubleshooting.

To generate the ZIP file with all the required information, activate the Support Data toggle.

You can also choose to share analytics to help improve the product. Pdftools does not track any of the data of your Conversion Service implementation. Analytics are only used for the purposes of improving your experience with the Conversion Service. The exported analytics ZIP file contains statistics on the workflows and profiles used, the number of output files and their size, and the number of pages in each output file. No information that can be used to identify the contents of the documents you process is collected. All analytics are stored in your local machine.
You can choose to include analytics data when you create the ZIP file for your support request by activating the Analytics data toggle.

When you click Export, a window opens where you can choose where to save the exported file. You must attach this file to your support request.

Support Data Collection

We collect specific data from your system to help us diagnose and address your issues more effectively. This collection is vital for us to provide you with the best possible support. Our commitment is to maintain transparency with our enterprise clients about the data we access.

Data We Collect:

1. Event Logs in the Last 24h: This helps us understand any recent system or application events that might have contributed to the issue you're facing.
2. Software Versions:
   • Conversion Service: Helps us determine if any known issues exist with your current version.
   • Office: Assists in diagnosing potential compatibility or integration issues.
3. Win32 Tables:
   • UserAccount, LogonSession, LoggedOnUser: Provides insights into user accounts, their sessions, and logon activities.
   • Group, GroupUser: Details about user groups and their members, crucial for understanding access and permissions.
   • Service: Information about running services, which can highlight conflicts or dependencies.
   • Printer, PrinterDriver: Essential for understanding the PDF generation process. When creating PDFs from Excel spreadsheets, Excel uses the Windows printing system, making printer settings and drivers crucial for successful conversion.
   • QuickFixEngineering: Information on recent patches or fixes applied to the system.
   • GPO Information: Extracts rights for all Users and Groups, assisting in understanding policy-related issues.
   • OperatingSystem: Details of the OS, which can help in understanding compatibility or known issues.
   • ComputerSystem: Information about the computer's hardware and configuration.
   • Processor: Helps diagnose performance or compatibility issues.
   • LogicalDisk: Information on storage, which can aid in understanding space-related issues.
   • DCOMApplication, DCOMApplicationSetting: Provides insights into distributed component settings and potential conflicts.
4. Conversion Service Product Configuration:
   • appsettings.json: Configuration settings that might be causing issues.
   • Workflows.xml: Workflow configurations that could lead to operational problems.
   • Backups of old Workflows.xml: Historical configurations to compare and trace the origin of issues.
5. Log Files (from the Conversion Service): Detailed logs can highlight errors, warnings, or unusual behaviors.
6. Report Files (from the Conversion Service): Generated reports can provide context on the tasks or processes that were running when an issue occurred.

All the data collected is strictly used for support and diagnostic purposes. We ensure that every piece of information is treated with the highest standards of confidentiality and security. Transmitting this data allows our support team to understand the context better and pinpoint the root causes of issues, ensuring efficient resolution.

We understand and respect the importance of your data's privacy and integrity. All data is securely transmitted, and we adhere to rigorous data protection standards to ensure the safety of your information.

For any concerns or further questions about our data collection practices, please contact our support team or review our comprehensive privacy policy.