Pod okiem 4000 serwerów Discord: Grafana, PostHog i to, co nam pokazały

AlphaCloud działa na nieco ponad 4000 serwerach Discord, rozłożonych na cztery shardy. To cztery procesy, z których każdy obsługuje część serwerów, a wszystkie rozmawiają z tym samym API.

Przy takiej skali problem rzadko pokazuje się przez to, że coś się psuje. Znacznie częściej wszystko działa, tylko drożej, wolniej albo głośniej, niż powinno. Dlatego we wrześniu 2026 przebudowaliśmy nasz monitoring. Ten artykuł pokazuje, jak wygląda i co pokazał nam w pierwszych tygodniach.

Dwa narzędzia, dwa pytania

Grafana odpowiada na pytanie: co robi bot? Bot i API wysyłają metryki do Prometheusa (zapytania, czasy odpowiedzi, odsetek błędów, odpowiedzi Discorda, użycie AI), a logi trafiają do Loki. Każdy węzeł serwerowy ma własny stos, a Grafana jest dostępna tylko przez sieć prywatną, nie z internetu.

PostHog odpowiada na pytanie: czego doświadczają ludzie na naszych stronach? Odsłony, błędy przeglądarki, czasy ładowania i, za zgodą, nagrane sesje. PostHog uruchamia się dopiero po zgodzie w banerze cookie.

Podział jest celowy. Grafana patrzy na maszyny, PostHog na interfejsy. Kto wciśnie jedno i drugie w jedno narzędzie, dostanie albo dane użytkowników w logach serwera, albo obciążenie serwera w analityce produktu.

Co znalazł

Pętla, która generowała połowę ruchu

Ankiety z czasem zakończenia zamyka zadanie w tle, które co minutę sprawdza, czy coś wygasło. Robiło to dla każdego serwera osobno. Przy około 1000 serwerów na shard i czterech shardach dawało to około 70 zapytań na sekundę, z których prawie wszystkie odpowiadały "nic nie wygasło".

Zauważyliśmy to dopiero w Grafanie, gdy rozbiliśmy zapytania bota do API według ścieżek: ten jeden endpoint stanowił ponad połowę całego ruchu. Wszystko działało. Po prostu dźwigało obciążenie, o które nikt nie prosił.

Teraz każdy shard pyta raz na minutę: "Które serwery w ogóle mają wygasłą ankietę?" i pobiera szczegóły tylko dla nich. Z około 4200 zapytań na minutę zrobiły się mniej więcej cztery.

Trzy miliony razy "nie skonfigurowano"

Ten sam wzorzec, inne miejsce: kilka modułów (wpisy supportu, nieobecności, lista zespołu, statystyki bota, newsletter) w swoich pętlach regularnie odczytywało ustawienia każdego serwera. Na większości serwerów dany moduł w ogóle nie jest skonfigurowany, więc odpowiedź brzmiała "nie znaleziono". Około trzech milionów razy dziennie.

Poprawka jest niespektakularna: "nie skonfigurowano" jest teraz zapamiętywane na 30 minut. To bezpieczne tylko dlatego, że każdy z tych modułów wysyła botowi aktualizację w chwili zapisania w panelu webowym, więc skonfigurowanie modułu nigdy nie oznacza czekania 30 minut.

Awarie Discorda to nie nasze błędy

Nasz kanał błędów zespołu publikował każdą nieudaną akcję jako "Runtime Error", z unikalnym identyfikatorem i wszystkim, co trzeba. Także w chwilach, gdy sam Discord odpowiadał błędem serwera. To ani błąd po naszej stronie, ani coś, co możemy naprawić, a w kanale wyglądało dokładnie jak prawdziwa usterka.

Dziś jest to logowane jako ostrzeżenie, a członek dostaje informację, żeby spróbował ponownie za kilka sekund, zamiast linku do zgłoszenia błędu. Kanał błędów, w którym połowa wiadomości to nie błędy, w końcu przestaje być czytany. I wtedy przegapia się ten prawdziwy.

Atak, który trwał minutę

Pewnego popołudnia pod koniec września nasza strona główna dostała w ciągu jednej minuty nieco ponad 500 000 zapytań, z wielu krajów naraz. Większość została zatrzymana, zanim dotarła do naszych serwerów, a minutę później ruch wrócił do normy.

Nie zobaczyliśmy tego dlatego, że coś padło. Zobaczyliśmy to, bo liczba nie pasowała do reszty wykresu. To właściwe zadanie monitoringu: nie bić na alarm, gdy wszystko płonie, tylko pokazywać, gdzie coś nie pasuje do normy.

Czego nasz monitoring celowo nie widzi

Zasady są tu tak samo ważne jak pulpity:

• Żadnych adresów IP odwiedzających w logach. Obiecuje to nasza polityka prywatności, więc usuwamy je w dwóch miejscach: przy zapisie logu dostępu i jeszcze raz przed jego zapisaniem w bazie.
• Żadnych ID serwerów, użytkowników ani wiadomości w metrykach. Każda metryka jest dzielona tylko według ogólnych cech (moduł, klasa statusu, shard). To chroni dane i utrzymuje bazę metryk w małym rozmiarze.
• Nagrania sesji pokazują nasz interfejs, a nie twoją treść. Czytelny pozostaje tylko tekst pochodzący słowo w słowo z naszych plików tłumaczeń. Nazwy serwerów, kanałów i użytkowników, dane wejściowe i podglądy są maskowane. Jeśli listy dozwolonych tekstów nie da się wczytać, maskowane jest wszystko.
• Wszystko na stronie dopiero po zgodzie. Co sprawia, że tamtejsze liczby to dolna granica. Prawdziwe liczby odsłon odczytujemy z anonimowych sum naszego dostawcy sieci.

Szczegóły są w polityce prywatności.

Co z tego wynosimy

To, co drogie, rzadko jest tym, co zepsute. Żadne z powyższych znalezisk nie wywołało błędu. Wywołały obciążenie, koszty i hałas, a bez pomiarów nie widzi się żadnej z tych rzeczy.

Pytanie o każdy serwer osobno się nie skaluje. Oba duże znaleziska miały ten sam wzorzec: pętla po wszystkich serwerach, która pyta o każdy z osobna. Odpowiedzią jest prawie zawsze to samo pytanie, zadane raz dla wszystkich.

Alarm musi być rzadki, inaczej nie jest alarmem. Dlatego tylko Grafana pinguje zespół, i to tylko w sprawach, które wymagają czyjejś interwencji. Nowe rodzaje błędów z PostHog trafiają na kanał bez pingu.

Jeśli sam prowadzisz serwer Discord i chcesz zobaczyć wspomniane tu moduły: ankiety, wpisy supportu i nieobecności są w panelu webowym, a opisuje je dokumentacja.