Artillery v2.0.0-36

[hassy]

New features

• Dynatrace support - the official publish-metrics plugin can now be configured to send Artillery metrics and events to Dynatrace. Read more in the docs. (140ee92)
• config.http.defaults - default headers and cookies for all requests in a test may now be set via config.http.defaults (938f9c4)

Fixes & improvements

Artillery Dashboard (join the waitlist)

• Send load phase start/end timings for visualization (feat: send load phase events to cloud dashboard #2022)
• Send CLI exit code to display in test run results (407d225)
• Fix test run status not always getting reported correctly (48a4a91)
• Fix bug which caused test runs on AWS Lambda to not be tagged correctly (919327f)

Core

• Allow variables set with --variables to be used anywhere in config (c08c695)
• Fix for encoding of array values in query strings (06989c6)
• Make sure CLI exit handlers are always run (77f6423)
• Fix bug affecting match groups in regexp captures (e92306e)

Plugins

• publish-metrics - Exit early if required config is missing for publish-metrics (7871d39)
• publish-metrics - Reduce memory usage of the plugin (338b070)
• expect - add useRequestNamesOnly option (feat: log expectations by request name #1995)
• ensure - fix bug where ensure config under config.plugins.ensure would not get picked up (d1136f3)

This release brought to you by @InesNi @bernardobridge @hassy

---

This discussion was created from the release Artillery v2.0.0-36.

[Thilaknath]

Hello Team, @hassy I am trying to use the dynatrace plugin to publish metrics. But I get the following error

 plugin:publish-metrics:dynatrace Metrics sent to Dynatrace +1ms
⠋   plugin:publish-metrics:dynatrace Sending event to Dynatrace +5s
  plugin:publish-metrics:dynatrace Cleaning up +2ms
  plugin:publish-metrics:dynatrace Waiting for pending request ... +0ms
⠴   plugin:publish-metrics:dynatrace There has been an error in sending event to Dynatrace:  HTTPError: Response code 404 (Not Found)
    at Request.<anonymous> (/usr/local/lib/node_modules/artillery/node_modules/got/dist/source/as-promise/index.js:118:42)
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  code: 'ERR_NON_2XX_3XX_RESPONSE',
  timings: {
    start: 1694441764452,
    socket: 1694441764452,
    lookup: 1694441764453,
    connect: 1694441764572,
    secureConnect: 1694441764688,
    upload: 1694441764688,
    response: 1694441764806,
    end: 1694441764808,
    error: undefined,
    abort: undefined,
    phases: {
      wait: 0,
      dns: 1,
      tcp: 119,
      tls: 116,
      request: 0,
      firstByte: 118,
      download: 2,
      total: 356
    }
  }
} +359ms

I am trying to publish to our centrally managed dynatrace instance at our org. I have the credential and url configured properly. Am i missing something ?

[Thilaknath]

Update: The rejection dashboard was of no use as I was not seeing any data for the time frame I was trying to ingest data.

[Thilaknath]

Update: I am not sure why the 400 bad request is there. But i see some data points in dynatrace after removing the management filter

[InesNi]

Great @Thilaknath 🎉, glad we've made progress.

I'll continue trying to replicate the 400 bad request with your config and/or try to see if it's possible to get a more meaningful error message from Dynatrace's API. In the meantime, at least it seems you are able to get data into the platform.

[Thilaknath]

Yes and Thank you for your support @InesNi

[InesNi]

Hi @Thilaknath,

I realised that the issue might be with the / being created by metrics from the metrics-by-endpoint plugin (which I think is the same issue you're facing in one of the open-telemetry debug logs you showed). Dynatrace doesn't accept those characters.

As a workaround, you should be able to do the following:

1. Set your config to use useOnlyRequestNames (https://www.artillery.io/docs/reference/extensions/metrics-by-endpoint#plugin-configuration)

plugins:
   metrics-by-endpoint:
      useOnlyRequestNames: true

2. name your requests with a string that follows this convention:

scenarios:
  - flow:
      - get:
          url: "/actuator/health"
          name: actuator

---

I'll work on a fix for the reporter, but I've tested the workaround above, and was able to get past the 400 Bad Request issue, so you should be able to use this for now 🤞🏻 .