Content-type problem

[soso-bc]

Checklist

• I have read and followed the above instructions

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there or the fix did not work.

Describe the issue

Hello,

This question is dedicated to the kvaster/zwavejs-prom plugins with which I have encountered an encoding problem since I upgraded my prometheus server.
So I apologize if I am not asking my question in the right project.
Despite everything, I have consulted the plugin code and I think that my problem is related to the http server carried by zwave js ui.

This new version of prometheus tells me that the content-type of the metrics returned by the plugin is not in the right format: text/html while prometheus expects text/plain (https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format).
As a result, it is not able to exploit the data.

Is it possible to overload the format in the context of the plugin?
Another possibility is that I could modify the file ./node_modules/@kvaster/zwavejs-prom/index.js to impose this format (which would be more logical). But, I don't see how to exploit the this.app variable (in the constructor) to achieve this!

Thanks

Software versions

Z-Wave Controller (Stick/Dongle/...)

No response

Device information

No response

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

No response

[zwave-js-bot]

👋 Hey @soso-bc!

Thanks for opening an issue! It doesn't look like you provided a logfile though. While not strictly necessary for every issue, having a driver log on loglevel debug is required to diagnose most issues.

Please consider uploading a logfile that captures your problem. As a reminder, here's how to create one:

• Z-Wave JS UI
• Home Assistant Z-Wave Integration
• ioBroker.zwave2 Adapter

[AlCalzone]

I think this belongs in the zwave-js-ui repository. I can move the issue tomorrow, or you close it and open a new one in the correct repo.

[kpine]

The prom-exporter plugin is an external project by a different maintainer: https://github.com/kvaster/zwavejs-prom

The plugin code is responsible for setting up the /metrics endpoint request handler and sending the response including setting the content type. Here's the existing code from the plugin:

https://github.com/kvaster/zwavejs-prom/blob/ece34753358848b24ab478e3c689e28c942797c8/index.js#L79-L81

    async sendMetrics(req, res) {
        this.registry.metrics().then((m) => res.send(m))
    }

Compare to the example code from the upstream prom-client project, which shows that the request handler needs to set the content type:

https://github.com/siimon/prom-client/blob/c1d76c5d497ef803f6bd90c56c713c3fa811c3e0/example/server.js#L92-L99

server.get('/metrics', async (req, res) => {
	try {
		res.set('Content-Type', register.contentType);
		res.end(await register.metrics());
	} catch (ex) {
		res.status(500).end(ex);
	}
});

And where the default content type is set to text/plain for Prometheus:

https://github.com/siimon/prom-client/blob/c1d76c5d497ef803f6bd90c56c713c3fa811c3e0/lib/registry.js#L6-L8

	static get PROMETHEUS_CONTENT_TYPE() {
		return 'text/plain; version=0.0.4; charset=utf-8';
	}

Since the plugin code is missing the content type setting, if I had to guess text/html is the default type that Express uses when it's undefined. So it would look like the plugin code needs to be fixed. This is all speculative to me but it makes sense from code observation, what do you think?

[AlCalzone]

Makes sense to me. Closing since I can't move the issue there.

[kpine]

Just another note, the Prometheus 3 migration guide provides guidance for handling applications that don't set the right Content-Type as this was a breaking change introduced by Prometheus:

https://prometheus.io/docs/prometheus/latest/migration/#scrape-protocols

If a scrape target is not providing the correct Content-Type header the fallback protocol can be specified using the fallback_scrape_protocol parameter. See Prometheus scrape_config documentation.

Setting this for your scrape config should restore the previous behavior without having to change the plugin (though still preferred):

fallback_scrape_protocol: PrometheusText0.0.4

[soso-bc]

Hello @AlCalzone @kpine,

Thank you for your feedback and sorry for the late response but I am in a Paris time zone...
I also agree.. I will look into modifying the pluings and if not modifying the prometheus configuration.

Thank you both!

[soso-bc]

@kpine
Thank you very much for your suggestions / leads.
I modified the plugins to force the format without changing the configuration of my prometheus (effectively in v3).
Everything purrs ;)

Thanks!

$ grep -n 'register[;.]' Docker/plugins/zwavejs-prom/index.js
5:const register = promCli.register;
81: res.set('Content-Type', register.contentType);