Hogyan lehet létrehozni egy állapotfigyelő szolgáltatást a Go-ban

A monitorozás a megbízható szoftverek futtatásának kritikus része, de sok csapat csak akkor észleli a megszakításokat, amikor a felhasználói panaszok elkezdenek megjelenni. Képzeld el, hogy 2 órakor Slack üzenetet kapsz, amely azt mondja, hogy az API-k több mint egy órán át le vannak állítva, és senki sem vette észre, amíg az ügyfelek el nem kezdték a panaszokat. Ebben a bemutatóban elviszem a lépéseket, hogyan kell építeni egy állapotfigyelő alkalmazást a semmiből. Próbálja ki szolgáltatásait ütemezés szerint (HTTP, TCP, DNS és még sok más) Felismeri a megszakításokat és figyelmeztetéseket küld a különböző kommunikációs csatornáknak (Teams, Slack stb.) Az események nyomon követése automatikus nyitással/zárással A Prometheus és a Grafana táblák mutatói Folytatódik a Docker Ehhez az alkalmazáshoz a Go-t fogom használni, mert gyors, egyetlen binárisra állítja össze a platformok közötti támogatást, és egyidejűleg kezeli, ami fontos egy olyan alkalmazás számára, amelynek egyszerre több végpontot kell figyelemmel kísérnie. Mit építünk Létre fogunk hozni egy Go alkalmazást "StatusD". Elolvassa a konfigurációs fájlt, amely tartalmazza a szolgáltatások listáját, megfigyeli őket, és incidenseket, tűz értesítéseket hoz létre, ha valami rosszul megy. Tech Stack Used: Golán Postgrémium Grafana (Prometheus a metrikában) Docker Nginx Íme a magas szintű építészet: ┌─────────────────────────────────────────────────────────────────┐ │ Docker Compose │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Postgres │ │Prometheus│ │ Grafana │ │ Nginx │ │ │ │ DB │ │ (metrics)│ │(dashboard)│ │ (reverse proxy) │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │ │ │ │ │ │ │ │ └─────────────┴─────────────┴──────────────────┘ │ │ │ │ │ ┌─────────┴─────────┐ │ │ │ StatusD │ │ │ │ (our Go app) │ │ │ └─────────┬─────────┘ │ │ │ │ └──────────────────────────────┼──────────────────────────────────┘ │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ │Service │ │Service │ │Service │ │ A │ │ B │ │ C │ └────────┘ └────────┘ └────────┘ Projekt szerkezet Mielőtt kódot írnánk, értsük meg, hogyan illeszkednek egymáshoz a darabok. status-monitor/ ├── cmd/statusd/ │ └── main.go # Application entry point ├── internal/ │ ├── models/ │ │ └── models.go # Data structures (Asset, Incident, etc.) │ ├── probe/ │ │ ├── probe.go # Probe registry │ │ └── http.go # HTTP probe implementation │ ├── scheduler/ │ │ └── scheduler.go # Worker pool and scheduling │ ├── alert/ │ │ └── engine.go # State machine and notifications │ ├── notifier/ │ │ └── teams.go # Teams/Slack integration │ ├── store/ │ │ └── postgres.go # Database layer │ ├── api/ │ │ └── handlers.go # REST API │ └── config/ │ └── manifest.go # Config loading ├── config/ │ ├── manifest.json # Services to monitor │ └── notifiers.json # Notification channels ├── migrations/ │ └── 001_init_schema.up.sql ├── docker-compose.yml ├── Dockerfile └── entrypoint.sh Core adatmodellek Itt meg fogjuk határozni a „típusokat”, ami lényegében azt jelenti, hogy meg fogjuk határozni, hogy milyen egy „monitorozott szolgáltatás”. Négy „típust” fogunk meghatározni: Asset: Ez egy olyan szolgáltatás, amit ellenőrizni szeretnénk. ProbeResult: Mi történik, amikor ellenőrizzük az eszközt; a válasz, a késleltetés stb. Incidens: Ez nyomon követi, amikor valami rosszul megy, azaz amikor a ProbeResult váratlan választ ad (és amikor a szolgáltatás helyreáll). Értesítés: Ez egy figyelmeztetés vagy üzenet, amelyet a meghatározott kommunikációs csatornára küldenek, például a Teams, a Slack, az e-mail stb. Határozza meg a típusokat a kódban: // internal/models/models.go package models import "time" // Asset represents a monitored service type Asset struct { ID string `json:"id"` AssetType string `json:"assetType"` // http, tcp, dns, etc. Name string `json:"name"` Address string `json:"address"` IntervalSeconds int `json:"intervalSeconds"` TimeoutSeconds int `json:"timeoutSeconds"` ExpectedStatusCodes []int `json:"expectedStatusCodes,omitempty"` Metadata map[string]string `json:"metadata,omitempty"` } // ProbeResult contains the outcome of a single health check type ProbeResult struct { AssetID string Timestamp time.Time Success bool LatencyMs int64 Code int // HTTP status code Message string // Error message if failed } // Incident tracks a service outage type Incident struct { ID string AssetID string StartedAt time.Time EndedAt *time.Time // nil if still open Severity string Summary string } // Notification is what we send to Slack/Teams type Notification struct { AssetID string AssetName string Event string // "DOWN", "RECOVERY", "UP" Timestamp time.Time Details string } Figyeljük meg a Az eszköz típusú mezőben nem minden végpont 200-at ad vissza, egyesek 204-et vagy átirányítást adhatnak vissza. Ez lehetővé teszi, hogy meghatározzuk, mit jelent az „egészséges” az egyes szolgáltatások esetében. ExpectedStatusCodes Adatbázis rendszer Szükségünk van egy helyre a felmérési eredmények és incidensek tárolására. erre a PostgreSQL-t fogjuk használni, és itt van a rendszerünk: -- migrations/001_init_schema.up.sql CREATE TABLE IF NOT EXISTS assets ( id TEXT PRIMARY KEY, name TEXT NOT NULL, address TEXT NOT NULL, asset_type TEXT NOT NULL DEFAULT 'http', interval_seconds INTEGER DEFAULT 300, timeout_seconds INTEGER DEFAULT 5, expected_status_codes TEXT, metadata JSONB, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS probe_events ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), asset_id TEXT NOT NULL REFERENCES assets(id), timestamp TIMESTAMP WITH TIME ZONE NOT NULL, success BOOLEAN NOT NULL, latency_ms BIGINT NOT NULL, code INTEGER, message TEXT ); CREATE TABLE IF NOT EXISTS incidents ( id SERIAL PRIMARY KEY, asset_id TEXT NOT NULL REFERENCES assets(id), severity TEXT DEFAULT 'INITIAL', summary TEXT, started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, ended_at TIMESTAMP ); -- Indexes for common queries CREATE INDEX IF NOT EXISTS idx_probe_events_asset_id_timestamp ON probe_events(asset_id, timestamp DESC); CREATE INDEX IF NOT EXISTS idx_incidents_asset_id ON incidents(asset_id); CREATE INDEX IF NOT EXISTS idx_incidents_ended_at ON incidents(ended_at); A kulcsfontosságú betekintés a Itt az eszköz és az időbélyegzés szerint indexálunk (lefelé sorban), ami lehetővé teszi számunkra, hogy gyorsan lekérdezzük a szolgáltatás vizsgálati eredményeit. probe_events(asset_id, timestamp DESC) A próba rendszer kiépítése Szeretnénk támogatni a többféle protokolltípus felderítését: HTTPS, TCP, DNS stb. anélkül, hogy bonyolult kapcsolási nyilatkozatot kellene írni. Először meg fogjuk határozni, hogy néz ki egy szonda: // internal/probe/probe.go package probe import ( "context" "fmt" "github.com/yourname/status/internal/models" ) // Probe defines the interface for checking service health type Probe interface { Probe(ctx context.Context, asset models.Asset) (models.ProbeResult, error) } // registry holds all probe types var registry = make(map[string]func() Probe) // Register adds a probe type to the registry func Register(assetType string, factory func() Probe) { registry[assetType] = factory } // GetProbe returns a probe for the given asset type func GetProbe(assetType string) (Probe, error) { factory, ok := registry[assetType] if !ok { return nil, fmt.Errorf("unknown asset type: %s", assetType) } return factory(), nil } Végezze el a HTTP-vizsgálatot: // internal/probe/http.go package probe import ( "context" "io" "net/http" "time" "github.com/yourname/status/internal/models" ) func init() { Register("http", func() Probe { return &httpProbe{} }) } type httpProbe struct{} func (p *httpProbe) Probe(ctx context.Context, asset models.Asset) (models.ProbeResult, error) { result := models.ProbeResult{ AssetID: asset.ID, Timestamp: time.Now(), } client := &http.Client{ Timeout: time.Duration(asset.TimeoutSeconds) * time.Second, } req, err := http.NewRequestWithContext(ctx, http.MethodGet, asset.Address, nil) if err != nil { result.Success = false result.Message = err.Error() return result, err } start := time.Now() resp, err := client.Do(req) result.LatencyMs = time.Since(start).Milliseconds() if err != nil { result.Success = false result.Message = err.Error() return result, err } defer resp.Body.Close() // Read body (limit to 1MB) io.ReadAll(io.LimitReader(resp.Body, 1024*1024)) result.Code = resp.StatusCode // Check if status code is expected if len(asset.ExpectedStatusCodes) > 0 { for _, code := range asset.ExpectedStatusCodes { if code == resp.StatusCode { result.Success = true return result, nil } } result.Success = false result.Message = "unexpected status code" } else { result.Success = resp.StatusCode < 400 } return result, nil } Az init() funkció automatikusan fut, amikor a Go alkalmazás elindul. Szeretne TCP próbákat hozzáadni? létrehozása alkalmazza az interfészt, és regisztrálja azt a . tcp.go init() Tervezés és verseny Szükségünk van arra, hogy az összes eszközt ütemtervben vizsgáljuk meg, és ehhez egy munkavállalói csoportot fogunk használni.A munkavállalói csoport lehetővé teszi számunkra, hogy egyszerre több felderítést hajtsunk végre, anélkül, hogy minden egyes szolgáltatásnál goroutine-t teremtenénk. // internal/scheduler/scheduler.go package scheduler import ( "context" "sync" "time" "github.com/yourname/status/internal/models" "github.com/yourname/status/internal/probe" ) type JobHandler func(result models.ProbeResult) type Scheduler struct { workers int jobs chan models.Asset tickers map[string]*time.Ticker handler JobHandler mu sync.Mutex done chan struct{} wg sync.WaitGroup } func NewScheduler(workerCount int, handler JobHandler) *Scheduler { return &Scheduler{ workers: workerCount, jobs: make(chan models.Asset, 100), tickers: make(map[string]*time.Ticker), handler: handler, done: make(chan struct{}), } } func (s *Scheduler) Start(ctx context.Context) { for i := 0; i < s.workers; i++ { s.wg.Add(1) go s.worker(ctx) } } func (s *Scheduler) ScheduleAssets(assets []models.Asset) error { s.mu.Lock() defer s.mu.Unlock() for _, asset := range assets { interval := time.Duration(asset.IntervalSeconds) * time.Second ticker := time.NewTicker(interval) s.tickers[asset.ID] = ticker s.wg.Add(1) go s.scheduleAsset(asset, ticker) } return nil } func (s *Scheduler) scheduleAsset(asset models.Asset, ticker *time.Ticker) { defer s.wg.Done() for { select { case <-s.done: ticker.Stop() return case <-ticker.C: s.jobs <- asset } } } func (s *Scheduler) worker(ctx context.Context) { defer s.wg.Done() for { select { case <-s.done: return case asset := <-s.jobs: p, err := probe.GetProbe(asset.AssetType) if err != nil { continue } result, _ := p.Probe(ctx, asset) s.handler(result) } } } func (s *Scheduler) Stop() { close(s.done) close(s.jobs) s.wg.Wait() } Minden eszköz saját ticker goroutine-t kap, amely csak ütemterveket működtet. Amikor eljön az idő egy eszköz ellenőrzésére, a ticker egy felderítő munkát küld egy csatornába. Van egy rögzített számú munkavállalói goroutine, amely hallgatja a csatornát, és végzi a tényleges felderítést. Nem futtatjuk a szondákat közvetlenül a ticker goroutine-ben, mert a szondák blokkolhatják a hálózati válaszok vagy időzítések várakozását. Például 4 alkalmazottal és 100 eszközzel csak 4 szonda fut bármikor, még akkor is, ha a tickers egyidejűleg lő. Biztosítani kell, hogy minden munkavállaló tiszta legyen. sync.WaitGroup Incident Detection: Az állami gép Amikor egy felderítés meghibásodik, nem feltételezzük automatikusan a meghibásodást. Ez hálózati meghibásodás lehet. Ha azonban ismét meghibásodik, eseményt hozunk létre. Amikor helyreáll, bezárjuk az eseményt, és értesítjük. Ez egy állami gép: fel → le → fel. Így építsd fel a motort: // internal/alert/engine.go package alert import ( "context" "fmt" "sync" "time" "github.com/yourname/status/internal/models" "github.com/yourname/status/internal/store" ) type NotifierFunc func(ctx context.Context, notification models.Notification) error type AssetState struct { IsUp bool LastProbeTime time.Time OpenIncidentID string } type Engine struct { store store.Store notifiers map[string]NotifierFunc mu sync.RWMutex assetState map[string]AssetState } func NewEngine(store store.Store) *Engine { return &Engine{ store: store, notifiers: make(map[string]NotifierFunc), assetState: make(map[string]AssetState), } } func (e *Engine) RegisterNotifier(name string, fn NotifierFunc) { e.mu.Lock() defer e.mu.Unlock() e.notifiers[name] = fn } func (e *Engine) Process(ctx context.Context, result models.ProbeResult, asset models.Asset) error { e.mu.Lock() defer e.mu.Unlock() state := e.assetState[result.AssetID] state.LastProbeTime = result.Timestamp // State hasn't changed? Nothing to do. if state.IsUp == result.Success { e.assetState[result.AssetID] = state return nil } // Save probe event if err := e.store.SaveProbeEvent(ctx, result); err != nil { return err } if result.Success && !state.IsUp { // Recovery! return e.handleRecovery(ctx, asset, state) } else if !result.Success && state.IsUp { // Outage! return e.handleOutage(ctx, asset, state, result) } return nil } func (e *Engine) handleOutage(ctx context.Context, asset models.Asset, state AssetState, result models.ProbeResult) error { incidentID, err := e.store.CreateIncident(ctx, asset.ID, fmt.Sprintf("Service %s is down", asset.Name)) if err != nil { return err } state.IsUp = false state.OpenIncidentID = incidentID e.assetState[asset.ID] = state notification := models.Notification{ AssetID: asset.ID, AssetName: asset.Name, Event: "DOWN", Timestamp: result.Timestamp, Details: result.Message, } return e.sendNotifications(ctx, notification) } func (e *Engine) handleRecovery(ctx context.Context, asset models.Asset, state AssetState) error { if state.OpenIncidentID != "" { e.store.CloseIncident(ctx, state.OpenIncidentID) } state.IsUp = true state.OpenIncidentID = "" e.assetState[asset.ID] = state notification := models.Notification{ AssetID: asset.ID, AssetName: asset.Name, Event: "RECOVERY", Timestamp: time.Now(), Details: "Service has recovered", } return e.sendNotifications(ctx, notification) } func (e *Engine) sendNotifications(ctx context.Context, notification models.Notification) error { for name, notifier := range e.notifiers { if err := notifier(ctx, notification); err != nil { fmt.Printf("notifier %s failed: %v\n", name, err) } } return nil } Kulcsfontosságú betekintés: nyomon követjük az állapotot a memóriában gyors keresésekhez, de fennmarad az incidensek az adatbázisban a tartósság érdekében. Ha a folyamat újraindul, újraépíthetjük az állapotot a nyitott incidensekből. assetState Értesítések küldése Abban az esetben, ha valami megszakad, az embereknek tudniuk kell. Küldjük az értesítést a különböző kommunikációs csatornákra. Határozzuk meg csapatunk értesítőjét: // internal/notifier/teams.go package notifier import ( "bytes" "context" "encoding/json" "fmt" "net/http" "time" "github.com/yourname/status/internal/models" ) type TeamsNotifier struct { webhookURL string client *http.Client } func NewTeamsNotifier(webhookURL string) *TeamsNotifier { return &TeamsNotifier{ webhookURL: webhookURL, client: &http.Client{Timeout: 10 * time.Second}, } } func (t *TeamsNotifier) Notify(ctx context.Context, n models.Notification) error { emoji := "🟢" if n.Event == "DOWN" { emoji = "🔴" } card := map[string]interface{}{ "type": "message", "attachments": []map[string]interface{}{ { "contentType": "application/vnd.microsoft.card.adaptive", "content": map[string]interface{}{ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.4", "body": []map[string]interface{}{ { "type": "TextBlock", "text": fmt.Sprintf("%s %s - %s", emoji, n.AssetName, n.Event), "weight": "Bolder", "size": "Large", }, { "type": "FactSet", "facts": []map[string]interface{}{ {"title": "Service", "value": n.AssetName}, {"title": "Status", "value": n.Event}, {"title": "Time", "value": n.Timestamp.Format(time.RFC1123)}, {"title": "Details", "value": n.Details}, }, }, }, }, }, }, } body, _ := json.Marshal(card) req, _ := http.NewRequestWithContext(ctx, "POST", t.webhookURL, bytes.NewReader(body)) req.Header.Set("Content-Type", "application/json") resp, err := t.client.Do(req) if err != nil { return err } defer resp.Body.Close() if resp.StatusCode >= 300 { return fmt.Errorf("Teams webhook returned %d", resp.StatusCode) } return nil } A Teams adaptív kártyákat használ a gazdag formázáshoz.Egyéb kommunikációs csatornák, például a Slack, a Discord stb. különböző értesítőit is definiálhatja. A maradék tűz Szükségünk van a végpontokra, hogy lekérdezzük az általunk monitorozott szolgáltatások állapotát. Ehhez a Chi-t fogjuk használni, amely egy könnyű útválasztó, amely támogatja az útvonalparamétereket, mint például . /assets/{id} Határozza meg az Apis: // internal/api/handlers.go package api import ( "encoding/json" "net/http" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" "github.com/yourname/status/internal/store" ) type Server struct { store store.Store mux *chi.Mux } func NewServer(s store.Store) *Server { srv := &Server{store: s, mux: chi.NewRouter()} srv.mux.Use(middleware.Logger) srv.mux.Use(middleware.Recoverer) srv.mux.Route("/api", func(r chi.Router) { r.Get("/health", srv.health) r.Get("/assets", srv.listAssets) r.Get("/assets/{id}/events", srv.getAssetEvents) r.Get("/incidents", srv.listIncidents) }) return srv } func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) { s.mux.ServeHTTP(w, r) } func (s *Server) health(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(map[string]string{"status": "healthy"}) } func (s *Server) listAssets(w http.ResponseWriter, r *http.Request) { assets, err := s.store.GetAssets(r.Context()) if err != nil { http.Error(w, err.Error(), 500) return } w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(assets) } func (s *Server) getAssetEvents(w http.ResponseWriter, r *http.Request) { id := chi.URLParam(r, "id") events, _ := s.store.GetProbeEvents(r.Context(), id, 100) w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(events) } func (s *Server) listIncidents(w http.ResponseWriter, r *http.Request) { incidents, _ := s.store.GetOpenIncidents(r.Context()) w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(incidents) } A fenti kód egy kis HTTP API-kiszolgálót határoz meg, amely 4 olvasható végpontot tár fel: GET /api/health - Egészségügyi ellenőrzés (a szolgáltatás működik?) GET /api/assets - Az összes monitorozott szolgáltatás listája GET /api/assets/{id}/events - Szerezze be egy adott szolgáltatás felmérési előzményeit GET /api/incidents - Nyitott incidensek listája Dockerizálja az alkalmazást Az alkalmazás dockerizálása meglehetősen egyenesen halad előre, mivel a Go egyetlen binárisra kompilál. Egy többlépcsős felépítést fogunk használni, hogy a végső képet kicsi legyen: # Dockerfile FROM golang:1.24-alpine AS builder WORKDIR /app RUN apk add --no-cache git COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o statusd ./cmd/statusd/ FROM alpine:latest WORKDIR /app RUN apk --no-cache add ca-certificates COPY --from=builder /app/statusd . COPY entrypoint.sh . RUN chmod +x /app/entrypoint.sh EXPOSE 8080 ENTRYPOINT ["/app/entrypoint.sh"] Az utolsó szakasz csak az Alpine plusz a bináris - általában 20 MB alatt. A bemeneti script a környezeti változókból építi fel az adatbázis-kapcsolatláncot: #!/bin/sh # entrypoint.sh DB_HOST=${DB_HOST:-localhost} DB_PORT=${DB_PORT:-5432} DB_USER=${DB_USER:-status} DB_PASSWORD=${DB_PASSWORD:-status} DB_NAME=${DB_NAME:-status_db} DB_CONN_STRING="postgres://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}" exec ./statusd \ -manifest /app/config/manifest.json \ -notifiers /app/config/notifiers.json \ -db "$DB_CONN_STRING" \ -workers 4 \ -api-port 8080 Docker Compose: Összeállítva Egy fájl, amely mindegyiküket szabályozza: # docker-compose.yml version: "3.8" services: postgres: image: postgres:15-alpine container_name: status_postgres environment: POSTGRES_USER: status POSTGRES_PASSWORD: changeme POSTGRES_DB: status_db volumes: - postgres_data:/var/lib/postgresql/data - ./migrations:/docker-entrypoint-initdb.d healthcheck: test: ["CMD-SHELL", "pg_isready -U status"] interval: 10s timeout: 5s retries: 5 networks: - status_network statusd: build: . container_name: status_app environment: - DB_HOST=postgres - DB_PORT=5432 - DB_USER=status - DB_PASSWORD=changeme - DB_NAME=status_db volumes: - ./config:/app/config:ro depends_on: postgres: condition: service_healthy networks: - status_network prometheus: image: prom/prometheus:latest container_name: status_prometheus volumes: - ./docker/prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus networks: - status_network depends_on: - statusd grafana: image: grafana/grafana:latest container_name: status_grafana environment: GF_SECURITY_ADMIN_USER: admin GF_SECURITY_ADMIN_PASSWORD: admin volumes: - grafana_data:/var/lib/grafana networks: - status_network depends_on: - prometheus nginx: image: nginx:alpine container_name: status_nginx volumes: - ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./docker/nginx/conf.d:/etc/nginx/conf.d:ro ports: - "80:80" depends_on: - statusd - grafana - prometheus networks: - status_network networks: status_network: driver: bridge volumes: postgres_data: prometheus_data: grafana_data: Néhány dolog, amit meg kell jegyezni: PostgreSQL egészségügyi ellenőrzés: A statusd szolgáltatás addig vár, amíg a Postgres ténylegesen készen áll, nem csak elindult. Config mount: Mi mount ./config mint csak olvasható. Szerkessze a manifesztet helyi szinten, és a futó konténer látja a változásokat. Nginx: A külső forgalmat a Grafana és a Prometheus eszköztárakra irányítja. Konfigurációs fájlok Az alkalmazás két fájlt olvashat: és manifest.json notifiers.json The file lists the assets we want to monitor. Each asset needs an ID, a probe type, and an address. The controls how often we check (60 = once per minute). lets you define what "healthy" means. Some endpoints return 301 redirects or 204 No Content, and that's fine. manifest.json intervalSeconds expectedStatusCodes // config/manifest.json { "assets": [ { "id": "api-prod", "assetType": "http", "name": "Production API", "address": "https://api.example.com/health", "intervalSeconds": 60, "timeoutSeconds": 5, "expectedStatusCodes": [200], "metadata": { "env": "prod", "owner": "platform-team" } }, { "id": "web-prod", "assetType": "http", "name": "Production Website", "address": "https://www.example.com", "intervalSeconds": 120, "timeoutSeconds": 10, "expectedStatusCodes": [200, 301] } ] } The controls where to send alerts. You define notification channels (Teams, Slack), then set policies for which channels fire on which events. means you won't get spammed more than once every 5 minutes for the same issue. notifiers.json throttleSeconds: 300 // config/notifiers.json { "notifiers": { "teams": { "type": "teams", "webhookUrl": "https://outlook.office.com/webhook/your-webhook-url" } }, "notificationPolicy": { "onDown": ["teams"], "onRecovery": ["teams"], "throttleSeconds": 300, "repeatAlerts": false } } futtatni docker-compose up -d Öt szolgáltatás spin up: A PostgreSQL tárolja az adatait A StatusD teszteli szolgáltatásait Prometheus metrikákat gyűjt Grafana megjeleníti a műszerfalakat (http://localhost:80) Nginx Routes mindent Ellenőrizze a logókat: docker logs -f status_app Meg kell látnod: Loading assets manifest... Loaded 2 assets Loading notifiers config... Loaded 1 notifiers Connecting to database... Starting scheduler... [✓] Production API (api-prod): 45ms [✓] Production Website (web-prod): 120ms Összefoglaló Most már van egy ellenőrző rendszer, amely: A szolgáltatások olvasása egy JSON-konfigurációból Próbálja ki őket egy ütemtervben egy munkavállalói medencével Megszakítások észlelése és incidensek létrehozása Értesítések küldése a Teams/Slack A Prometheus metrikák kiállítása Docker használata egyetlen parancsbal Ez a bemutató segíteni fog egy működő monitorozási rendszer telepítésében. Azonban több van a fedél alatt, amit átláttunk. Az áramkör-megszakítók megakadályozzák a kaszkadáló meghibásodásokat, amikor egy szolgáltatás meghibásodik Többszintű emelkedési riasztó menedzserek, ha a mérnök nem válaszol a hívásra A figyelmeztetés duplikálása megakadályozza az értesítési viharokat Az adaptív szondaintervallumok gyakrabban ellenőrizhetők incidensek során Hot-reload konfiguráció a szolgáltatás újraindítása nélkül SLA számítások és megfelelőségi nyomon követés