Log Import Tips and Best Practices

How license server logs complement real-time monitoring, and what to watch for so your usage reports and audit defense actually hold up.

LiMon watches your license servers from the network in real time. It also lets you feed it the log files those servers write — from the command line, the web UI, or the REST API. This piece is about why that second channel matters even when you already have real-time monitoring, what each vendor’s log actually contains, and what separates a trustworthy import from one that quietly rots your numbers.

Doesn’t real-time monitoring make log import redundant?

It’s a fair question. Server logs contain the checkouts, checkins, and usually a bit more, depending on the vendor. So at first glance you might assume that a scheduled log ingestion duplicates what network polling already does — and that you could pick one or the other. Not really.

Network polling gives you the now: who has what checked out at this moment, whether the daemon is healthy, whether the pool is at 100%. That’s what tells you something is on fire before the tickets arrive. A nightly log ingestion can’t do that — by the time it sees an event, the user has come and gone.

The logs are the history, and they should be a clean record of it. They’re not, anymore, and that’s deliberate. Most vendors today are explicit in the file headers that the contents are “for debugging only” and not suitable for usage analysis. Out-of-order checkin/checkout events, missing timestamps, license file rereads that log duplicate checkouts, client reconnections that generate entries no real user produced — the list is long and the intent is clear. Vendors would prefer you bought their proprietary analytics suite, or engaged their professional services, rather than mine the free logs they already produce.

Their customers are the software publishers that license through them, not you. They are not in the business of helping you buy less from their customers.

So the value of importing the logs isn’t that they’re perfect. It’s that, treated carefully, they fill three gaps that polling alone leaves open.

What polling misses, and logs catch

Short sessions. Polling is scheduled. If a checkout starts and ends between two polls, LiMon never sees it. For an editor like NX that engineers leave open for hours, missing the occasional session is a rounding error. For ABAQUS jobs that finish a FEA solve in under a minute, polling can make a feature look idle when in reality your team is hitting it frequently. The log file has the full trace.

Denials. Polling will tell you the pool is at 100%. The log will tell you who tried to check out a license and got turned away. That’s the difference between “we’re using everything we own” and “we don’t own enough.” Without it, contention only surfaces through tickets and calls — by which point you’ve already lost the argument with finance about why renewal needs more seats. Denial counts also let you quantify the real cost of saying no, which is exactly the number you need next to “cost of more seats.”

Server-side events the network view doesn’t expose. Vendors keep some genuinely useful information in the logs that the protocol itself doesn’t reveal. A server that’s failing to serve some of its own licenses. Clients hitting it with the wrong version. Requests for features you don’t have licensed. Most of these are silent until you go looking, and you only find them in the logs.

Denials are where log import really earns its keep. Users complain. The vendor’s account rep nudges you to expand the pool. Polling alone gives you utilization — a strong signal, not a verdict. The log gives you the denial events themselves: who got turned away, on what feature, how often. Together, the two data sources argue both ways. Sometimes they confirm the case for more seats. Just as often they show the denials clustered around a handful of teams competing for some scarce licenses and some schedule tweak can save you the upsell.

What each format actually contains

The supported log formats look similar from a distance — timestamps, usernames, feature names — but each has its own gaps.

FlexLM debug log (lmgrd -l <path>)

The richest of the bunch. Records OUT, IN, DENIED, QUEUED, vendor daemon health, lmgrd restarts, and license file rereads. Caveats:

  • The default rotation behavior truncates the file on restart. Always start lmgrd with -l +path so the log appends instead of overwriting.
  • Borrowed checkouts (LINGER) appear as long sessions even after the user has disconnected. Without filtering, you’ll over-count concurrency.
  • Some vendor daemons emit non-ASCII characters in usernames or hostnames in the system locale, which is rarely what a naive parser expects.

RLM report log (REPORTLOG +<path>)

Designed for accounting rather than debugging. Cleaner format than FlexLM, with explicit START/PRODUCT/OUT/IN/DENY/STOP records. Caveats:

  • The + prefix on the path is mandatory for append mode. Without it, every RLM restart wipes the file.
  • Report logs don’t include queue events. If you care about queueing pressure, you also need the standard rlm.log.
  • Roaming checkouts can extend past the actual user session by hours.

LM-X usage log

LM-X writes structured per-checkout records by default, which makes parsing relatively straightforward. Caveats:

  • LM-X separates “license usage” from “license denials.” You may need to enable both with LICENSE_LOG=1 and make sure the denial log is captured.
  • Per-server logs need consolidation if you run a redundant pool; LM-X does not auto-merge.

DSLS usage history

DSLS (the Dassault Systèmes license server) keeps usage in its own database that you export with DSLicSrv -admin. Caveats:

  • DSLS rotates its history on its own schedule; if you don’t export at least daily, you lose granularity.
  • Token-based products (CATIA, 3DEXPERIENCE) report token consumption, not seats. The token-to-seat mapping varies by product and release.

The quiet failure modes

Most bad imports don’t fail loudly. They produce numbers that look reasonable and are slightly wrong. These are the patterns to watch for whether you’re rolling your own pipeline or evaluating someone else’s.

Rotation without overlap. Logs rotate at midnight, the import job runs at 1 a.m., and anything written in between disappears. The fix is to keep the previous rotation’s file readable for at least 48 hours and to track import position by byte offset or content hash, not by file timestamp.

Timezone drift. License servers run in whatever timezone the OS happens to use — sometimes UTC, sometimes local, occasionally local without DST awareness. Every twice-yearly DST change becomes either a one-hour gap or a one-hour duplicate. Verify what the server actually emits before normalizing.

Encoding and locale. Active Directory usernames often carry accented characters. FlexLM and RLM emit them in the system locale (CP1252 on Windows, UTF-8 on most modern Linux). Müller becomes M?ller if your importer assumes UTF-8 everywhere, and your per-user reports stop matching reality.

Truncated lines under load. When the license server is busy and the log directory sits on slow storage (NFS is a frequent culprit), individual lines can be truncated mid-write. A robust parser flags those as parse errors rather than silently interpreting a partial line as something it isn’t.

Skipping IN events. Filter only on OUT and DENIED and every checkout looks like it lasted forever. This is the single most common reason concurrency reports show absurd peak numbers. Always import the full event lifecycle, even if your reports only look at start times.

Polling and logs working together

The hard part isn’t parsing the logs. It’s combining them with what polling already saw, without double-counting and without leaving gaps.

LiMon handles that reconciliation in the background. Imports can be triggered on demand or on a schedule, from the command line or through the web interface, and either path coordinates with the other — a nightly automated import isn’t going to step on an operator’s ad-hoc upload for the same server. Once the raw events are in, LiMon rebuilds the affected date range, merging the fresh log evidence with the sessions it already had from polling, so the dashboards and reports for those dates reflect the combined picture instead of two versions of the truth.

That combined record is what feeds the rest of the product: the cost-optimization views that track utilization and contention over time, and the executive reports for renewal negotiations and audit responses. The reports are ultimately what justifies the careful import work — a renewal conversation goes very differently when you can hand the vendor a clean twelve-month breakdown than when you can only describe what you remember.

A short audit checklist

If you’re reviewing your own setup today, regardless of tool:

  1. Verify whether 6license servers are running with append-mode logging (lmgrd -l +path, REPORTLOG +path).
  2. Confirm the timezone the servers actually emit in their log files.
  3. Make sure your importer tracks position by byte offset, not by file timestamp.
  4. Spot-check a few lines with non-ASCII characters and confirm they round-trip through your store correctly.
  5. Pick one feature and reconcile its count of OUT events against IN events — they should be close. Small drift from open-at-shutdown sessions is normal.

If any of those return surprises, the rest of your numbers are at risk too.

Where LiMon fits

Most teams running engineering licenses have better things to do than maintain their own parsing pipeline. LiMon does the polling, the log ingestion, and the reconciliation in a single on-premises stack — no agents on the license servers, no cloud, no phone-home. Request an evaluation to try the workflow, then choose Standard or Professional for the server scale, audit-defense reporting, and savings reports that close the loop between “we monitored everything” and “we can prove it on the renewal call.”

Ready to Find Your Unused Licenses?

Deploy LiMon in 10 minutes. No agents, no cloud, no vendor approval needed.