License and updates
The license alerts in System Health and what each one means, a patch that refuses to deploy, version conflicts after an update, rolling back, and a deployment that does not report to dock.
What you will do: read a license or update alert correctly and resolve it without a reinstall.
License alerts
The license is per server or cluster and is enforced on the dimensions it carries. System Health raises these alerts:
| Alert | Meaning | What to do |
|---|---|---|
| License will expire in N days | The term is ending | Renew on dock (Licenses) or through your partner; install the new .lic under PortX > Settings > License and restart |
| License is not valid | The file does not match this server key, is corrupt or has expired | Generate the server key again (any node of the cluster), bind it on dock or send it to XPLG, install the new file |
| Server key is invalid | The key no longer matches the installation; the server stops until it is resolved | Install a license issued for the current key; a cloned or moved host has a new key |
| Allowed data volume exceeded | Daily ingestion passed the licensed volume; the Data thresholds are measured against the licence volume | Reduce or route data with PortX, or move to a higher tier; dock shows plan versus actual on Licenses |
| Allowed number of logs was reached | The licensed log count is used up | Remove unused logs or extend the license |
An evaluation license is created with your workspace and bound on Licenses; see Get an evaluation license and How licensing works. A license must also be renewed when its terms change, for example a higher daily volume.
A patch will not deploy
- Runtime. Every current V7 build needs Java 17 and Tomcat 10 on every node; the patch fails on an older runtime. Check System Health > System Information and apply patch 9001 first.
- Prerequisite build. 7.9859 requires 7.9858 on every instance (Release notes).
- License. A valid V7 license is a prerequisite for applying patches.
- Disk. At least 3 GB free on each node for the patch and its backup.
- Zip. Keep the downloaded patch unextracted; verify size and MD5 against the upgrade guide.
- Service on Linux. Stop the service and run the instance manually from the installation directory for the patch; the
ant.outlog records the deployment. - Load balancer. Publish from a direct connection to one node.
After the update
- "Conflict between installation and configuration versions": a node was missed — publish the patch to it. About > update patch lists every node with its version.
- A node shows an old version in About but the patch is listed: it has not restarted; restart that instance.
- Validate in five phases (Upgrades); Deployments in dock shows the new version after the next heartbeat.
Rolling back
- Configuration: stop every node, unzip the chosen daily backup from
<extConf>/temp/backups/, restore itsconfandcollectiondirectories, start. - V7 version: Publish Patch of the earlier zip; the Java migration keeps
java8_backup(patch 9001). - X8: the previous image tag and
up -d.
The deployment does not report to dock
- Outbound HTTPS (443) from the XPLG host to dock.xplg.com, through the proxy flags if your site uses one.
- The heartbeat is configured with the license key on first contact and the deployment token afterwards; a reinstalled host has a new key and registers as a new deployment unless the token is restored (Register a deployment).
- Deployments shows the last heartbeat time; a deployment that stays "offline" after an upgrade is usually a token lost with the installation directory.
Next: Diagnostics
Source: XPLG wiki, pages 1594133274, 1594132938, 1597964372, 1708130305, 3179773959, 1689157633, 1595637833, 1602191443 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/1594133274).
