Overvågning og advarsler

Hvilke metrikker overvåger vi?

Vi tilbyder omfattende overvågning på tværs af servere og Kubernetes-klynger ved hjælp af vores open source-driftsframeworks - LinuxAid og KubeAid - drevet af Prometheus.

1. Serverovervågning (LinuxAid)

For servere er alle metrikker og advarslingsregler defineret i vores LinuxAid-stak.

Du kan se den komplette liste over PromQL-målinger og alarmregler her:

Disse inkluderer:

• Vært- og hardwaremålinger
• CPU, RAM, I/O, disktilstand
• Filsystem- og lagerovervågning
• Netværksydelse

Disse regler vedligeholdes som open source, opdateres regelmæssigt, og vi har også skrevet en testsuite til dem.

2. Kubernetes-overvågning (KubeAid)

Til Kubernetes-miljøer bruger vi Kube Prometheus som vores fundament og udvider det med yderligere regler og mixins.

Grundlæggende alarmregler:

Yderligere alarmer og mixins:

Vores Kubernetes-alarmer inkluderer:

• Node-, pod- og containermålinger
• Kontrolplan- og API-servertilstand
• etcd-ydeevne og tilgængelighed
• Scheduler- og controller-managersignaler
• Ingress-, service- og netværkstilstand
• Alarmer på applikationsniveau for udvalgte open source-komponenter
• Valgfrie mixin-baserede alarmpakker, der kan aktiveres eller deaktiveres pr. klynge

Denne lagdelte tilgang sikrer platformomfattende synlighed med fleksibiliteten til at tilpasse sig hver kundes stak.

Sikkerhedsovervågning og afhjælpning

Rettelser rulles ud i de servicevinduer, du vælger. Kræver en rettelse en ændring i konfigurations-repositoryet, fx en ny KubeAid-version eller snapshot-dato, kommer den først som en branch, der skal merges.

Servere (LinuxAid)

• Kendte sårbarheder. Portalen viser hver servers åbne CVE'er med alvorlighed og næste opdateringsvindue.
• End of life. En alarm fra 75 dage før OS-versionen holder op med at få gratis sikkerhedsopdateringer. Har versionen betalt udvidet support, bliver alarmen ved, indtil den også udløber.
• Firewall. Hver server rapporterer firewallens pakketal pr. regel som metrikker, men der udløses ingen alarm på droppet trafik.
• Hærdning. SSH tillader kun stærke nøgleudvekslinger, ciphers og MACs, undtagen på RHEL 6. SELinux og auditd kan slås til pr. server.
• Repo-snapshots. Hvor din konfiguration fastlåser en snapshot-dato, kommer pakkerne fra det snapshot. Dagen før hver opdateringscyklus åbner vi en pull request, der rykker datoen frem, så alle servere i cyklussen får de samme opdateringer.

Kubernetes (KubeAid)

• Supply chain-sikkerhed.
  • Image-scanning. Trivy scanner de container-images, du kører, og gemmer de kritiske og høje fund, der har en rettelse. På klynger, der rapporterer til Obmondo, viser portalen dem.
  • Registry-spejl. Harbor kan spejle de images og også scanne dem.
• Firewall. Cilium-netværkspolitikker filtrerer indgående og udgående trafik. Cilium eksporterer hver droppet pakke som en Hubble-metrik, men der udløses ingen alarm, når afvist trafik bliver ved med at være høj.
• Runtime-sikkerhed. Tetragon registrerer procesafvikling, indlæsning af kernemoduler og ændringer af rettigheder og følger først netværks- og filadgang, når der er tilføjet en politik til det. KubeArmor kan blokere det, dine politikker forbyder.
• Admission-politikker. Kyverno eller Gatekeeper kan stoppe workloads, der bryder dine regler, før de starter.

Image-scanning, runtime-overvågning og admission-politikker er valg, du slår til pr. klynge.

Sådan håndterer vi advarsler og eskalering af hændelser

Prometheus sender advarsler til vores centrale endepunkt for indtagelse af advarsler (med mulighed for at ekskludere værter eller komponenter efter anmodning). Advarsler behandles derefter af vores interne driftsplatform, som:

• Automatisk opretter eller opdaterer advarsler
• Giver vores døgnåbne driftsteam besked
• Anvender din SLA til korrekt prioritering og fastsættelse af deadlines
• Sporer bekræftelse og løsningsstatus i realtid
• Udfører automatiserede eskaleringer - først til den vagthavende tekniker, derefter til ledelsen, hvis det er nødvendigt
• Nogle af vores advarsler er forebyggende, dvs. brand, før ting kan nedbrydes/nedbrydes.

Vi prioriterer altid at genoprette tjenesten så hurtigt som muligt og fokuserer derefter på at adressere rodårsagen for at forhindre fremtidig gentagelse.