Console and metrics

A console session is a tunnel: your browser to the platform, the platform to your agent over the connection that is already open, and your agent to the machine. The platform in the middle never looks at the contents. It counts bytes and forwards them.

1. 01The panel asks for a ticket for this one server. The request is refused if you may not use this server's console, if the agent is not connected, if the integration is disabled or if the machine is not in a state that has a console.
2. 02The ticket is valid for a minute and can be used once. It names the server, so a ticket for something else cannot open this console.
3. 03Your browser opens a separate socket with that ticket. Every check is done again there, because things can change in that minute.
4. 04The agent attaches to the machine and reports which protocol it is: a screen for a virtual machine, a terminal for a game server. Your browser refuses a protocol it does not speak, with a message rather than a black rectangle.

• A session lasts at most an hour. The platform enforces that itself, next to the agent, and tells you why it closed.
• If your browser cannot keep up, the tunnel is paused rather than dropped. Only when the backlog gets truly large is the session ended.
• The session is recorded in the activity trail as a session: how long it lasted and how much went each way. No content, ever.

A console tab appears wherever the integration offers one, and its integration page tells you which do. Virtual machines and game servers can have a live screen or terminal; a hosting account is a slice of a shared machine with nothing of its own to attach to, so it never does.

• For Proxmox this is the machine's own screen, over the same port and the same token the integration already uses, so no second hole in your firewall is needed.
• For Pterodactyl it is the game server's terminal, relayed from Wings. You see console output, status changes and usage figures, and you can send commands.

Every server is measured on the same twenty-second rhythm as the poll. Recent measurements are kept as they are for quick graphs; older ones are folded into five-minute buckets with an average, a minimum and a maximum, so a spike does not disappear into a mean.

An hour and six hours are drawn from the recent measurements, a day and a week from the folded ones. The folded ranges also carry a band showing the highest and lowest value in each bucket.

Which graphs a server has follows from what its provider can measure.

• Virtual machines: processor, memory, disk, network and disk throughput. Disk usage inside the guest is not visible to the hypervisor, so that graph shows the allocated size.
• Hosting accounts: disk quota usage. That is what a control panel reports.
• Game servers: processor, memory, disk and network. Wings does not report disk throughput.

Measurements are deliberately not resent after a disconnection. An agent that was away leaves a gap in the graph rather than a burst of back-dated points, and the line is broken rather than drawn straight across.

Recent measurements are kept for a few hours, folded measurements for a month. A deleted server keeps its graphs until they age out.

An agent has its own graphs, in four groups: the host it runs on, the agent process, the connection to the platform, and the network interface it serves installations from. Where a family has several labels, the busiest three are drawn and the rest are named.

Separately from the metrics there is an operational log that the agent streams live: what its runtime, its session, its integrations, its installation service and its downloads are doing. It is composed by the agent from codes and parameters, so it renders in your language, and it is stripped of anything that looks like a secret twice, once on your host and once on arrival.