tdeekens / promster

⏰A Prometheus exporter for Hapi, express and Marble.js servers to automatically measure request timings 📊

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clarification Needed (normalizePaths)

saby1101 opened this issue · comments

In path normalizer in @promster/metrics, url-value-parser is being used to prevent duplicate paths. /path/1 and /path/2 both map to /path/#val. However, url-value-parser has some issues. It doesn't detect every pattern, only certain (UUID, decimal, etc). So, if somebody hits the server with randomized urls (undetected by url-value-parser), it should go out of memory. In fact, the /metrics call can become so big it can timeout. How do I handle this?

urlValueParser.replacePathValues(url.parse(path).pathname);

Thanks for opening the issue.

Yes, path normalization is one of the most tricky things. In short: promster can not get it right for all consumers and just tries to give a reasonable default like most prometheus exporters.

It all comes down to cardinality in the end in prometheus and trying to minimize it as much as possible.

Given you have most knowledge about the system you are building and request types coming in you can either otherwrite normalizePath when configuring promster or implementing (more powerful) your own getLabelValues where you receive request and response and can return a path only in certain cases.

Lastly, I think some things should also be caught early in a system. For instance if you have a id being a uuid and a request is coming in with an int in that position the request should be rejected early.

Thanks for the clarification. However, I didn't understand what you meant by catching it early in the system. As far as I understand, the promster middleware will be sitting in front of my request handlers. Even if I handle it correctly in my handlers and exit early, promster will still add it to the histogram?

I wanted to note it as an additional safety net. One should still normalize the path (with both described measures) as aggressively as possible. However, a request validation middleware or system could also sit infront of everything additionally and reject requests which do not follow url schemes or defined routes to avoid flooding the server in a way.

Understood. Thanks again for clearing it up.