Feature/custom metrics

[luissimas]

Hello!

This is a proposal for the implementation of custom metrics for this extension. As described in #13, currently there are no custom metrics for the Diameter protocol. It would be valuable to provide metrics regarding request latency and the number of requests handled per second, as those are key results that cannot be properly expressed by the default VU metrics (specially in test scenarios where we issue multiple requests to the server, such as in a SIP authentication flow).

My proposal is to add the following metrics (I've marked the ones that are already implemented by this PR):

• diameter_req_count to track the number of requests handled during the test
• diameter_req_duration to track the response time of each individual request
• diameter_req_failed to track the rate of failed requests. In this case it would be nice to provide an API similar to HTTP's setResponseCallback to allow the user to define what is a failure response

With that said, this implementation requires some refactoring in the way that we export the modules to the JavaScript runtime, and I'm not very familiar with this API.

I'd like to know what you guys think about the proposal and also the design of the implementation.

Before

After

[luissimas]

I'm currently having an issue with this implementation. For some reason when I call console.log on the messages they are not being printed anymore. I'd guess that's something to do with the changes in the way the module is exported, but I'll look into it.

          /\      |‾‾| /‾‾/   /‾‾/
     /\  /  \     |  |/  /   /  /
    /  \/    \    |     (   /   ‾‾\
   /          \   |  |\  \ |  (‾)  |
  / __________ \  |__| \__\ \_____/ .io

  execution: local
     script: tests/example.js
     output: -

  scenarios: (100.00%) 1 scenario, 1 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 1 iterations shared among 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)

INFO[0004] Connected to localhost:3868
INFO[0006] UAA 1 {}                                      source=console
INFO[0006] MAA {}                                        source=console
INFO[0006] UAA 2 {}                                      source=console
INFO[0006] SAA  {}                                       source=console
INFO[0006] LIA  {}                                       source=console
INFO[0006] 2001                                          source=console
INFO[0006] 2001                                          source=console
INFO[0006] 2001                                          source=console

     ✗ Success Result-Code
      ↳  60% — ✓ 3 / ✗ 2

     checks..................: 60.00% ✓ 3        ✗ 2
     data_received...........: 0 B    0 B/s
     data_sent...............: 0 B    0 B/s
     diameter_req_count......: 5      1.96493/s
     diameter_req_duration...: avg=486.1ms min=66.46ms med=73.46ms max=2.07s p(90)=1.3s  p(95)=1.68s
     iteration_duration......: avg=2.54s   min=2.54s   med=2.54s   max=2.54s p(90)=2.54s p(95)=2.54s
     iterations..............: 1      0.392986/s
     vus.....................: 1      min=1      max=1
     vus_max.................: 1      min=1      max=1


running (00m02.5s), 0/1 VUs, 1 complete and 0 interrupted iterations
default ✓ [======================================] 1 VUs  00m02.5s/10m0s  1/1 shared iters

[lwlee2608]

I'm on vacation, I'll get back to you once I am back.

[lwlee2608]

can be made slightly more efficient:

now := time.Now()
c.reportMetric(c.metrics.RequestDuration, now, metrics.D(now.Sub(sentAt)))
c.reportMetric(c.metrics.RequestCount, now, 1)

[lwlee2608]

@luissimas Regarding diameter_req_failed, let's keep it simple by only tracking failed diameter responses in scenarios such as timeouts or invalid messages. Users can use checks(resultCode {}) to track diameter messages with unexpected result codes.

[lwlee2608]

I'm currently having an issue with this implementation. For some reason when I call console.log on the messages they are not being printed anymore. I'd guess that's something to do with the changes in the way the module is exported, but I'll look into it.

I'm not sure what's happening either, but it seems to work with:

    console.log("CCA: ", cca.string())
    console.log(`CCA: ${cca}`)

[luissimas]

@luissimas Regarding diameter_req_failed, let's keep it simple by only tracking failed diameter responses in scenarios such as timeouts or invalid messages. Users can use checks(resultCode {}) to track diameter messages with unexpected result codes.

Agreed. After some thought I think that the current checks is a better solution. I'm kinda busy at the start of this week, but I'll implement the metric for timeouts when get the time

[luissimas]

I'm currently having an issue with this implementation. For some reason when I call console.log on the messages they are not being printed anymore. I'd guess that's something to do with the changes in the way the module is exported, but I'll look into it.

I'm not sure what's happening either, but it seems to work with:

    console.log("CCA: ", cca.string())
    console.log(`CCA: ${cca}`)

Yes, explicitly converting the object to a string seems to work on my end as well. I've updated the docs to show working examples. Would you consider this a block for merging this PR?

[lwlee2608]

Thank you for your contribution!