Public source validation / validate (push) Failing after 3m8s
84 lines
2.0 KiB
Markdown
84 lines
2.0 KiB
Markdown
# 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.
|