CT-Ops

Host Monitoring

How to use host metrics, heartbeat history, checks, and alert rules in CT-Ops.

The Monitoring area is where CT-Ops shows whether a host is behaving normally over time. Use it when a host is slow, noisy, intermittently offline, or failing a service-level check.

Open it from a host detail page. The host detail navigation separates monitoring into two operational tabs:

• Metrics shows resource charts, heartbeat intervals, and host notification charts.
• Checks shows host-specific checks, recent check history, check health, and check alert rules.

Metrics tab

The Metrics tab is the time-series view for a single host. CT-Ops loads the selected host’s metric and heartbeat history only while this tab is active, then refreshes the live range every 60 seconds.

At the top of the tab, the range selector controls the time window used by all charts in the tab:

The CPU, memory, and heartbeat charts share the same horizontal time axis. Drag across a chart to zoom into a narrower time window. When zoomed, CT-Ops shows the exact start and end timestamps beside Reset zoom and pauses automatic live refetching for the zoomed view so the selected window does not move while you are inspecting it.

If the host has not sent metric history for the selected period, the tab shows No metric history yet. Data appears after the agent starts sending heartbeats that include resource telemetry.

CPU, memory, and disk usage chart

The CPU, Memory & Disk Usage (%) chart is a line chart with three series:

The Y axis is fixed from 0% to 100%, which makes spikes and sustained pressure easy to compare across hosts and time ranges. Hover a point to see the exact timestamp and percentage for each series at that time.

Use this chart to answer whether a problem is:

• a short spike, such as a batch job or restart
• a sustained plateau, such as memory pressure or a full disk
• a repeating pattern, such as backups, sync jobs, or scheduled workloads
• correlated across resources, such as CPU and memory rising together

For long ranges, gaps can indicate missing heartbeat telemetry, an offline agent, or an ingestion problem.

Heartbeat history

The Heartbeat Interval chart shows the number of seconds between consecutive agent heartbeats. It answers a different question from the host online/offline badge: it shows whether the agent has been reporting consistently over time.

The chart is a bar chart:

For ranges longer than 2 hours, the chart label notes max per bucket. In that mode, each bar represents the largest heartbeat gap in its time bucket, so brief dropouts remain visible even on wider ranges.

Use heartbeat history to distinguish:

• a host resource issue, where metrics change but heartbeats remain regular
• an agent or network issue, where heartbeat bars stretch or disappear
• an ingestion outage, where many hosts show heartbeat gaps at the same time

If heartbeats are missing but the host should be online, check network connectivity to ingest, the agent service state, and whether the agent still has valid identity material.

Notification charts

The Metrics tab also includes two host-specific notification charts. They refresh every 60 seconds.

Notification Severity

Notification Severity is a donut chart for all notifications recorded against the host, grouped by severity.

Hover a slice to see the notification count and percentage of the host’s total. If there are no notifications for the host, the chart shows No notifications for this host.

Use this chart to understand whether a host is mostly producing critical alerts, lower-priority warning noise, or a balanced mix.

Notification Trend

Notification Trend is a line chart for critical and warning notifications over time. It deliberately excludes info notifications so operational noise does not hide incident-level trends.

The range selector in this chart is separate from the metrics range selector:

The line chart has one line for Critical notifications and one line for Warning notifications. Hover a point to inspect the counts for that period. Daily ranges include a bucket for every day in the selected period, even when a day has no notifications. Those empty days stay on the chart with zero counts, so the trend line dips instead of skipping over quiet periods.

Use this chart to decide whether a host had one isolated event, repeated failures, or alert activity that lines up with metric pressure or maintenance.

Checks tab

The Checks tab manages checks that run for the current host. CT-Ops refreshes the check list and recent history every 30 seconds.

The top row contains:

After assigning global checks, CT-Ops shows a success or error message. The success message includes how many checks and alert rules were assigned.

When checks exist, CT-Ops shows a health summary card:

The summary also lists how many checks are passing, failing, and pending out of the total.

Check rows and history charts

Each check row shows the check name, type badge, alert badge when enabled alert rules exist, recent results, current health, and row actions.

Checks are sorted so noisy checks appear first: CT-Ops prioritizes checks with more recent status changes, then checks with recent failures or errors.

When a row is expanded, CT-Ops shows how many results are stored for that check, the latest formatted output when available, and a compact history chart. Up to 100 recent results are loaded.

The compact history chart changes its metric by check type:

For patch status charts, green means the patch age is within policy, amber means the patch age is close to the configured maximum age, red means it is over the configured maximum, and gray means the agent did not return enough patch-age data to classify it.

Creating checks

Click Add check to open the Add Check dialog. The form always includes the common fields below, then shows additional fields based on the selected type.

The Add check submit button is disabled until Name has a value. If the server rejects a field, CT-Ops shows the validation error in the dialog.

Port check form

Choose Port - TCP connectivity to verify that the agent can connect to a TCP port.

Use port checks for databases, reverse proxies, message brokers, and local services where TCP reachability is the basic service signal.

Process check form

Choose Process - running process to verify that a process or service is running.

Use process checks when a service can be unhealthy because it has stopped, even if no network listener is exposed.

HTTP check form

Choose HTTP - health endpoint to verify an HTTP or HTTPS endpoint from the host.

Use HTTP checks for health endpoints, local admin endpoints, or service probes where a TCP connection alone is not enough.

Certificate check form

Choose Certificate - TLS certificate to inspect a certificate served over TLS.

Use certificate checks for externally or internally served TLS endpoints where certificate expiry must be visible before it becomes an incident.

Certificate file check form

Choose Certificate - File on disk to inspect certificate material stored on the monitored host.

Use certificate file checks when the certificate is not directly served on a network port or when you need to monitor Java keystores and packaged certificate files.

Folder size check form

Choose Folder Size - Path usage to monitor disk usage for a path.

Used-space checks fail above the threshold. Free-space checks fail below the threshold. Use used-space checks for growth control and free-space checks for minimum-capacity policies.

File size check form

Choose File Size - Specific file threshold to monitor one file.

Use file size checks for log growth, queue files, exports, or state files where an unusual size is a useful signal.

Docker volume check form

Choose Docker Volume - Volume size threshold to monitor a Docker volume.

Use Docker volume checks for database, registry, cache, and application volumes where growth can consume disk unexpectedly.

Service account check form

Choose Service Accounts - discover system users to discover local accounts. This check has no additional fields. The agent reads /etc/passwd and checks for running processes so CT-Ops can report system accounts observed on the host.

Use this check when account inventory and service-account drift matter for the host.

SSH key scan check form

Choose SSH Key Scan - discover SSH keys to scan user home directories for SSH key material. This check has no additional fields. It looks for authorized_keys files and identity files, then reports key type, fingerprint, and age.

Use this check to make SSH access paths visible and to find stale or unexpected keys.

Patch status check form

Choose Patch Status - OS patch age and updates to monitor operating-system patch posture.

Use patch status checks when a host should raise attention because it has not been patched recently or has too many outstanding package updates.

Alert rules

The Alerts on failure panel appears in both the add and edit check dialogs. It defines alert rules that turn check failures into CT-Ops alert instances.

Click Add Alert to open the alert editor.

Saved alert rules appear in the panel with their severity and threshold. Use the pencil button to edit a rule and the trash button to remove it. CT-Ops supports up to 10 alert rules per check, which lets you configure escalation patterns such as a warning after 3 failures and a critical alert after 10 failures.

Severity describes impact. Consecutive failures describe confidence. For noisy network checks, use a higher threshold. For checks where one failure is already meaningful, use a lower threshold.

Editing checks

Click the pencil button on a check row to open Edit Check. The edit dialog uses the same type-specific fields as the add dialog and also includes:

The check type itself is fixed in the edit dialog. To change a port check into an HTTP check, create a new check and delete the old one after the replacement has results.

Global defaults

Administrators can define global check defaults for the CT-Ops instance. On a host’s Checks tab, Assign global checks copies those defaults onto the current host and creates any configured alert rules that belong to the defaults.

Use global defaults to bring a host back in line with the standard monitoring baseline. This is useful after onboarding a host, replacing checks that were removed, or correcting drift. Host-specific checks and edits remain useful for exceptions where one machine legitimately needs different monitoring.