What it is
Every Observatory target can run up to four monitors: ping, SNMP, HTTP and a TCP probe. This page covers ping, HTTP and TCP.
- Ping (ICMP) answers “is the device reachable?”. CreaRack sends ICMP echoes natively (the
icmpliblibrary, no OSpingsubprocess) and records latency, packet loss and jitter. - HTTP checks answer “is the service healthy?”. They request a URL and record status code, response time, response size, redirect target and SSL certificate validity, including days until expiry.
- The TCP probe answers “does this port accept connections?”. It is the reachability net for devices that block ICMP: if the probe connects, the device counts as up even when every ping is lost.
The CreaRack cloud probes public IPs only. Targets on private LAN ranges are probed by the Local Agent (Sentinel mode), which also keeps monitoring 24/7 with no browser open.
How ping works
Ping is enabled by default on new targets — open the device tab and the Heartbeat section starts updating.
Each check records:
- Status: up (0% loss), degraded (partial loss) or down (no replies).
- Latency: average round-trip time in ms, plus min/max.
- Packet loss: percentage of unanswered packets.
- Jitter: variation between round trips, in ms.
The monitoring refresh uses a fast probe (1 packet, 1 s timeout) so a down host does not stall the page. Diagnostic and batch operations use 4 packets with a 2 s timeout per packet.
For live troubleshooting, open the Console in the Heartbeat section: a terminal-style panel pings the device every 2 seconds (green = reply with latency, red = timeout) and keeps the last 50 lines.
How to configure an HTTP check
- Open the device tab and find the HTTP section.
- Open HTTP Settings.
- Set the URL (e.g.
https://myservice.example/health) and the Method — GET (downloads the body) or HEAD (headers only, lighter). - Save. HTTP monitoring is enabled automatically for the target.
Each check runs with a 10 s timeout, follows redirects, verifies the SSL certificate and reads at most 2 MB of body. Status mapping: a 2xx (or 301/302/304) response is up — but degraded if it took over 2000 ms; 5xx is down; other 4xx are degraded.
How to configure the TCP probe
Some devices never answer ping — hardened servers, firewalls, appliances that only expose SSH. Without the probe they show as down even though they are alive.
- Open the device tab and find the Heartbeat section.
- Click TCP Probe.
- Tick Enable TCP probe and set the Port the device exposes (e.g.
22for SSH,443for HTTPS). - Save.
From then on the device counts as up whenever the port accepts connections, even if ICMP is fully blocked. The probe measures the connection handshake latency; a closed or filtered port counts as a failed probe. Each check uses a 3 s timeout.
Intervals
Each device has its own Polling cadence — 15 s, 30 s, 1 min (default) or 5 min — set in its card editor; see [[crearack—network—device-page]]. Charts refresh at that pace while the tab is open, and in Sentinel mode the Local Agent applies the same cadence to its 24/7 checks — with one guardrail: the availability ping never slows beyond 30 s, so a down device is noticed quickly even at a 5 min cadence. The TCP probe follows the same guardrail.
When to use each
- Ping: turn it on for every piece of infrastructure. It is cheap and gives you the baseline availability metric.
- HTTP: add it for web services and APIs you care about. Use HEAD when you do not need the body. The SSL expiry reading helps you renew certificates before they bite.
- TCP probe: add it to anything that blocks ICMP but exposes a service port — the classic case is a server that only answers SSH. It keeps your availability numbers honest.
- Combine them (plus SNMP) on critical devices: reachability, service health and traffic in one tab.
Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
| Target always down on ping | ICMP blocked by a firewall | Allow ICMP echo, or enable the TCP Probe on a port the device exposes (e.g. 22) |
| LAN target never checked | Cloud cannot reach private IPs | Enable the Local Agent (Sentinel) |
| TCP probe down but the device is up | The configured port is closed or filtered | Point the probe at a port that actually accepts connections |
| HTTP check degraded with 4xx | Endpoint needs auth or wrong path | Point the URL at an unauthenticated health endpoint |
| HTTP slow but service fine | Response over 2000 ms marks it degraded | Serve a lighter health URL or use HEAD |
Related
- [[crearack—monitoring—que-es-observatory]] — module overview
- [[crearack—monitoring—metricas]] — metrics collected and retention
- [[crearack—monitoring—configurar-snmp]] — bandwidth via SNMP
- [[crearack—monitoring—alertas]] — thresholds on latency, loss and HTTP time
- [[crearack—network—device-page]] — setting the polling cadence per device
Véase también
- [[crearack—monitoring—que-es-observatory]]
- [[crearack—monitoring—metricas]]
- [[crearack—monitoring—configurar-snmp]]
- [[crearack—monitoring—alertas]]