Behovet
Tre tjänster ska kunna följas separat. Driftstopp och långsam respons behöver gå att upptäcka snabbt, samtidigt som lösningen ska vara begriplig att förvalta.
Portfolio · Zabbix 7.0 LTS · lokalt verifierad
Övervakning som går att starta, testa och felsöka.
TrafficWatch är ett containerbaserat övervakningslabb för tre simulerade transporttjänster. Projektet visar hur driftbehov kan omsättas till mätvärden, larm, automation, incidentövningar och dokumenterade återställningsvägar.
Avgränsning: Fristående portfolio-labb. Ingen koppling till Trafikverkets interna system eller produktionsmiljöer.
Zabbixserver, webb och Agent 2
Dockerreproducerbar lokal miljö
AutomationPython och Bash
Incidentstoppa, upptäck, felsök, återställ
Driftrunbook, backup, test och säkerhet
Från behov till teknisk lösning
Inte bara en installerad dashboard.
Projektet är byggt för att visa hela kedjan: design, driftsättning, datainsamling, larmmodell, felsökning, återställning och dokumentation.
Designen
Zabbix Server, webbgränssnitt, PostgreSQL, Agent 2 och mål-API:er separeras i Docker Compose. Konfiguration och driftsteg versionsstyras tillsammans med koden.
Verifieringen
Zabbix-servern och samtliga tre API:er körs lokalt. Hälsosvar, systemversion och startflöde är verifierade; provisionering och incidentövningar ingår som skript.
Faktisk körning
Lokalt verifierad miljö.
Bilderna nedan är beskurna från den lokala körningen: Zabbix 7.0.29 rapporterar att servern är igång och de tre mål-API:erna returnerar status ok.
Zabbix server
Server och frontend svarar.
Systeminformationen visar Zabbix Server och frontend i version 7.0.29 samt aktiv serveranslutning.
Arkitektur
Separata komponenter. Tydliga felgränser.
Databas, Zabbix-server, webbgränssnitt, agent och måltjänster körs separat. Det gör miljön enklare att felsöka, byta ut och skala vidare.
OPERATÖRZabbix Webport 8080
status · problem · konfiguration
ÖVERVAKNINGZabbix Serverpollers · triggers · historik
AGENTZabbix Agent 2Linux- och containermått
DATALAGERPostgreSQLkonfiguration och historik
HTTP-kontroller · status · svarstid
Road APIRail APIFerry API
Det jag byggde
Sex leveranser i samma repository.
Compose-miljö
Sju separata tjänster, healthchecks, beständig databasvolym och nätverk med tydliga beroenden.
Övervakningsmål
Road, Rail och Ferry API med normal hälsa, medvetet långsam endpoint och kontrollerat 503-fel.
API-provisionering
Idempotent Python-skript för värdgrupp, värdar, HTTP-items, triggers och tags i Zabbix.
Incidentövningar
Bash-skript som stoppar och återställer en vald tjänst utan att förstöra databas eller konfiguration.
Backup och kontroll
PostgreSQL-backup med komprimering och SHA-256-kontrollsumma samt separat hälsokontroll.
Driftdokumentation
Arkitektur, operationsmanual, incident-runbook, säkerhetsbedömning, testplan och intervjunoteringar.
Kontrollerad incident
Från grön signal till återställd tjänst.
Incidentflödet är avsiktligt enkelt att repetera. Poängen är inte dramatik; poängen är att bevisa upptäckt, diagnos och återställning.
- 01
Verifiera baslinjen
Kontrollera att Zabbix och samtliga tjänster svarar.
./scripts/healthcheck.sh - 02
Skapa driftstopp
Stoppa Rail API genom ett säkert testskript.
./scripts/simulate_incident.sh rail - 03
Avgränsa felet
Kontrollera containerstatus, loggar och endpoint.
docker compose logs --tail=200 rail-api - 04
Återställ och verifiera
Starta tjänsten och bekräfta nya mätvärden.
./scripts/restore_service.sh rail
Ärlig omfattning
Vad projektet visar — och vad det inte påstår.
Praktisk systemförståelse
- Design och driftsättning av en flerkomponentsmiljö
- Linux, containers, PostgreSQL och Zabbix
- Skriptutveckling i Python och Bash
- Övervakningslogik, triggers och incidentflöden
- Testbarhet, backup, säkerhet och dokumentation
Ett labb — inte lånad senioritet
- Projektet är lokalt och fristående, inte en produktionsmiljö
- Det ersätter inte flerårig drift i en stor organisation
- HA, SSO, TLS och Zabbix proxies är dokumenterade nästa steg
- Påståenden hålls till sådant som finns i koden eller har verifierats lokalt
- Ingen koppling finns till en arbetsgivares interna infrastruktur
Nästa nivå
Så skulle labben utvecklas för större drift.
Distribuerad insamling
Zabbix proxy per nätsegment eller geografiskt område.
Säker åtkomst
TLS, SSO, rollbaserad behörighet och extern secrets manager.
Hög tillgänglighet
HA för Zabbix Server och PostgreSQL samt verifierade återställningstester.
Förvaltning
Versionsstyrda templates, SLA/SLO, underhållsfönster och change-process.
Källkod och dokumentation
Hela lösningen går att granska.
Repositoryt innehåller Compose-filen, servicekoden, provisioneringsskript, driftverktyg och samtliga tekniska dokument.