Update exporters to include Pure Storage exporters.md

[genegr]

Added reference to Pure Storage exporter for FlashArray and FlashBlade.
Written using the Python Prometheus client, the Pure exporter is a quite consolidated project since three years and is widely used to monitor Pure appliances in several enterprise contexts.

[roidelapluie]

  - targets: [ mypureflashblade-01.lan ]
    labels:
      __pure_apitoken: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

This is unsecure, since that token will be displayed in the UI. Did you consider configuring the token in the exporter itself, or as part of the authorization parameter of prometheus, then passing it again to the actual target?

[RichiH]

Passing auth from Prometheus is also not recommended; what if you need to auth to get to the exporter, and the auth behind it is different? I recommend making an `auth` section in the exporter config, and passing this as a URL parameter

[genegr]

That is already the suggested method to use the exporter. The current version still supports both the options: the old one using the GET request parameter that was chosen mainly to condense multiple FlashArray/FlashBlade targets into the same Prometheus job and the new preferred one that uses the Authorization header. I am also thinking to deprecate the old method and remove it in the 2.0 version which uses the Pure REST API 2.x.

…

On Mon, Apr 12, 2021 at 11:33 AM Richard Hartmann ***@***.***> wrote: Passing auth from Prometheus is also not recommended; what if you need to auth to get to the exporter, and the auth behind it is different? I recommend making an `auth` section in the exporter config, and passing this as a URL parameter — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1920 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNLRL2FWFICL6TISVMRS53TIK46RANCNFSM42YI5CVA> .

[RichiH]

Would it be an option to deprecate the old mechanism in code and documentation now, and remove it with the next major release? That would give your users both more time to migrate, and a strong signal to not use the insecure legacy path.

[genegr]

Would it be an option to deprecate the old mechanism in code and documentation now, and remove it with the next major release? That would give your users both more time to migrate, and a strong signal to not use the insecure legacy path.

Done. Now the README states the old way of using the apitoken GET parameter is deprecated and will be removed from the next major release.

[RichiH]

Thanks!