PDF

Monitorowanie NGINX za pomocą Telegraf w NetCrunch

Ten dokument opisuje sposób konfigurowania Telegraf w celu zbierania metryk NGINX i wysyłania ich do NetCrunch za pośrednictwem punktu końcowego Telemetry Node.

Omówienie

Telegraf może zbierać metryki serwera NGINX za pomocą wbudowanej wtyczki wejściowej NGINX. Dane są przekazywane do NetCrunch za pośrednictwem żądania HTTP POST do punktu końcowego Telemetry Node.

Obsługa telemetrii NGINX przez NetCrunch

NetCrunch odbiera dane z Telegraf za pośrednictwem punktu końcowego REST Telemetry Node. Telemetry Nodes akceptują dane w formacie JSON i zapisują odebrane wartości jako liczniki lub stany alertów.

Obsługiwane punkty końcowe

Chmurowy punkt końcowy REST:


https://gw.netcrunch.io/tm/v1/<serverId>@<sensorId>@<nodeId>/update

Lokalny punkt końcowy REST:


<NetCrunch-WebServer>/api/rest/1/sensors/<sensorId>@<nodeId>/update

Przykładowy chmurowy punkt końcowy:


https://gw.netcrunch.io/tm/v1/SRV-001@sensor01@node100/update

Dane są wysyłane za pomocą metody HTTP POST z typem zawartości application/json. Wykrywanie adresu IP nie jest wymagane, ponieważ Telemetry Node istnieje logicznie w strukturze NetCrunch.

Przepływ danych

Monitorowanie NGINX za pomocą Telegraf przebiega w następujący sposób:

  1. Udostępnianie stanu NGINX — NGINX udostępnia metryki za pośrednictwem punktu końcowego modułu stub_status.

  2. Zbieranie danych przez Telegraf — wtyczka wejściowa NGINX w Telegraf wysyła zapytania do punktu końcowego stanu w regularnych odstępach czasu.

  3. Przekazywanie danych — Telegraf przekazuje zebrane metryki do Telemetry Node w NetCrunch za pośrednictwem HTTP POST.

  4. Przetwarzanie przez NetCrunch — Telemetry Node przypisuje przychodzące metryki i zapisuje je jako liczniki lub stany alertów.

Konfiguracja NGINX

Włącz moduł stub_status, aby udostępnić metryki.

Przykład konfiguracji

Dodaj poniższy wpis do pliku konfiguracyjnego NGINX (np. /etc/nginx/nginx.conf lub /etc/nginx/sites-available/default):


 server {
    listen 127.0.0.1:80;
    server_name localhost;


location /nginx_status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
}




}

Przeładuj NGINX:


nginx -t
systemctl reload nginx

Zweryfikuj punkt końcowy stanu:


curl http://127.0.0.1/nginx_status

Oczekiwany wynik:


Active connections: 45
server accepts handled requests
 657 657 1126
Reading: 0 Writing: 36 Waiting: 9

Konfiguracja Telegraf

Główny plik konfiguracyjny to /etc/telegraf/telegraf.conf.

Podstawowa konfiguracja


[agent]
  interval = "30s"
  flush_interval = "30s"
  debug = false
  quiet = true


[[inputs.nginx]]
  urls = ["http://127.0.0.1/nginx_status"]
  response_timeout = "5s"


[[outputs.http]]
  url = "https://gw.netcrunch.io/tm/v1/SRV-001@sensor01@node100/update"
  method = "POST"
  data_format = "json"
  content_encoding = "identity"
  [outputs.http.headers]
    Content-Type = "application/json"

Parametry konfiguracji

Sekcja Agent: - interval — częstotliwość zbierania metryk - flush_interval — częstotliwość wysyłania danych do wyjść - debug — włączenie szczegółowego rejestrowania - quiet — pomijanie komunikatów innych niż błędy

Wejście NGINX: - urls — lista punktów końcowych stanu NGINX, do których należy wysyłać zapytania - response_timeout — maksymalny czas oczekiwania na odpowiedź

Wyjście HTTP: - url — punkt końcowy Telemetry Node w NetCrunch - method — metoda HTTP (POST) - data_format — format wyjściowy (JSON) - content_encoding — typ kodowania - headers — nagłówki HTTP, w tym typ zawartości

Zbierane metryki

Wtyczka wejściowa NGINX zbiera następujące metryki:

Aktywne połączenia: - nginx_active — liczba aktywnych połączeń klientów

Metryki serwera: - nginx_accepts — łączna liczba zaakceptowanych połączeń klientów - nginx_handled — łączna liczba obsłużonych połączeń - nginx_requests — łączna liczba żądań klientów

Stany połączeń: - nginx_reading — liczba połączeń odczytujących nagłówki żądań - nginx_writing — liczba połączeń wysyłających odpowiedzi do klientów - nginx_waiting — liczba bezczynnych połączeń oczekujących na żądania

Konfiguracja zaawansowana

Wiele instancji NGINX

Monitoruj wiele serwerów NGINX:


[[inputs.nginx]]
  urls = [
    "http://server1.local/nginx_status",
    "http://server2.local/nginx_status",
    "http://server3.local/nginx_status"
  ]
  response_timeout = "5s"

Dodawanie niestandardowych tagów

Uwzględnij dodatkowe metadane:


[[inputs.nginx]]
  urls = ["http://127.0.0.1/nginx_status"]
  response_timeout = "5s"
  [inputs.nginx.tags]
    environment = "production"
    datacenter = "dc01"

Punkty końcowe HTTPS

W przypadku stanu NGINX udostępnianego przez HTTPS:


[[inputs.nginx]]
  urls = ["https://server.local/nginx_status"]
  response_timeout = "5s"
  insecure_skip_verify = false
  # tls_ca = "/path/to/ca.crt"

Przypadki użycia

Monitorowanie wydajności serwera internetowego

Śledź możliwości obsługi połączeń i identyfikuj wąskie gardła wydajności na serwerach internetowych o dużym natężeniu ruchu.

Kontrole kondycji modułu równoważenia obciążenia

Monitoruj instancje NGINX działające jako odwrotne serwery proxy lub moduły równoważenia obciążenia, aby zapewnić prawidłowe rozdzielanie żądań.

Monitorowanie bramy mikrousług

Śledź metryki z bram NGINX API obsługujących ruch mikrousług.

Monitorowanie wielu instancji

Zbieraj metryki z wielu instancji NGINX rozmieszczonych na różnych serwerach lub w kontenerach.

Podsumowanie

Telegraf zapewnia prostą integrację z NGINX za pośrednictwem modułu stub_status. Metryki są zbierane w regularnych odstępach czasu i przekazywane do Telemetry Nodes w NetCrunch w celu centralnego monitorowania i obsługi alertów. Takie podejście eliminuje konieczność konfigurowania SNMP i zapewnia wgląd w wydajność NGINX w czasie rzeczywistym.

Najważniejsze możliwości: - Zbieranie metryk NGINX w czasie rzeczywistym - Obsługa wielu instancji NGINX - Centralne monitorowanie za pośrednictwem Telemetry Nodes w NetCrunch - Brak konieczności odpytywania przez serwer NetCrunch

Zobacz także

Integracja Telegraf z NetCrunch
Kompletny przewodnik dotyczący korzystania z Telegraf z Telemetry Nodes w NetCrunch.

Telemetry Node
Wirtualny typ węzła przeznaczony do odbierania zewnętrznych metryk i zdarzeń za pośrednictwem REST lub OTLP.

Omówienie formatów danych NetCrunch
Szczegółowe wyjaśnienie formatów JSON, XML i CSV akceptowanych przez NetCrunch.

Wysyłanie danych do NetCrunch
Przewodnik dotyczący korzystania z REST API, bramy OTLP i czujników opartych na plikach w celu przesyłania danych do NetCrunch.