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, Alertmanager, i 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.
Otwórz interfejs webowy
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.
- Rozliczenie 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.
Łatwy w użyciu
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 witryną
Masz uprawnienia root. Dostosuj retencję, przycinaj indeksy, konfiguruj vmauth użytkowników i kieruj alerty przez vmalert i 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.
Potężne 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.
Zasięg globalny
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: odpowiedzialność za konfigurację i domenę
Masz pełny dostęp SSH/root do każdego OCA. Ta swoboda oznacza też, że Twoje zmiany mogą przerwa wpłynąć na działanie aplikacji. Przeczytaj to przed modyfikacją konfiguracji.
- Zarządzasz domeną. Nie sprzedajemy ani nie hostujemy domen/DNS. Jeśli aplikacja wymaga domeny, musisz skierować swoją domenę na serwer (A/AAAA/CNAME, oraz MX/TXT jeśli dotyczy). Wystawianie SSL i wiele paneli zależy od poprawności tych ustawień.
- Zmiana domeny lub nazwy hosta po instalacji nie jest prosta. Wiele OCAs zapisuje domenę w plikach konfiguracyjnych (.env, reverse proxy, URL aplikacji). Przy zmianie zaktualizuj też:
- Reverse proxy (Nginx/Caddy) i certyfikaty TLS
- "Zewnętrzne URL"/bazowe URL aplikacji oraz URL callback/webhook
- Wszystkie zakodowane na stałe linki w aplikacji lub dodatkach
- Poświadczenia mają znaczenie. Zmiana domyślnej nazwy administratora, rotacja haseł lub zmiana portów usług bez aktualizacji konfiguracji aplikacji może zablokować dostęp lub zatrzymać usługi. Dbaj o bezpieczeństwo danych dostępowych i ich spójność między aplikacją, proxy a integracjami.
- Zmiany serwerów nazw mogą powodować przestoje. Przeniesienie domeny do nowych serwerów nazw lub edycja rekordów NS wywołuje opóźnienia propagacji. Zaplanuj zmiany z wyprzedzeniem, obniż TTL i zweryfikuj rekordy A/AAAA przed przełączeniem.
- Edycja zapory lub portów może zablokować dostęp. Jeśli zmienisz SSH, HTTP/HTTPS, RDP lub porty aplikacji, zaktualizuj odpowiednio reguły zapory (UFW/CSF/grupy bezpieczeństwa) i 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. przez dział wsparcia lub użyj transakcyjnego dostawcy poczty (SendGrid/Mailgun/SES) przez API lub zatwierdzony SMTP.
- Poczta e-mail i listy dozwolonych. Jeśli aplikacja wysyła pocztę lub odbiera webhooki, zmiana adresów IP lub nazw hostów może wpłynąć na dostarczalność lub listy dozwolonych. Zaktualizuj rekordy SPF/DKIM/DMARC oraz wszelkie listy dozwolonych IP.
- Przed każdą większą zmianą: zrób snapshot. Skorzystaj z opcji w panelu zrzut ekranu/kopia zapasowa najpierw. Jeśli wtyczka, aktualizacja lub zmiana konfiguracji spowoduje problemy, możesz cofnąć zmiany w ciągu kilku minut.
- Zakres obsługi. Dostarczamy serwer oraz wstępnie zainstalowany obraz OCA. Bieżąca konfiguracja na poziomie aplikacji (domeny, DNS, ustawienia aplikacji, wtyczki i niestandardowy kod) leżą w gestii użytkownika.
Prosta zasada: jeśli dotkniesz domenę, porty, hasła, nazwy hostów lub konfiguracje proxy/SSL, pamiętaj, aby zaktualizować również ustawienia aplikacji i wcześniej wykonać 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/
