Engine
What Is Engine?
Engine is the tab where the state of the AGS engine of a vService with the AGS access control enabled is monitored and the maintenance operations are made. The AGS engine is the process that runs the login pages, the authentication and MFA steps and the access flow of the vService; it runs separately per enabled vService on every device, opens one worker process for every processor core assigned to the vService and keeps the sessions, the lockouts and the TOTP records in the session store of the device. When the vService is disabled its engine is removed.
The screen shows one card for every device. In the card there are the state of the engine, its uptime, its memory usage and the space it occupies in the session store; with the buttons under the card the engine is restarted or the vService data in the session store is cleaned. In a cluster setup the engines of the two devices are shown side by side in two cards, and in a single device setup in a single card at full width.
The screen answers the question "is the AGS engine running healthily?". If AGS Uptime reads zero on the Live Stats dashboard, if the AGS counters are not advancing, if the sections read - or if the users see a preparation page instead of the login page, this tab is the first place to look.
Accessing Engine
- Left Monitor Panel is opened.
- AGS-Enabled vServices is selected from the category tabs at the top left.
- The vServices defined on TR7 with AGS access control enabled are listed.
- The vService to be monitored is clicked; the screen opens with the Dashboard tab that carries the vService's name.
- On the screen that opens, the Engine tab is clicked.
The tab is displayed unconditionally to the users who have monitoring authorization in the Load Balancer area. The Restart Engine and Clean Storage operations require the Load Balancer modify authorization; the buttons are displayed to the users who do not have this authorization as well and the operation is rejected with an error window after the confirmation.
The Engine Screen
When the Engine tab is opened, one engine card is shown for every device. In the image below the cards of two devices in a cluster setup are displayed.
The Engine Screen
Card Header
At the top left of the card there are the server icon and the name of the device, and at the top right the state badge of the engine. The badge shows the state of the engine, which is evaluated again once every 10 seconds on the server side, and is updated without the page being refreshed when the state changes.
| Badge | Color | Meaning |
|---|---|---|
| running | Green | The engine is running, all the worker processes are responding and the session store is reachable. |
| partially degraded | Yellow | The engine is running but some of the worker processes are not responding or the session store is not reachable. |
| starting | Yellow | The engine has just been started and the worker processes are not ready yet. The engine can stay in this state for up to one minute. |
| not responding | Red | The engine looks as if it is running but although one minute has passed since it was started none of the worker processes is responding. |
| restarting repeatedly (crash loop) | Red | The engine shuts down and starts again over and over at short intervals. |
| stopped | Red | The engine has stopped. |
| not created | Red | The engine for the vService could not be found on this device; the engine has never been created or has been removed. |
| unknown | Light yellow | The engine state could not be taken from the device: the first check after the device was turned on has not been made yet, the vService is disabled or there is no connection with the peer device in the cluster. In this case the measurements read - as well. |
When a reason can be determined for the state of the engine, a yellow information row is displayed under the badge:
| Reason | Badge | Meaning |
|---|---|---|
| engine files are missing on this device | stopped · restarting repeatedly (crash loop) | The files required for the engine to run are not found on this device. |
| ran out of memory | stopped · restarting repeatedly (crash loop) | The engine was shut down because it exceeded the memory limit. The memory limit is derived from the Memory Limit setting of the vService. |
| engine setup failed | not created · stopped · restarting repeatedly (crash loop) | The engine could not be created or could not be restarted while the vService configuration was being applied. |
| session storage is unreachable | partially degraded | The engine is running but the session store cannot be accessed; the logins fail. |
In the starting and not responding states and in the partially degraded state in which some of the worker processes are not responding, the reason row is not displayed.
Measurements
The three values in the middle of the card flow live; when the tab is left the subscription is closed.
| Measurement | Description |
|---|---|
| Uptime | The uptime of the engine process, with the two largest units (e.g. 53m 33s, 2h 5m). It is reset when the engine is restarted. |
| Memory | The memory the engine uses and the memory limit (e.g. 295.6MB / 1GB). The limit is half of the Memory Limit value in the QOS settings of the vService (e.g. if 4GB is selected 2GB). While QOS is closed or while Memory Limit is not selected, the default 2 GB is taken as the basis for the vService and the engine limit becomes 1 GB. There is no separate memory setting on this screen. |
| Storage | The memory usage the engine reports in the session store for this vService (e.g. 1KB). |
When the value cannot be read, - is displayed in the relevant field. While the session store is in an accessible state, if the engine is not running Uptime reads 0.
Card Buttons
The two buttons under the card are applied only to the device of that card. While the operation continues the buttons stay passive; when the operation is completed successfully a separate result message is not shown, the result is monitored from the badge and the measurements. If the operation is rejected or if the target device cannot be reached, an error window is displayed.
Restart Engine
The AGS engine on the device of the card is restarted by clicking the Restart Engine button. Before the operation the "Are you sure?" confirmation is requested.
- The data in the session store is not deleted; the sessions, the lockouts and the TOTP records are preserved.
- Until the engine comes up again, the preparation page with the text "Access Gateway is being prepared. Please try again shortly." is shown for the requests the engine meets, such as the login page, the MFA and the portal. In this process the badge can read starting for a short time according to the check timing and passes to the running state when the engine is ready.
- Since the application requests of the sessions whose identity has been verified do not pass by the engine, the users whose session is open continue to access the application during the restart.
- If the operation is repeated one after another without the engine reading running, the badge can read restarting repeatedly (crash loop) for one minute even if the engine is running healthily and an engine state alarm can be produced.
- In a cluster setup the engine of the other device is not affected; if the engines of both devices are to be restarted, the operation is applied separately on the two cards.
- When the operation is completed successfully, it is recorded on the User Logs screen on behalf of the user who performs the operation with the text
AGS engine restarted for "<vService>" service; the record does not state the device the operation is applied to.
Clean Storage
All of the AGS data belonging to this vService in the session store on the device of the card is deleted by clicking the Clean Storage button. Before the operation the "Are you sure?" confirmation is requested.
Clean Storage cannot be undone
The data deleted is as follows:
- All of the sessions: all of the sessions whose identity has been verified and has not been verified are deleted; the users whose session is open have to log in again (Sessions).
- The lockouts and the failed attempt counters (Lockout).
- The TOTP records: the users have to enroll their authenticator applications again (TOTP).
- The AGS counters: the total counters the Live Stats dashboard reads are reset.
- The other runtime data the engine keeps for this vService.
The confirmation window does not state this scope separately. The Audit Logs records, the AGS configuration and the local user databases are not affected by this operation.
In a cluster setup only the data on the device of the card that is clicked is deleted; the session store of the other device stays as it is. When the operation is completed successfully, it is recorded on the User Logs screen on behalf of the user who performs the operation with the text AGS storage cleaned for "<vService>" service; the record does not state the device and the number of records deleted.
Scope and Limits
INFO
- The operations are per device. Restart Engine and Clean Storage are applied only to the device of the card that is clicked; in a cluster they are run separately for the two devices. The Restart Engine operation made from the menu of the preview title on the Dashboard and AGS Management tabs is applied only to the engine of the device connected to; the confirmation window does not state the target device.
- The state is updated with a delay. The badge changes with the 10 second check interval; the measurements, on the other hand, flow live. After a restart, one check round is waited for after the engine becomes ready in order for the badge to read running.
- The memory limit comes from the QOS setting. The engine memory is applied as half of the Memory Limit value of the vService. The engine that exceeds the limit is shut down and restarted by itself; this situation is understood from the resetting of the Uptime value. If the engine has stopped or is restarting continuously for this reason, ran out of memory is displayed under the badge. The limit is raised from the vService QOS settings; when Memory Limit or Cores is changed and the vService configuration is applied, the engine is restarted by itself with the new limits and the data in the session store is preserved.
- The state alarm. When the badge reads not responding, restarting repeatedly (crash loop), stopped or not created or when the session storage is unreachable reason is displayed, an engine state alarm is produced; starting and partially degraded without a reason do not produce an alarm. The channels of the alarm are defined on the Notification Profiles screen.
- The screen does not contain a table. Row selection, a right-click menu, a preview panel and pagination are not found in the tab.
- What the screen does not show. The processor usage of the engine, the number of records in the session store and the number of restarts do not take place on this screen.
