Show tag data in output or summary json without threshold?

Hey.

I just discovered you can add in thresholds for specific endpoints if they’ve been tagged correctly.

Adding these in add some nice extra information to your console output and summary json where you can get details on how each request performed by tag:

    http_req_duration..........: avg=102.08ms min=97.46ms med=103.64ms max=106.42ms p(90)=106.23ms p(95)=106.31ms
    ✓ { staticAsset:yes }......: avg=101.93ms min=97.46ms med=103.58ms max=106.42ms p(90)=106.12ms p(95)=106.3ms
        "http_req_duration": {
            "avg": 102.08474074074076,
            "max": 106.429,
            "med": 103.6465,
            "min": 97.46,
            "p(90)": 106.23450000000001,
            "p(95)": 106.31275000000001
        },
        "http_req_duration{staticAsset:yes}": {
            "avg": 101.93491666666667,
            "max": 106.422,
            "med": 103.58850000000001,
            "min": 97.46,
            "p(90)": 106.1215,
            "p(95)": 106.30625,
            "thresholds": {
                "p(95)<500": false
            }
        },

I was wondering if this was the only way to get this detail to show in the outputs? Is there a way to do this without setting a threshold?

Cheers,
gy.

Unfortunately, there’s currently no way to tell k6 to track a sub-metric besides defining a threshold on it…

Thank you for this question though! It jogged some things in my brain, resulting in a few ideas and the impetus to put them in a new issue. So, please have a look at Add explicit tracking and ignoring of metrics and sub-metrics · Issue #1321 · grafana/k6 · GitHub , and tell me if you see any issues with or improvements for the proposals listed there.

As @mark has pointed out in the github issue, you can also substitute any sub-metric by creating a Trend custom metric and populating its values manually. This is a bit more inefficient and requires some coding (a wrapper around http.request() or http.batch() to keep track of the things you’re interested in), but it’s a valid workaround until we implement the proper solution from that issue (or something like it).

Thanks @ned! New issue looks good and added to the conversation there.

2 Likes