Skip to main content
Om uit te vinden welke specifieke stukken code performanceproblemen veroorzaken, is het nuttig om custom instrumentation aan uw applicatie toe te voegen. Hierdoor kunnen we betere uitsplitsingen maken van welke code het traagst draait en welk soort actie de meeste tijd kostte. Wanneer u opgeslagen samples van trage requests in AppSignal bekijkt, ziet u alle instrumentation die uw applicatie intern gebruikt. Template-rendering, ActiveRecord-queries en caching zijn geïnstrumenteerd en worden in de sample weergegeven. Default event tree Dat is al heel nuttig, maar zou het niet geweldig zijn als we metingen konden zien van specifieke stukken code waarvan u vermoedt dat ze uw performance beïnvloeden? Dat kan! Door custom instrumentation toe te voegen, kunnen we meer gedetailleerde uitsplitsingen maken van een request en background job. Er zijn twee manieren om uw code te instrumenteren. Met AppSignal-instrumentation-helpers of met ActiveSupport Notifications-instrumentation, zoals door Rails wordt gebruikt.
Let op: Zorg ervoor dat u AppSignal heeft geïntegreerd voordat u custom instrumentation aan uw applicatie toevoegt, als deze niet automatisch geïntegreerd wordt door een van onze ondersteunde integraties. Volg onze gids voor instrumentation voor scripts en background jobs voor applicaties die we niet automatisch instrumenteren.
Let op: Deze pagina beschrijft alleen hoe u performance-instrumentation aan uw code toevoegt. Om errors te tracken, lees onze gids over exception handling.

Instrumentation-helpers

Wanneer u custom instrumentation aan uw code toevoegt, krijgt u nog meer inzicht in uw applicatie. U werkt bijvoorbeeld met een externe API die artikelen voor uw homepage ophaalt:
Zodra u zulke custom instruments toevoegt, pikt AppSignal ze op en laat het u zien hoeveel tijd zowel een event-groep (article_fetcher in dit geval) als individuele events in beslag namen. Event tree with fetcher In dit geval ziet u dat deze API-aanroep een enorme invloed heeft op de performance van onze homepage, wat eerder verborgen was. We zouden kunnen overwegen de artikelen te cachen.
Let op: De naam van het event dat u instrumenteert is belangrijk voor onze processor. Lees meer over event-naming.

Geneste instrumentation

U kunt zoveel instruments gebruiken in elke gewenste combinatie. U kunt instrument-aanroepen nesten en AppSignal handelt de nesting en aggregaten van de metingen netjes af. U hoeft alleen het laatste segment (na de laatste punt) van de sleutel consistent te houden.

Meer data verzamelen per event

Standaard verzamelt AppSignal de duur van een event en stuurt het naar onze servers. Aangezien custom instrumentation niet aan framework-internals is gekoppeld, moet u mogelijk meer data meegeven als u event-details in AppSignal wilt laten verschijnen. Dit kan een beschrijvende titel zijn, of meer specifieke informatie zoals de query van een database-aanroep. We doen dit al voor ActiveRecord, Sequel, Redis, MongoDB, Sinatra, Grape, en meer. Er zijn twee helpers waarmee u uw code met AppSignal kunt instrumenteren.

name-argument

De naam van het event dat in de event tree in AppSignal verschijnt. Lees meer over event-key-naming.

title-argument

Een meer beschrijvende titel van een event, zoals "Fetch current user" of "Fetch blog post comments". Deze verschijnt naast de naam van het event in de event tree op de performance-sample-pagina om iets meer context te geven over wat er gebeurt.

body-argument

Meer details, zoals een databasequery die door het event werd gebruikt.
Waarschuwing: Zorg ervoor dat de body-payloads gesaneerd zijn (gevoelige/dynamische data wordt verwijderd). Niet-gesaneerde body-events worden weggegooid als ze een bepaalde limiet bereiken.
Goed:
Slecht:
Wanneer u een SQL-query als body meegeeft, kunt u body_format = Appsignal::EventFormatter::SQL_BODY_FORMAT gebruiken.

body_format-argument

Body format ondersteunt formatters om de gegeven data in het body-argument te scrubben om eventuele gevoelige data uit de waarde te verwijderen. Momenteel zijn er twee ondersteunde waarden voor het body_format-argument.
Appsignal::EventFormatter::DEFAULT-waarde
Appsignal::EventFormatter::DEFAULT is de standaardwaarde van dit argument. Standaard laat AppSignal de waarde intact en scrubt het geen data eruit.
Appsignal::EventFormatter::SQL_BODY_FORMAT-waarde
De waarde Appsignal::EventFormatter::SQL_BODY_FORMAT haalt uw data door de SQL-sanitizer en scrubt eventuele waarden in SQL-queries. We raden aan om hiervoor in plaats daarvan de Appsignal.instrument_sql-helper te gebruiken.

ActiveSupport::Notifications

In oudere versies van de AppSignal gem (1.2 en lager) is Appsignal.instrument niet beschikbaar. Als u niet kunt upgraden, is het nog steeds mogelijk om in plaats daarvan ActiveSupport::Notifications te gebruiken. Als u de Appsignal.instrument-helper niet wilt gebruiken, maar in plaats daarvan ActiveSupport::Notifications wilt gebruiken, kunt u dit ook nog steeds doen in AppSignal voor Ruby gem 1.3 en hoger.
De methode voor het instrumenteren van uw code met ActiveSupport::Notifications lijkt erg op hoe AppSignal het doet. Door het article-fetcher-voorbeeld opnieuw te gebruiken, ziet u dat de verschillen vrij klein zijn. Zie ook onze documentatie over AppSignal event formatters bij het gebruik van ActiveSupport::Notifications. Voor meer informatie over ActiveSupport::Notifications-instrumentation, zie de officiële Rails ActiveSupport::Notifications-documentatie.
Het werkt ook voor geneste instrumentation-aanroepen.
ActiveSupport::Notifications is zeer flexibel, u kunt uw code op elke gewenste manier instrumenteren. Meer informatie over ActiveSupport::Notifications is te vinden in de Rails API-docs.
Waarschuwing: We tracken geen private ActiveSupport::Notifications-events die met een uitroepteken (!) beginnen. Deze events omvatten meestal private events die door Rails worden gegenereerd.