Doctor plugin checks: implement health check classes and documentation
Implement remediation-aware health checks across all Doctor plugin modules (Agent, Attestor, Auth, BinaryAnalysis, Compliance, Crypto, Environment, EvidenceLocker, Notify, Observability, Operations, Policy, Postgres, Release, Scanner, Storage, Vex) and their backing library counterparts (AI, Attestation, Authority, Core, Cryptography, Database, Docker, Integration, Notify, Observability, Security, ServiceGraph, Sources, Verification). Each check now emits structured remediation metadata (severity, category, runbook links, and fix suggestions) consumed by the Doctor dashboard remediation panel. Also adds: - docs/doctor/articles/ knowledge base for check explanations - Advisory AI search seed and allowlist updates for doctor content - Sprint plan for doctor checks documentation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
78
docs/doctor/articles/notify/email-connectivity.md
Normal file
78
docs/doctor/articles/notify/email-connectivity.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
checkId: check.notify.email.connectivity
|
||||
plugin: stellaops.doctor.notify
|
||||
severity: warn
|
||||
tags: [notify, email, smtp, connectivity, network]
|
||||
---
|
||||
# Email Connectivity
|
||||
|
||||
## What It Checks
|
||||
Verifies that the configured SMTP server is reachable by opening a TCP connection to the SMTP host and port. The check:
|
||||
|
||||
- Opens a TCP socket to `SmtpHost:SmtpPort` with a 10-second timeout.
|
||||
- Reads the SMTP banner and verifies it starts with `220` (standard SMTP greeting).
|
||||
- Reports an info-level result if the connection succeeds but the banner is not a recognized SMTP response.
|
||||
- Fails if the connection times out, is refused, or encounters a socket error.
|
||||
|
||||
The check only runs when both `SmtpHost` and `SmtpPort` are configured with valid values.
|
||||
|
||||
## Why It Matters
|
||||
A configured but unreachable SMTP server means email notifications will silently fail. Release gate alerts, security finding notifications, and approval requests will never reach operators, potentially delaying incident response.
|
||||
|
||||
## Common Causes
|
||||
- SMTP server not running
|
||||
- Wrong host or port in configuration
|
||||
- Firewall blocking outbound SMTP connections
|
||||
- DNS resolution failure for the SMTP hostname
|
||||
- Network latency too high (exceeding 10-second timeout)
|
||||
|
||||
## How to Fix
|
||||
|
||||
### Docker Compose
|
||||
Verify network connectivity from the container:
|
||||
|
||||
```bash
|
||||
docker exec <notify-container> nc -zv smtp.example.com 587
|
||||
docker exec <notify-container> nslookup smtp.example.com
|
||||
```
|
||||
|
||||
Ensure the container network can reach the SMTP server. If behind a proxy, configure it:
|
||||
```yaml
|
||||
environment:
|
||||
HTTP_PROXY: "http://proxy.example.com:8080"
|
||||
```
|
||||
|
||||
### Bare Metal / systemd
|
||||
Test connectivity manually:
|
||||
|
||||
```bash
|
||||
nc -zv smtp.example.com 587
|
||||
telnet smtp.example.com 587
|
||||
nslookup smtp.example.com
|
||||
```
|
||||
|
||||
Check firewall rules:
|
||||
```bash
|
||||
sudo iptables -L -n | grep 587
|
||||
```
|
||||
|
||||
### Kubernetes / Helm
|
||||
Verify connectivity from the pod:
|
||||
|
||||
```bash
|
||||
kubectl exec -it <notify-pod> -- nc -zv smtp.example.com 587
|
||||
```
|
||||
|
||||
Check NetworkPolicy resources that might block egress:
|
||||
```bash
|
||||
kubectl get networkpolicy -n stellaops
|
||||
```
|
||||
|
||||
## Verification
|
||||
```
|
||||
stella doctor run --check check.notify.email.connectivity
|
||||
```
|
||||
|
||||
## Related Checks
|
||||
- `check.notify.email.configured` — verifies SMTP configuration is complete
|
||||
- `check.notify.queue.health` — verifies the notification delivery queue is healthy
|
||||
Reference in New Issue
Block a user