Debug Log Configuration

Web-based Configuration

The form in the monitor administration web page contains a DebugLog monitor type for FlexNet Publisher an AltiumLog monitor type for the Altium License Manager and a CodeMeterLog monitor type for the CodeMeter License Manager those are used to specify a single debug log for a specific tag:


Figure 1. Stand-alone Monitoring

For situations where multiple debug logs exist for a single tag, use the file-based configuration method below.

Optionally, for FlexNet Publisher, usage information can be acquired in addition to denial information by checking the box for this functionality. This feature is currently considered experimental as Altair Accelerator continues to improve the handling of corrupt and incomplete data commonly found in debug logs. Altium and CodeMeter debug logs only contain usage information, so denials are not supported.

File-based Configuration

To enable stand-alone FlexNet Publisher or DSLS debug log parsing, use one of the following configuration procedures:

These procedures must be written into the licmon.swd/vovlmd/config.tcl file. Repeat for specifying multiple debug logs for triads. Supply the license server host name that generated each log using the -host argument. Also repeat for specifying multiple debug logs that are the result of multiple daemons being served on the same tag that each have their own debug log.

Optionally, checkout information can be acquired in addition to denial information by adding the -checkouts option. This feature is currently considered experimental as Altair Accelerator continues to improve the handling of corrupt and incomplete data commonly found in debug logs.

For Altium usage monitoring, use the add_ALTIM_LOG procedure in the licmon.swd/vovlmd/config.tcl file.

For CodeMeter usage monitoring, use the add_CODEMETER_LOG procedure in the licmon.swd/vovlmd/config.tcl file.

Debug Log Specification

For both the joint and stand-alone monitoring methods described above, the debug log can be specificied in the following formats:
  • /path/to/file (for static logs)
  • /path/to/file.@DATE@.log (for rotated logs)
  • /path/to/file.@LATEST@.log (for rotated logs)

The first option is a simple path to the debug log and is typically used when a static debug log is being parsed. As stated above, a static debug log is not rotated on any basis and normally contains data for multiple days. In order to be parsed correctly, the file must contain TIMESTAMP lines. The file can be named something as simple as debug.log, in which case data tracking will begin upon the first TIMESTAMP line encountered. This ensures that the records will be applied to the correct day and time. The filename can also contain the start date for the data, such as debug.20100101.log. If a date is found in the filename in the format of YYYYMMDD, it will be used as the initial day and time instead of requiring the parser to find it in the debug log data itself. The drawback to using a dated filename with the static method is that the monitor configuration must be updated if the debug log file name is changed.

The second option utilizes the @DATE@keyword, which is substituted with the current date, in YYYYMMDD format, at parsing time. This is required when the debug log is created using the rotation method. The rotation method results in a debug log for each day, named in the aforementioned format. Rotation is required if the debug log does not contain TIMESTAMP lines.

The third option utilizes the @LATEST@keyword, which causes the parser to search for the latest file found based on its name. The file name must contain its creation date, in YYYYMMDD format. This is required mainly for Altium logs, which are rotated at a static rate that is less than daily.

Time Zones

When monitoring a debug log that was written by a license server located in a time zone that differs from the time zone in which the Monitor server is running, the remote time zone must be properly specified. Otherwise, denial events will not be synchronized with the capacity and utilization data that is coming from sampling. The remote time zone can be specified with both the web interface and the configuration file, via the -tz argument to add_LM_LICENSE_FILE, add_DEBUG_LOG, and add_ALTIUM_LOG.

Example time zone specifications can be found in Time Zones.

Live Monitoring and Manual Parsing

Once a debug log has been specified for a tag, Monitor will parse the log every 12 hours, by default. This period can be adjusted in the Admin > System > Configuration Information page or via the associated configuration procedure in the licmon.swd/vovlmd/config.tcl file.

If it is determined that the debug log environment is not suitable for live monitoring, logs can be manually parsed using either the appropriate parsing command for each license manager type:

Usage Information in FlexNet Publisher Debug Logs

Although experimental support is included in Monitor for parsing debug logs for utilization data, it is strongly discouraged to rely upon debug logs for the main data source for utilization statistics. The following lists some reasons for this:
  • Data is often missing from the debug log, meaning that there are missing OUT and/or IN records. It only takes a few missing records to produce inaccurate results, especially for long checkouts.
  • The OUT and IN records cannot be precisely matched to one another because they do not have unique identifiers like lmstat provides (the FlexNet Publisher handle). This makes it impossible to accurately track checkout durations. The Monitor debug log parser uses a first-out, last-in algorithm. This allows for easier detection of erroneous records (outliers) in the ftlm_check_db utility.
  • Debug logs are often corrupt with malformed lines. These are discarded by the parser, but they were supposed to represent a record that should be tracked, but it is lost because of the corruption.
  • The license server clock is often adjusted by a clock synchronization daemon such as ntpd. When this occurs, the timestamps in the debug log can jump forward or backward. In some cases, this the jump is significant enough to case major skew in the data. The parser attempts to accomodate for this, but if the jump is large enough in the backward direction, it will ignore records until the clock catches back up with the last known good timestamp.