Przegląd
VictoriaLogs na Cloudzy daje ci szybką, samodzielnie hostowaną bazę danych logów, którą w pełni kontrolujesz. Uruchom pojedynczy węzeł do prac deweloperskich lub większą maszynę na potrzeby produkcji, a następnie skieruj Vector, Fluent Bit, lub syslog i zacznij wykonywać zapytania w ciągu kilku sekund. Dedykowane vCPUy EPYC, RAM oparty wyłącznie na NVMe i łącze 10 Gbps zapewniają płynne przyjmowanie danych i szybkie zapytania nawet przy szczytowym ruchu. Rozliczanie godzinowe pozwala zwiększać zasoby w godzinach wzmożonego ruchu i ograniczać je w spokojniejszych momentach.
Opis
Ten obraz instalacyjny zawiera VictoriaLogs wewnątrz Docker z lekką owijką systemd oraz przydatnymi narzędziami pomocniczymi, takimi jak Grafana, Vector, vmauth, vmalert, Alertmanageroraz VictoriaMetrics jeden węzeł dla metryk. VictoriaLogs nasłuchuje na natywnym porcie HTTP i jest gotowy do przyjmowania logów oraz odpowiadania na zapytania od razu po uruchomieniu. Szczegóły dotyczące modelu danych, metod ingestion i wzorców zapytań znajdziesz w oficjalnej dokumentacji.
Uzyskaj dostęp do interfejsu webowego
Zacznij od sprawdzenia usług już działających na Twoim serwerze. Zastąp <SERVER-IP> adresem IP swojej instancji.
- VictoriaLogs: http://<SERVER-IP>:9428 (ingestion, zapytania i metryki pod adresem /metrics).
- Grafana: http://<SERVER-IP>:3000 (pierwsze logowanie to admin /admin, a następnie zmień to).
- VictoriaMetrics jeden węzeł: http://<SERVER-IP>:8428 dla metryk zgodnych z Prometheus.
- vmalert Interfejs użytkownika i API: http://<SERVER-IP>:8880.
- vmauth brama: http://<SERVER-IP>:8427 do uwierzytelniania i routingu.
- Alertmanager: http://<SERVER-IP>:9093.
- Vector API i interfejs użytkownika: http://<SERVER-IP>:8686 jeśli włączony w vector config.
Sterowanie usługami na pierwszy dzień działania:
| sudo systemctl początek victoria-logs sudo systemctl stop victoria-logs sudo systemctl status victoria-logs docker ps |
Zaawansowane funkcje
Oto praktyczne ulepszenia, które mają znaczenie dla bazy danych logów na własnej infrastrukturze. Zmniejszają opóźnienia zapytań, utrzymują płynny ingest podczas skoków obciążenia i umożliwiają szybki rollback, gdy aktualizacja zachowuje się niepoprawnie.
- Dedykowane vCPUs i DDR5 RAM aby uniknąć przestojów spowodowanych zakłóceniami sąsiadów przy równoczesnych operacjach zapisu i odczytu.
- Czyste storage NVMe dla wysokiego IOPS przy WAL, budowaniu indeksów i kompakcjach.
- 10 Gbps network port dla wielu klientów wysyłających logi z dużą częstotliwością i licznych użytkowników dashboardów.
- Migawki na żądanie i rollback przed aktualizacjami lub zmianami schematu.
- Rozliczenia godzinowe oznacza, że klony do testów staging lub testów obciążeniowych kosztują tylko tyle, ile godzin je utrzymujesz.
Pojedyncze uruchomienie ponownie stosuje każdą zmianę rozmiaru. Nie są potrzebne migracje danych ani edycja DNS.
Łatwość użycia
Masz do dyspozycji przejrzysty panel do restartowania, tworzenia migawek i migracji regionów. Skieruj Vector or Fluent Bit to http://<SERVER-IP>:9428 dla HTTP JSON ingestion lub włącz odbiorniki syslog w VictoriaLogs, jeśli wolisz TCP albo UDP 514. Przykładowe konfiguracje znajdziesz w dokumentacji, a zaczynając od domyślnych pól, możesz stopniowo dodawać strukturę.
Fokus na wydajność
Jeśli Twój zespół osadza Grafana panele w publicznych stronach statusu lub wewnętrznych portalach, krótszy czas do pierwszego bajtu i szybsze zapytania ad hoc sprawiają, że strony działają błyskawicznie. NVMe I/O i łącze 10 Gbps utrzymują stabilne czasy odpowiedzi, gdy wielu użytkowników jednocześnie odpytuje duże okna czasowe.
Pełna kontrola nad stroną
Masz uprawnienia root. Dostosuj retencję, przycinaj indeksy, konfiguruj vmauth użytkowników i kieruj alerty przez vmalert oraz Alertmanager. Kontener VictoriaLogs działa pod /root/VictoriaLogs, zarządzany przez jednostkę systemd wywołującą cele Makefile, dzięki czemu aktualizacje są przewidywalne i odwracalne. Użyj docker ps do inspekcji kontenerów lub rozszerzania stosu o własne pliki compose.
Mocne narzędzia
Ten obraz zawiera lub współpracuje z poniższymi komponentami, abyś mógł skupić się na jakości logów, nie na konfiguracji.
- VictoriaLogs pojedynczy węzeł do szybkiego przyjmowania i odpytywania danych na porcie 9428.
- Grafana do dashboardów i eksploracji ad-hoc na porcie 3000.
- VictoriaMetrics jeden węzeł gdy potrzebujesz również przechowywania metryk na porcie 8428.
- vmauth do dodawania uwierzytelniania i routowania ruchu multi-tenant na porcie 8427.
- vmalert do oceny reguł alertowania i udostępniania API alertów na porcie 8880.
- Vector jako prosty, wydajny shipper z API pod adresem 8686, gdy jest włączony.
Globalny zasięg
Wybierz region najbliższy swoim użytkownikom. Cloudzy posiada punkty obecności w:
- Ameryka Północna: Nowy Jork, Dallas, Miami, Utah, Las Vegas
- Europa: Londyn, Amsterdam, Frankfurt, Zurych
- Azja i PacyfikSingapur
Każda lokalizacja oferuje to samo łącze 10 Gbps, mix Tier-1 i gwarantowany czas działania 99,95% zgodnie z SLA. Jedyna różnica to odległość.
Szczegóły aplikacji
Wersja: Nieokreślona
System operacyjny: Ubuntu Server 24.04
Minimalna ilość RAM: 1 GB
Typy IP: IPv6, IPv4
Wdróż VictoriaLogs teraz: Twoja baza logów i dashboardy są gotowe w kilka minut.
Uwagi i odniesienia: Domyślny port VictoriaLogs to 9428 oraz /metrics endpoint, przykłady ingestowania danych i model danych są udokumentowane przez VictoriaMetrics. Domyślne porty dla vmauth 8427, vmalert 8880, VictoriaMetrics jeden węzeł 8428, i Grafana 3000 z przepływem pierwszego logowania są opisane w oficjalnych przewodnikach.
Ważne: Konfiguracja i obowiązki dotyczące domeny
Dostajesz pełny dostęp SSH/root na każdej OCA. Ta moc oznacza też, że Twoje zmiany mogą przerwa aplikację. Przeczytaj to przed modyfikacją konfiguracji.
- Zarządzasz domeną. Nie sprzedajemy ani nie hostujemy domen/DNS. Jeśli aplikacja potrzebuje domeny, musisz skierować swoją domenę na serwer (A/AAAA/CNAME oraz MX/TXT, jeśli dotyczy). Wystawianie SSL i wiele paneli zależy od tego, czy są poprawne.
- Zmiana domeny/hostname po instalacji nie jest trywialna. Wiele OCA zapisuje domenę w konfiguracjach (.env, reverse proxy, adresy URL aplikacji). Jeśli ją zmienisz, zaktualizuj również:
- Reverse proxy (Nginx/Caddy) i certyfikaty TLS
- Aplikacyjny external URL / base URL oraz adresy URL callback i webhook
- Wszystkie zakodowane na stałe linki w aplikacji lub dodatkach
- Poświadczenia mają znaczenie. Zmiana nazwy domyślnego administratora, rotacja haseł lub zmiana portów usług bez aktualizacji konfiguracji aplikacji może zablokować dostęp lub zatrzymać usługi. Trzymaj poświadczenia w bezpiecznym miejscu i zsynchronizowane między aplikacją, proxy i wszystkimi integracjami.
- Zmiany serwerów nazw mogą powodować przestoje. Przeniesienie domeny na nowe nameservery lub edycja rekordów NS powoduje opóźnienia propagacji. Planuj zmiany, obniż TTL z wyprzedzeniem i zweryfikuj rekordy A/AAAA przed przełączeniem.
- Edycja zapory lub portów może zablokować dostęp. Jeśli zmienisz porty SSH, HTTP/HTTPS, RDP lub portów aplikacji, zaktualizuj odpowiednio firewalle (UFW/CSF/security groups) i reguły reverse-proxy.
- Porty poczty (SMTP) są domyślnie zablokowane. Wychodzące porty pocztowe (np. 25/465/587) może być zablokowane, aby zapobiec nadużyciom. Jeśli Twoja OCA musi wysyłać pocztę, poproś o dostęp SMTP. od supportu lub użyj dostawcy poczty transakcyjnej (SendGrid/Mailgun/SES) przez API albo zatwierdzony SMTP.
- Poczta e-mail i listy dozwolonych. Jeśli aplikacja wysyła pocztę lub odbiera webhooki, zmiana IP/hostname może wpłynąć na dostarczalność lub allowlisty. Zaktualizuj SPF/DKIM/DMARC i wszystkie allowlisty IP.
- Przed każdą większą zmianą: zrób snapshot. Skorzystaj z opcji w panelu zrzut ekranu/kopia zapasowa najpierw. Jeśli plugin, aktualizacja lub edycja konfiguracji zawiedzie, możesz cofnąć zmiany w kilka minut.
- Zakres obsługi. Dostarczamy serwer i preinstalowany obraz OCA. Bieżące konfiguracja na poziomie aplikacji (domeny, DNS, ustawienia aplikacji, wtyczki i niestandardowy kod) leżą w gestii użytkownika.
Prosta zasada: jeśli dotkniesz domena, porty, hasła, hostname lub konfiguracje proxy/SSL, przygotuj się również na aktualizację ustawień aplikacji i wykonaj najpierw snapshot.
Instalacja
- Sklonowano repozytorium VictoriaMetrics z GitHub do
/root/VictoriaLogs - Zainstalowano Docker i zależności
- Utworzono usługę systemd
victoria-logsdo zarządzania kontenerem VictoriaLogs za pomocą poleceń make
Polecenia
sudo systemctl start victoria-logs # Start VictoriaLogs service sudo systemctl stop victoria-logs # Stop service sudo systemctl status victoria-logs # Check service status docker ps # List running Docker containers
Dostęp do adresów URL
- VictoriaLogs w jednym węźle →
http://<SERVER-IP>:9428 - Grafana →
http://<SERVER-IP>:3000 - VictoriaMetrics w jednym węźle →
http://<SERVER-IP>:8428 - vmalert →
http://<SERVER-IP>:8880 - vmauth →
http://<SERVER-IP>:8427 - Alertmanager →
http://<SERVER-IP>:9093 - Vector UI →
http://<SERVER-IP>:8686
Dokumentacja
- https://docs.victoriametrics.com/victorialogs/
