Monitoring Logged-In Users

Keeping track of who's logged into your servers is crucial for both security and performance monitoring. Server Scout's logged-in users metric provides a simple yet effective way to monitor active terminal sessions on your Linux servers, helping you spot unusual activity and correlate user presence with system performance.

Enabling the Logged-In Users Metric

The logged-in users metric is disabled by default to minimise resource usage. To enable it, you'll need to modify your Server Scout configuration file:

  1. Open the Scout configuration file:

``bash sudo nano /etc/scout/scout.conf ``

  1. Add or modify the following line:

`` loggedinusers=1 ``

  1. Restart the Scout agent to apply the changes:

``bash sudo systemctl restart scout-agent ``

The agent will begin collecting user data within the next monitoring cycle.

How It Works

Server Scout uses the standard who command to count active terminal sessions on your server. The agent executes this command every 5 minutes during its regular monitoring cycle, counting the number of lines returned to determine how many users are currently logged in.

This approach captures:

  • SSH sessions (both interactive and active)
  • Console logins (physical or virtual terminal access)
  • Screen and tmux sessions that maintain active terminals

The metric specifically tracks terminal sessions and does not monitor web application users or other types of authenticated connections.

Viewing User Activity Data

Once enabled, you can view the logged-in users count on your server's detail page in the Server Scout dashboard. The metric appears as a line graph showing user activity over time, making it easy to spot patterns and anomalies.

The graph displays:

  • Current number of logged-in users
  • Historical trends over your selected time period
  • Peak usage times and quiet periods

This visualisation helps you quickly identify when your servers are being accessed and by how many concurrent users.

Security Implications

Monitoring logged-in users serves as an important security control. Unexpected logins outside normal business hours may indicate:

  • Unauthorised access attempts that have succeeded
  • Compromised user accounts being used by attackers
  • Insider threats or policy violations
  • Forgotten maintenance sessions left open

Regular monitoring helps establish baseline user activity patterns, making anomalies more apparent. If you notice users logged in during unusual hours or an unexpectedly high number of concurrent sessions, it warrants immediate investigation.

Practical Use Cases

Performance Correlation

User activity directly impacts server performance. By monitoring logged-in users alongside CPU, memory, and disk metrics, you can:

  • Identify performance bottlenecks caused by user activity
  • Plan capacity based on typical user loads
  • Optimise resource allocation during peak usage periods
  • Troubleshoot performance issues by correlating them with user presence

Compliance Auditing

For servers requiring restricted access, the logged-in users metric provides valuable audit data:

  • Regulatory compliance: Demonstrate controlled access for SOX, GDPR, or industry-specific requirements
  • Access pattern analysis: Verify that server access aligns with business processes
  • Security reviews: Provide historical data for security assessments and incident investigations

Operational Planning

Understanding user activity patterns helps with:

  • Maintenance scheduling: Plan updates and reboots during low-activity periods
  • Resource planning: Predict when additional server capacity might be needed
  • Shift planning: Ensure adequate support coverage during peak usage times

Best Practices

When using the logged-in users metric:

  • Set up alerts for unusual activity patterns outside business hours
  • Regularly review user activity trends to establish normal baselines
  • Combine this metric with other security monitoring tools for comprehensive coverage
  • Document expected user patterns to help identify genuine anomalies

Remember that whilst this metric provides valuable insights into terminal access, it should be part of a broader security and monitoring strategy rather than your only access control mechanism.

Frequently Asked Questions

How do I enable logged-in users monitoring in ServerScout?

Open the Scout configuration file at /etc/scout/scout.conf, add or modify the line 'logged_in_users=1', then restart the Scout agent with 'sudo systemctl restart scout-agent'. The metric is disabled by default to minimize resource usage.

How does ServerScout count logged-in users?

ServerScout uses the standard 'who' command executed every 5 minutes during monitoring cycles. It counts the number of lines returned to determine active terminal sessions, including SSH sessions, console logins, and screen/tmux sessions.

What types of user sessions does ServerScout monitor?

ServerScout tracks terminal sessions including SSH sessions (interactive and active), console logins (physical or virtual terminal access), and screen/tmux sessions that maintain active terminals. It does not monitor web application users or other authenticated connections.

Why should I monitor logged-in users for security?

Monitoring logged-in users helps detect unauthorized access attempts, compromised user accounts, insider threats, and policy violations. Unexpected logins outside normal business hours or unusually high concurrent sessions warrant immediate investigation.

Where can I view logged-in users data in ServerScout?

The logged-in users count appears on your server's detail page in the ServerScout dashboard as a line graph. It shows current users, historical trends over your selected time period, and peak usage times.

How often does ServerScout check for logged-in users?

ServerScout checks for logged-in users every 5 minutes during its regular monitoring cycle. The agent executes the 'who' command and counts active terminal sessions to provide current user activity data.

Can I correlate user logins with server performance?

Yes, you can monitor logged-in users alongside CPU, memory, and disk metrics to identify performance bottlenecks caused by user activity, plan capacity based on typical loads, and troubleshoot issues by correlating them with user presence.

Was this article helpful?