Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. informacje.
Warunki alertów definiują konkretny kod stanu (np. 404/502/2xx/4xx/5xx), czasu oczekiwania oraz kodów błędów, które po przekroczeniu powodują wyświetlanie alertów wizualnych w interfejsie i wysyłanie powiadomień za pomocą różnych kanałów, takich jak e-mail, slack, Pagerduty lub webhooki. Alerty możesz skonfigurować na poziomie środowiska, serwera proxy interfejsu API, usługi docelowej lub regionu. Po wywołaniu alertu otrzymasz powiadomienie zgodnie z metodą określoną podczas dodawania alertów i powiadomień.
Możesz na przykład aktywować alert i wysłać do zespołu operacyjnego powiadomienie, gdy odsetek błędów 5xx przekroczy 23% przez okres 5 minut dla serwera proxy interfejsu Order-prod API wdrożonego w środowisku produkcyjnym.
Poniższy rysunek przedstawia sposób wyświetlania alertów w interfejsie:
Poniżej znajduje się przykład powiadomienia e-mail, które możesz otrzymać po uruchomieniu alertu.
Aby uzyskać więcej informacji, w treści powiadomienia o alercie kliknij te linki:
- Wyświetl szczegóły, aby zobaczyć więcej informacji, w tym ustawienia alertów i aktywność związaną z poszczególnymi warunkami w ciągu ostatniej godziny.
- Definicja alertu, aby wyświetlić definicję alertu.
- Historia alertów – zawiera więcej informacji o konkretnym alercie.
- Wyświetl scenariusz, aby zobaczyć zalecane działania (jeśli zostały podane).
- Wyświetl raport interfejsu API Analytics, aby wyświetlić raport niestandardowy dotyczący warunku alertu.
W sekcjach poniżej opisano, jak konfigurować alerty i powiadomienia oraz nimi zarządzać.
Typy alertów
We wstępnej wersji usługi API Monitoring można tworzyć reguły oparte na wzorcach, które określają, kiedy ma być wywoływany alert na podstawie zestawu wstępnie zdefiniowanych warunków. Te typy alertów są nazywane alertami stałymi i były jedynym rodzajem alertów obsługiwanym we wstępnej wersji usługi API Monitoring.
Możesz na przykład wywołać stały alert, gdy:
- [współczynnik błędów 5xx] [wynosi więcej niż] [10%] w przypadku [10 minut] z [cel moja_cel1]
- [liczba błędów 2xx] [wynosi mniej niż] [50] przez [5 minut] w [region us-east-1]
- [czas oczekiwania p90] [wynosi więcej niż] [750 ms] przez [10 minut] na serwerze [proxy myproxy1]
Wersja beta raportowania zabezpieczeń 19.11.13 zawiera nowe typy alertów:
- Alerty dotyczące całkowitego ruchu (beta). Typ alertu, który umożliwia zgłaszanie alertu, gdy natężenie ruchu zmienia się o określoną wartość procentową w wybranym przedziale czasu.
- alerty o anomalii (beta), Typ alertu, w przypadku którego Edge wykrywa problemy związane z ruchem i wydajnością, bez konieczności ich samodzielnego określania. Możesz następnie zgłosić alert o tych anomaliach.
- Alerty o wygaśnięciu TLS (beta). Typ alertu, który umożliwia wysyłanie powiadomień, gdy certyfikat TLS zbliża się do wygaśnięcia.
Ponieważ API Monitoring obsługuje teraz wiele typów alertów, w oknie Utwórz alert pojawi się teraz opcja wyboru typu alertu:
Wyświetl ustawienia alertów
Aby wyświetlić obecnie zdefiniowane ustawienia alertów, kliknij Analiza > Reguły alertów w interfejsie Edge.
Zostanie wyświetlona strona alertów zgodnie z tą ilustracją:
Jak zaznaczyliśmy na ilustracji, strona Alert umożliwia:
- Wyświetl podsumowanie ustawień alertów, które są obecnie zdefiniowane
- wyświetlić historię alertów, które zostały wygenerowane;
- Dodawanie alertów i powiadomień
- Tworzenie raportu niestandardowego na podstawie alertu
- Włączanie i wyłączanie alertu
- Edytowanie alertu
- Usuwanie alertu
- Wyszukiwanie na liście alertów dotyczących określonego ciągu
Wyświetlanie historii alertów, które zostały aktywowane dla Twojej organizacji
Aby wyświetlić historię alertów, które zostały aktywowane w Twojej organizacji w ciągu ostatnich 24 godzin, kliknij Analiza > Reguły alertów w interfejsie użytkownika Edge i kliknij kartę Historia.
Wyświetli się strona Historia alertów.
Kliknij nazwę alertu, aby wyświetlić jego szczegóły w panelu sprawdzania. Listę można filtrować, wyszukując całość lub część nazwy alertu.
Dodawanie alertów i powiadomień
Aby dodać alerty i powiadomienia:
- W interfejsie Edge kliknij Analyze > Reguły alertów.
- Kliknij +Alert.
- Wpisz te ogólne informacje o alercie:
Pole Opis Nazwa alertu Nazwa alertu. Użyj nazwy, która opisuje regułę i będzie przydatna dla Ciebie. Długość nazwy nie może przekraczać 128 znaków. Typ alertu Wybierz Stałe. Więcej informacji o typach alertów znajdziesz w artykule Informacje o typach alertów. Opis Opis alertu. Środowisko Wybierz środowisko z listy. Stan Przełącz, aby włączyć lub wyłączyć alert. - Określ dane, próg i wymiar pierwszego warunku, który będzie wyzwalać alert.
Pole warunku Opis Dane Wybierz jeden z tych danych:
Kod stanu: wybierz z listy kod stanu, np. 401, 404, 2xx, 4xx lub 5xx HTTP.
Uwaga:
- Interfejs API umożliwia ustawienie szerszego zakresu kodów stanu. Użyj interfejsu API, aby podać dowolny kod stanu z przedziału 200–299, 400–599 oraz wartości symboli wieloznacznych 2xx, 4xx lub 5xx. Zobacz Tworzenie alertu.
- W przypadku alertów o ograniczaniu liczby żądań (kod stanu HTTP 429) ustaw wartość na Kod błędu Spike Arrest.
- Za pomocą zasady AssignMessage możesz przepisać kod odpowiedzi HTTP z powodu błędu serwera proxy lub błędu docelowego. API Monitoring ignoruje wszystkie przepisane kody i rejestruje rzeczywiste kody odpowiedzi HTTP.
- Czas oczekiwania: wybierz wartość czasu oczekiwania z listy. W szczególności: p50 (50 centyl), p90 (90 centyl), p95 (95 centyl) lub p99 (99 centyl). Wybierz na przykład P95, aby skonfigurować alert, który jest wyzwalany, gdy czas oczekiwania na odpowiedź 95 centyla przekracza próg ustawiony poniżej.
Kod błędu: wybierz z listy kategorię, podkategorię i kod błędu. Możesz też wybrać jedną z następujących opcji w kategorii lub podkategorii:
- Wszystkie – łączna liczba wszystkich kodów błędów w tej kategorii lub podkategorii musi spełniać kryteria danych.
- Dowolny – kod pojedynczego błędu w tej kategorii/podkategorii musi spełniać kryteria danych.
Więcej informacji znajdziesz w informacjach o kodach błędów.
- Łączny ruch (beta): wybierz zwiększanie lub zmniejszanie ruchu. Więcej informacji znajdziesz w artykule Alerty o natężeniu ruchu (beta).
Próg Skonfiguruj próg dla wybranego wskaźnika:
- Kod stanu: ustaw próg jako stopę procentową, liczbę lub liczbę transakcji na sekundę (TPS) w czasie.
- Czas oczekiwania: wybierz próg jako łączny lub docelowy czas oczekiwania (ms) w czasie. W takim przypadku alert jest wywoływany, gdy określony centyl zaobserwowanego czasu oczekiwania, który jest aktualizowany co minutę w przypadku wystąpienia ruchu, przekracza warunek progowy dla przedziału czasu obejmującego określony czas. Oznacza to, że warunek progowy nie jest agregowany w całym okresie.
- Kod błędu: ustaw próg w postaci stawki procentowej, liczby lub transakcji na sekundę (TPS) w czasie.
Wymiar Kliknij +Dodaj wymiar i określ szczegóły wymiaru, dla których mają zostać zwrócone wyniki, w tym serwer proxy interfejsu API, usługę docelową, aplikację dewelopera i region. Jeśli ustawisz konkretny wymiar na:
- Wszystko – wszystkie elementy w wymiarze muszą spełniać kryteria danych. Nie można wybrać opcji Wszystkie dla danych typu Czas oczekiwania.
- Dowolna – dotyczy tylko regionu. Encja w wymiarze musi spełniać kryteria danych dla dowolnego regionu.
Uwaga: w przypadku serwerów proxy interfejsu API lub usług docelowych wybierz kolekcję, która obsługuje dowolną funkcję. - Kolekcje – wybierz kolekcję z listy, aby określić zestaw serwerów proxy interfejsu API lub usług docelowych. W takim przypadku każdy element w kolekcji musi spełniać kryteria.
Jeśli ustawisz wymiar na Cel, możesz wybrać usługę docelową lub usługę określoną w zasadach dotyczących ServiceCallout. Cel zasady ServiceCallout jest wyświetlany jako wartość poprzedzona ciągiem „sc://”. Na przykład „sc://my.endpoint.net”.
- Kliknij Pokaż dane dotyczące warunku, aby wyświetlić najnowsze dane dotyczące stanu z ostatniej godziny.
Odsetek błędów na wykresie jest wyświetlany na czerwono, gdy przekracza próg warunku alertu.
Aby ukryć dane, kliknij Ukryj dane warunku.
- Kliknij + Dodaj warunek, aby dodać kolejne warunki, i powtórz kroki 4 i 5.
Uwaga: jeśli określisz kilka warunków, alert zostanie wywołany po spełnieniu wszystkich tych warunków.
Kliknij Utwórz raporty Analytics na podstawie warunków alertu, jeśli chcesz utworzyć raport niestandardowy na podstawie skonfigurowanych przez Ciebie warunków alertu. Jeśli nie jesteś administratorem organizacji, ta opcja jest nieaktywna.
Więcej informacji znajdziesz w artykule Tworzenie raportu niestandardowego na podstawie alertu.
Uwaga: po zapisaniu alertu możesz zmodyfikować raport niestandardowy zgodnie z opisem w sekcji Zarządzanie raportami niestandardowymi.
- Kliknij + Powiadomienie, aby dodać powiadomienie o alercie.
Szczegóły powiadomienia Opis Kanał Wybierz kanał powiadomień, którego chcesz użyć, i określ miejsce docelowe: Email, Slack, PagerDuty lub Webhook. Miejsce docelowe Określ miejsce docelowe na podstawie wybranego typu kanału: - E-mail – adres e-mail, np.
joe@company.com
- Slack – adres URL kanału na Slacku, np.
https://hooks.slack.com/services/T00000000/B00000000/XXXXX
- PagerDuty – kod PagerDuty, np.
abcd1234efgh56789
Webhook – adres URL webhooka, np.
https://apigee.com/test-webhook
. Opis obiektu wysyłanego na adres URL znajdziesz w sekcji Format obiektu webhooka.Przekaż dane logowania w adresie URL webhooka. Na przykład:
https://apigee.com/test-webhook?auth_token=1234_abcd
.Możesz podać adres URL punktu końcowego, który może przeanalizować obiekt webhooka, aby go zmodyfikować lub przetworzyć. Możesz na przykład podać adres URL interfejsu API, takiego jak Edge API, lub innego punktu końcowego, który może przetworzyć obiekt.
Uwaga: dla każdego powiadomienia możesz określić tylko jedno miejsce docelowe. Aby określić kilka miejsc docelowych dla tego samego typu kanału, dodaj kolejne powiadomienia.
- E-mail – adres e-mail, np.
- Aby dodać kolejne powiadomienia, powtórz krok 8.
- Jeśli dodasz powiadomienie, skonfiguruj te pola:
Pole Opis Poradnik (Opcjonalnie) Pole tekstowe z krótkim opisem zalecanych działań w przypadku uruchamiania uruchamianych alertów. Możesz też podać link do wewnętrznej strony wiki lub społeczności, na której znajdziesz sprawdzone metody. Informacje z tego pola zostaną dołączone do powiadomienia. Długość zawartości tego pola nie może przekraczać 1500 znaków. Ograniczaj Częstotliwość wysyłania powiadomień. Wybierz wartość z listy. Prawidłowe wartości to 15 minut, 30 minut i 1 godzina. - Kliknij Zapisz.
Format obiektu webhooka
Jeśli jako miejsce docelowe powiadomienia o alercie podasz adres URL webhooka, obiekt wysyłany do tego adresu URL będzie miał ten format:{ "alertInstanceId": "event-id", "alertName": "name", "org": "org-name", "description": "alert-description", "alertId": "alert-id", "alertTime": "alert-timestamp", "thresholdViolations":{"Count0": "Duration=threshold-duration Region=region Status Code=2xx Proxy=proxy Violation=violation-description" }, "thresholdViolationsFormatted": [ { "metric": "count", "duration": "threshold-duration", "proxy": "proxy", "region": "region", "statusCode": "2xx", "violation": "violation-description" } ], "playbook": "playbook-link" }
Właściwości thresholdViolations
i thresholdViolationsFormatted
zawierają szczegółowe informacje o alercie. Właściwość thresholdViolations
zawiera pojedynczy ciąg znaków ze szczegółami, a thresholdViolationsFormatted
– obiekt opisujący alert.
Zwykle używasz właściwości thresholdViolationsFormatted
, ponieważ jest ona łatwiejsza do dekodowania.
Powyższy przykład przedstawia zawartość tych właściwości dla alertu stałego, gdy skonfigurujesz wskaźnik alertu tak, aby uruchamiał się na podstawie kodu stanu HTTP 2xx, co wskazuje właściwość statusCode
.
Zawartość tych właściwości zależy od typu alertu (np. naprawiony lub anomalii) oraz jego konfiguracji.
Jeśli np. utworzysz naprawiony alert na podstawie kodu błędu, właściwość thresholdViolationsFormatted
będzie zawierać właściwość faultCode
, a nie statusCode
.
W tabeli poniżej znajdziesz wszystkie właściwości właściwości thresholdViolationsFormatted
w przypadku różnych typów alertów:
Typ alertu | Możliwe naruszenia progu Sformatowane treści |
---|---|
Naprawiono | metric, proxy, target, developerApp, region, statusCode, faultCodeCategory, faultCodeSubCategory, faultCode, percentile, comparisonType, thresholdValue, triggerValue, duration, violation |
Ruch ogółem | metric, proxy, target, developerApp, region, comparisonType, thresholdValue, triggerValue, duration, violation |
Anomalia | metric, proxy, target, region, statusCode, faultCode, percentile, sensitivity, violation |
Wygaśnięcie protokołu TLS | envName, certificateName, thresholdValue, violation |
Tworzenie raportu niestandardowego na podstawie alertu
Aby utworzyć raport niestandardowy na podstawie alertu:
- Podczas tworzenia alertu kliknij Tworzenie raportów analitycznych na podstawie warunków alertu zgodnie z opisem w artykule Dodawanie alertów i powiadomień.
Gdy zapiszesz alert, w interfejsie wyświetli się ten komunikat:
Alert alertName saved successfully. To customize the report generated, click here.
Kliknij komunikat, aby otworzyć raport w nowej karcie z wstępnie wypełnionymi odpowiednimi polami. Domyślna nazwa raportu niestandardowego to:
API Monitoring Generated alertName
- Odpowiednio edytuj raport niestandardowy i kliknij Zapisz.
- Kliknij nazwę raportu na liście i wygeneruj raport niestandardowy.
Aby zarządzać raportem niestandardowym utworzonym na podstawie warunków alertu:
- W interfejsie Edge kliknij Analyze > Reguły alertów.
- Kliknij kartę Ustawienia.
- W kolumnie Raporty kliknij raport niestandardowy powiązany z alertem, którym chcesz zarządzać.
Strona raportu niestandardowego pojawi się w nowej karcie. Jeśli kolumna Raporty jest pusta, oznacza to, że raport niestandardowy nie został jeszcze utworzony. W razie potrzeby możesz zmodyfikować alert, aby dodać raport niestandardowy.
- Odpowiednio edytuj raport niestandardowy i kliknij Zapisz.
- Kliknij nazwę raportu na liście i wygeneruj raport niestandardowy.
Włączanie i wyłączanie alertu
Aby włączyć lub wyłączyć alert:
- W interfejsie Edge kliknij Analyze > Reguły alertów.
- Kliknij przełącznik w kolumnie Stan powiązany z alertem, który chcesz włączyć lub wyłączyć.
Edycja alertu
Aby edytować alert:
- W interfejsie Edge kliknij Analyze > Reguły alertów.
- Kliknij nazwę alertu, który chcesz edytować.
- W razie potrzeby zmodyfikuj alert.
- Kliknij Zapisz.
Usuwanie alertu
Aby usunąć alert:
- W interfejsie Edge kliknij Analyze > Reguły alertów.
- Najedź kursorem na alert, który chcesz usunąć, i kliknij
w menu czynności.
Sugerowane alerty
Apigee sugeruje skonfigurowanie poniższych alertów, aby otrzymywać powiadomienia o typowych problemach. Niektóre z nich dotyczą implementacji interfejsów API i przydają się tylko w określonych sytuacjach. Kilka poniższych alertów dotyczy na przykład zasad dotyczących ServiceCallout lub zasad dotyczących Javy w języku Java.
Alert | Przykład interfejsu użytkownika | Przykład interfejsu API |
---|---|---|
Kody stanu 5xx dla wszystkich/dowolnych interfejsów API | Konfigurowanie alertu z kodem stanu 5xx dla serwera proxy interfejsu API | Konfigurowanie alertu z kodem stanu 5xx dla serwera proxy interfejsu API za pomocą interfejsu API |
Czas oczekiwania (95 centyl) w przypadku serwera proxy interfejsu API | Konfigurowanie alertu o czasie oczekiwania P95 dla serwera proxy interfejsu API | Konfigurowanie alertu o czasie oczekiwania P95 dla serwera proxy interfejsu API za pomocą interfejsu API |
Kody stanu 404 (nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API | Konfigurowanie alertu z kodem stanu 404 (nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API | Konfigurowanie alertu z kodem stanu 404 (Nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API za pomocą interfejsu API |
Liczba serwerów proxy API dla interfejsów API | Konfigurowanie alertu dotyczącego liczby serwerów proxy interfejsu API dla interfejsów API | Konfigurowanie alertu dotyczącego liczby serwerów proxy interfejsu API dla interfejsów API przy użyciu interfejsu API |
Odsetek błędów dotyczących usług docelowych | Konfigurowanie alertu dotyczącego odsetka błędów dla usług docelowych | Konfigurowanie alertu dotyczącego liczby błędów dla usług docelowych za pomocą interfejsu API |
Odsetek błędów w zasadach dotyczących wywołania usługi (jeśli dotyczy) | Konfigurowanie alertu dotyczącego odsetka błędów zgodnie z zasadami dotyczącymi objaśnień Service | Konfigurowanie za pomocą interfejsu API alertu o liczbie błędów w przypadku zasad dotyczących ServiceCallout |
konkretne kody błędów, w tym:
|
Konfigurowanie alertu dotyczącego kodu błędu zasady | Konfigurowanie alertu dotyczącego kodu błędu zasad za pomocą interfejsu API |
Konfigurowanie alertu z kodem stanu 5xx dla serwera proxy interfejsu API
Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wywoływany, gdy liczba transakcji na sekundę (TPS) kodów stanu 5xx dla serwera proxy interfejsu Hotel API przekracza 100 przez 10 minut w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.
Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu z kodem stanu 5xx dla serwera proxy przy użyciu interfejsu API.
Konfigurowanie alertu dotyczącego czasu oczekiwania P95 dla serwera proxy interfejsu API
Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika wywoływanego, gdy łączny czas oczekiwania na odpowiedź 95 centyla przekracza 100 ms przez 5 minut dla serwera proxy interfejsu Hotel API w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.
Informacje o używaniu interfejsu API znajdziesz w artykule Konfigurowanie alertu P95 dla serwera proxy interfejsu API przy użyciu interfejsu API
Skonfiguruj alert 404 (Nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API
Poniżej znajdziesz przykład konfigurowania za pomocą interfejsu użytkownika alertu uruchamianego, gdy odsetek kodów stanu 404 dla wszystkich serwerów proxy interfejsu API przekracza 5% przez 5 minut w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.
Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu 404 (Nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API przy użyciu interfejsu API.
Konfigurowanie alertu dotyczącego liczby serwerów proxy interfejsu API dla interfejsów API
Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wywoływany, gdy liczba kodów 5xx dla interfejsów API przez 5 minut w dowolnym regionie przekroczy 200 przez 5 minut. W tym przykładzie interfejsy API są przechwytywane w kolekcji krytycznych serwerów proxy interfejsu API. Aby dowiedzieć się więcej, zobacz:
Informacje o korzystaniu z interfejsu API znajdziesz w artykule na temat konfigurowania alertu dotyczącego liczby serwerów proxy interfejsu API przy użyciu interfejsu API.
Konfigurowanie alertu dotyczącego odsetka błędów dla usług docelowych
Poniżej znajdziesz przykład konfigurowania za pomocą interfejsu użytkownika alertu uruchamianego, gdy współczynnik kodów 500 dla usług docelowych przekracza 10% przez 1 godzinę w dowolnym regionie. W tym przykładzie usługi docelowe są rejestrowane w kolekcji Cele krytyczne. Aby dowiedzieć się więcej, zobacz:
Informacje o korzystaniu z interfejsu API znajdziesz w artykule na temat konfigurowania alertu dotyczącego odsetka błędów w usługach docelowych za pomocą interfejsu API.
Konfigurowanie alertu dotyczącego odsetka błędów na potrzeby zasady ServiceCallout
Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu, który jest wywoływany, gdy współczynnik kodu 500 dla usługi określonej przez zasadę ServiceCallout przekracza 10% przez 1 godzinę w dowolnym regionie. Aby dowiedzieć się więcej, zobacz:
Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu dotyczącego odsetka błędów w zasadach dotyczących objaśnień usługi przy użyciu interfejsu API.
Skonfiguruj alert dotyczący kodu błędu zasady
Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wywoływany, gdy liczba kodów błędów JWT AlgorithmMismatch
w zasadzie VerifyJWT jest większa niż 5 przez 10 minut przez wszystkie interfejsy API.
Aby dowiedzieć się więcej, zobacz:
Informacje o korzystaniu z interfejsu API znajdziesz w artykule na temat konfigurowania alertu dotyczącego kodu błędu zasad przy użyciu interfejsu API.