Met Anomaliedetectie kunt u Triggers configureren om meldingen te versturen wanneer een metriekwaarde boven een drempel uitkomt of daaronder zakt. Bijvoorbeeld: wanneer het foutpercentage van een applicatie boven de 5% komt of het vrije geheugen onder de 100MB zakt.
Anomaliedetectie werkt door per minuut wijzigingen in metriekwaarden te detecteren. Wanneer een drempelvoorwaarde wordt bereikt, brengen we u op de hoogte van de nieuwe alert die door deze gebeurtenis is aangemaakt en informeren we u opnieuw wanneer de drempel niet langer wordt bereikt.
Om ervoor te zorgen dat u op een passend moment wordt gewaarschuwd, kunt u warm-ups en cooldowns definiëren om te bepalen wanneer een nieuwe alert wordt geopend.
Alert-statussen
Alerts kunnen vijf verschillende statussen hebben:
| Status | Beschrijving |
|---|
| Warming up | De alert bevindt zich in de warm-up-fase. U kunt per Trigger configureren dat een voorwaarde gedurende een bepaalde tijd waar moet zijn voordat u een melding krijgt. |
| Open | De alert is actief geworden omdat de drempelvoorwaarde is bereikt. |
| Closed | De alert is niet meer actief en is gesloten. |
| Cool Down | De alert ligt niet meer boven de drempelvoorwaarde, maar wordt niet beëindigd of heropend totdat de cooldown-periode is verstreken. |
| Ended | De alert is beëindigd. Er wordt geen nieuwe alert meer verstuurd. Als de triggervoorwaarden opnieuw worden geactiveerd, gaat een nieuwe alert de warming up-fase in. |
Wanneer word ik gewaarschuwd?
Nadat u meldingen heeft geconfigureerd, ontvangt u een melding wanneer een alert in de open-fase komt. U ontvangt meldingen voor herinneringen die u tijdens die fase heeft geconfigureerd en wanneer de alert wordt gesloten.
E-mailmeldingen
Alert-e-mails bevatten een overzicht van nieuwe alerts, herinneringen en de status van andere alerts die nog niet zijn beëindigd.
Anomaliedetectie kan per app worden geconfigureerd in het gedeelte “Anomaly detection” in de app-navigatie. Standaard ziet u de meest recente alerts die zijn aangemaakt door triggers die u voor de app heeft geconfigureerd.
In de bovenste navigatie kunt u overschakelen naar de triggerspagina om nieuwe triggers aan te maken en bestaande triggers te bewerken.
U kunt Triggers aanmaken en beheren vanuit het gedeelte “Anomaly detection” in het navigatiemenu van uw applicatie.
U kunt Triggers configureren met verschillende metrieken:
- Foutpercentages
- Foutaantallen (absoluut)
- App-throughput
- Performance van actions (langzame actions)
- Queue-tijd
- Host-metrieken
- CPU-belasting
- Disk I/O
- Schijfgebruik
- Load averages
- Geheugengebruik
- Netwerkgebruik
Warm-up en cooldown
U kunt per trigger warm-up- en cooldown-instellingen configureren, waarmee u de tijd kunt definiëren die het systeem wacht voordat een alert wordt geopend en gesloten.
Warm-up
Het is niet aanbevolen om Anomaliedetectie en de Warmup-functie te gebruiken om
te controleren of services zoals uur-/dagelijkse jobs en cronjobs draaien.
Normaal gesproken wordt een alert geopend wanneer de drempelvoorwaarde van een Trigger wordt bereikt; bijvoorbeeld: het foutpercentage is hoger dan 5%.
Als er een warm-up-periode op de Trigger is geconfigureerd, opent AppSignal pas een alert nadat die tijd is verstreken en als de drempel nog steeds wordt overschreden; bijvoorbeeld: het foutpercentage is gedurende meer dan 3 minuten hoger dan 5%.
Wanneer er voor een trigger een warm-up-periode is geconfigureerd, opent de alert pas nadat de warm-up-tijd is verstreken. De drempelvoorwaarde moet gedurende de hele warm-up-periode worden bereikt om de alert te openen.
AppSignal stuurt u een melding wanneer de status van de alert van warm-up naar open verandert.
Cooldown
Alerts die door een Trigger worden geopend, worden automatisch gesloten wanneer de drempelvoorwaarde niet langer wordt bereikt. Om te voorkomen dat u te veel meldingen ontvangt, kunt u cooldown-periodes configureren.
Als u voor een Trigger een cooldown-periode heeft geconfigureerd, wordt er geen nieuwe alert aangemaakt tenzij de voorwaarden van de Trigger zijn bereikt nadat de cooldown-periode is verstreken.
Bijvoorbeeld:
- Een alert wordt geopend omdat het foutpercentage hoger is dan 5%
- Het foutpercentage daalt, dus de alert wordt automatisch gesloten.
- De trigger voor de alert heeft een cooldown-periode van twee minuten.
- Het foutpercentage komt opnieuw boven de 5%.
- AppSignal maakt geen nieuwe alert aan tenzij het foutpercentage de 5% overschrijdt nadat de cooldown-periode is afgelopen.
Sommige metrieken vereisen dat er ook tags worden geselecteerd. Als u bijvoorbeeld een aangepaste metriek met tags naar AppSignal verzendt:
Appsignal.set_gauge("my_metric_name", 100, :namespace => "web", :action => "hello")
Bij het aanmaken van een Trigger voor deze metriek moet u dan ook tags selecteren.
Ontbrekende datapunten als 0
Standaard gaan Triggers ervan uit dat er elke minuut een datapunt wordt verzonden.
Dit is in bepaalde situaties wellicht niet haalbaar, zoals het verhogen van een teller alleen wanneer een specifieke actie plaatsvindt. In dergelijke gevallen kunt u de optie "When checked, we will treat missing datapoints as a value of 0" gebruiken. Door deze optie in te schakelen gaat het systeem ervan uit dat een ontbrekend datapunt een waarde van nul heeft. Dit zorgt ervoor dat de alert zoals verwacht wordt gesloten als er in de volgende minuut geen data wordt ontvangen.
Dataverwerking
De metrieken die door triggers worden gebruikt om alerts aan te maken, worden niet direct verwerkt wanneer de metrieken vanuit uw applicatie naar AppSignal worden verzonden.
Uw metriekgegevens gaan door meerdere systemen voordat ze bij onze processor aankomen. De data kan ook worden verzonden vanaf meerdere servers die data op verschillende intervallen verzenden.
De processor wacht* totdat alle data voor een minuut is binnengekomen voordat die data wordt verwerkt en alerts worden aangemaakt of bijgewerkt.
Als u problemen ondervindt met de metrieken die door AppSignal voor Anomaliedetectie worden gerapporteerd, zorg er dan voor dat de servers van uw applicatie allemaal gelijktijdig rapporteren door ze te configureren met NTP. Onjuiste of verschillende gerapporteerde tijden voor data die door meerdere app-servers wordt verzonden, kunnen ertoe leiden dat alerts nooit worden geopend of gesloten.
U leest meer over hoe AppSignal data voor Anomaliedetectie verwerkt en wat dit voor de alerts betekent in onze data life cycle-documentatie.
*: Voor meer informatie over de specifieke wachttijden, raadpleegt u onze data life cycle-pagina.
Incidenten beheren
U kunt alle alert-incidenten bekijken op de Anomaly Issues-pagina in de AppSignal-app. De Issues-pagina toont een overzicht van alle open alert-incidenten, gesorteerd op laatste voorkomen, met kolommen voor de anomalie:
- Naam
- Status
- Toegewezen aan
- Status
- Tijdstip van laatste statuswijziging
U kunt uw incidenten ook eenvoudig filteren op basis van hun status.
Om een incident verder te onderzoeken, kunt u de incidentsamenvatting openen. Hier vindt u alle tools en informatie die u nodig heeft om de anomalie die uw alert activeert nader te onderzoeken. Op de samenvattingspagina heeft u toegang tot:
- Alert-informatie: de naam van de metriek, de status van de alert en de tags van de alert.
- Frequentiegrafiek van voorkomens: een visuele weergave van het voorkomen van de alert.
- Incidentinstellingen: mogelijkheid om de alert te sluiten, de ernst in te stellen en deze toe te wijzen aan een teamlid.
- Triggerinformatie: de voorwaarden die nodig zijn om de alert te activeren.
- Laatste voorkomens: een tabel met de meest recente voorkomens, met hun begin-/eindtijd, status en piekwaarde.
- Logboek: een logboek voor het vastleggen van belangrijke alert-informatie over deze alert voor uw team of uzelf in de toekomst.
- Toegang tot de Time Detective: gebruik de Time Detective-tool om de staat van uw applicatie te bekijken op het moment dat de alert voor het laatst optrad.
Al deze functies zijn eenvoudig toegankelijk in onze intuïtieve UI:
