Monitoring i alerty

Jakie metryki monitorujemy?

Zapewniamy kompleksowy monitoring serwerów i klastrów Kubernetes za pomocą naszych otwartych frameworków operacyjnych — LinuxAid i KubeAid — opartych na Prometheusie.

1. Monitoring serwerów (LinuxAid)

W przypadku serwerów wszystkie metryki i reguły alertów są zdefiniowane w naszym stosie LinuxAid tutaj:

Obejmują one:

• metryki hosta i sprzętu
• CPU, RAM, I/O i kondycję dysków
• monitoring systemów plików i pamięci masowej
• wydajność sieci

Te reguły są utrzymywane jako open source i regularnie aktualizowane, a napisaliśmy też dla nich zestaw testów.

2. Monitoring Kubernetesa (KubeAid)

W środowiskach Kubernetes jako podstawy używamy Kube Prometheus i rozszerzamy go o dodatkowe reguły i mixiny.

Bazowe reguły alertów:

Dodatkowe alerty i mixiny:

Nasze alerty Kubernetes obejmują:

• metryki węzłów, podów i kontenerów
• kondycję warstwy sterowania i serwera API
• wydajność i dostępność etcd
• sygnały schedulera i controller-managera
• kondycję ingressu, usług i sieci
• alerty na poziomie aplikacji dla wybranych komponentów open source
• opcjonalne pakiety alertów oparte na mixinach, które można włączać i wyłączać dla każdego klastra

Takie warstwowe podejście zapewnia widoczność całej platformy z elastycznością dopasowania do stosu każdego klienta.

Jak obsługujemy alerty i eskalację incydentów

Prometheus kieruje alerty do naszego centralnego endpointu odbioru alertów (na życzenie można wykluczyć wybrane hosty lub komponenty). Alerty są następnie przetwarzane przez naszą wewnętrzną platformę operacyjną, która:

• automatycznie tworzy lub aktualizuje zgłoszenia alertów
• powiadamia nasz zespół operacyjny 24/7
• stosuje twoje SLA, aby poprawnie ustalić priorytety i terminy
• śledzi w czasie rzeczywistym potwierdzenia i postęp rozwiązywania
• przeprowadza automatyczne eskalacje — najpierw do dyżurnego inżyniera, a w razie potrzeby do kierownictwa
• część naszych alertów ma charakter wyprzedzający, tzn. uruchamia się, zanim coś się zepsuje lub przestanie działać.

Zawsze najpierw jak najszybciej przywracamy działanie usługi, a potem zajmujemy się przyczyną źródłową, aby problem się nie powtórzył.