Tutorial 2 Obtain TOKEN index value based on HTTP protocol for subsequent collection and authentication
Through this tutorial, we will describe step by step how to modify on the basis of tutorial 1, add metrics, first call the authentication interface to obtain the TOKEN, and use the TOKEN as a parameter for the subsequent metrics collection and authentication.
Before reading this tutorial, we hope that you are familiar with how to customize types, metrics, protocols, etc. from Custom Monitoring and http Protocol Customization.
Dynamic UUID v4 in request bodies
Use {{v4uuid}} in an HTTP metric's payload to insert a random UUID v4. One UUID is generated at the start of each collection cycle and reused by all HTTP metrics in that cycle, including the authentication metric and later metrics. The next cycle generates a new UUID; different monitoring jobs have independent UUIDs.
For example, add a request ID to the HTTP configuration of a later metric in your custom monitoring template:
http:
host: ^_^host^_^
port: ^_^port^_^
method: POST
url: /api/data
headers:
Content-Type: application/json
Authorization: ^o^token^o^
payload: |
{"requestId":"{{v4uuid}}","correlation":{"id":"{{v4uuid}}"}}
parseType: jsonPath
parseScript: '$.data'
Adapt the endpoint, response fields and token name to your API. Both UUID placeholders above resolve to the same value. Add "requestId":"{{v4uuid}}" to the authentication metric's payload as well if both requests need to share that ID.
The placeholder also works inside a request body supplied through a monitoring parameter, such as payload: ^_^payload^_^. Static monitoring parameters and values from earlier metrics, such as ^o^token^o^, keep their existing behavior. UUID substitution applies only to the HTTP request body; it does not change headers, URLs or metric names. The stored template retains the placeholder for future collection cycles.