Maintenance, Monitoring, and Performance
What this domain tests
This domain covers what to back up and in what order, how to read logs and health signals, which tuning levers exist, and the supported upgrade sequence.
Back up three different things
Portal: configuration store and content directory, exported through the portal administrator directory or captured at file level with the portal stopped. ArcGIS Server: a site backup through Server Manager or the backup scripts under the ArcGIS Server tools directory. ArcGIS Data Store: the backup data store utility run on each data store machine, plus separate backups of any enterprise geodatabases. A data store backup cannot be restored into a different portal, and restoring requires the hosting server to be reachable.
Logs and health
Server logs live under the ArcGIS Server logs directory with levels running from SEVERE through WARNING, INFO, FINE, VERBOSE and DEBUG; Server Manager or the administrator REST logs endpoint reads them. Portal logs live under the portal logs directory and in the portal administrator directory. Both cap file size and age, but leaving DEBUG on after troubleshooting will fill the disk. Health endpoints, service uptime checks and ArcGIS Monitor cover what logs miss; also track certificate and license expiry and data store disk growth.
Performance levers
Per service: minimum and maximum instances, instance idle timeout, dedicated instances, maximum record count and query limits. Platform: cached or vector tile basemaps instead of dynamic layers, additional federated GIS servers behind the Web Adaptor, adequate portal heap, and data store storage on fast separate disks. Publishing and sync load the hosting server first, so check its processes and instance counts when users complain.
Upgrade order
Portal for ArcGIS, then ArcGIS Server, then ArcGIS Data Store, then the Web Adaptor; run the data store upgrade utility afterwards and verify federation and services. Confirm the supported upgrade path before starting.
Worked example
Editors report 40-second map loads every morning at 08:00. Reasoning: read the server logs for slow requests to see whether the delay is in the portal or the service; check instance counts on the hosted feature layer, where a low maximum instance setting queues a login spike. Raise maximum instances, add minimum instances for the peak window, set a query limit, and serve the basemap as a tile layer so panning never hits the feature service.
Traps
Restoring a data store backup from another deployment; expecting a server upgrade to upgrade the data store; leaving verbose logging on; blaming the portal for slowness that service logs attribute to the hosting server.