# Service and network monitoring requirements

## Service model

A service represents a reachable capability independently of container state.

Types:
- HTTP/HTTPS;
- TCP;
- DNS;
- ICMP where permitted;
- TLS certificate;
- JSON response;
- keyword/content assertion.

A service belongs to an application/entity and may declare dependencies.

## Probe configuration

- target URL/host/port;
- interval and timeout;
- expected status codes;
- redirect policy;
- TLS verification;
- optional JSONPath/keyword assertion;
- allowed source/agent;
- maintenance schedule;
- labels/category;
- secret reference for authenticated probes.

Never store plaintext probe credentials in database exports or evidence.

## SSRF and target safety

The probe engine must:
- validate scheme and port;
- resolve and re-check DNS;
- block link-local, metadata and unspecified addresses;
- apply an explicit network/target allowlist;
- prevent redirect escape to disallowed targets;
- limit response size;
- avoid executing returned content;
- restrict custom headers and methods;
- log redacted destinations.

LAN/private targets may be intentionally allowed through administrator configuration.

## Results

Store/derive:
- current state;
- response time;
- status/error class;
- availability windows;
- last success/failure;
- incident history;
- TLS expiry/issuer/hostname validity;
- DNS resolution timing when relevant.

## Network

Monitor:
- interface throughput;
- packet errors/drops;
- gateway reachability;
- DNS latency/failure;
- internet reachability using configured targets;
- internal service dependency failures;
- certificate expiry.

Avoid conflating internet failure with server failure. Dependency suppression should group downstream service alerts.

## Topology

Relationships may come from:
- container labels;
- compose project;
- reverse proxy connector;
- service configuration;
- observed dependency declarations;
- user confirmation.

Source/confidence must be retained. Inferred edges are visibly different from confirmed edges.