Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a listener or wasm-id label to the Prometheus stats #258

Open
iMaxGit opened this issue Feb 20, 2024 · 3 comments
Open

Adding a listener or wasm-id label to the Prometheus stats #258

iMaxGit opened this issue Feb 20, 2024 · 3 comments

Comments

@iMaxGit
Copy link

iMaxGit commented Feb 20, 2024

Hi,

we use different listeners in our envoy configuration. To be able to track coraza interventions on a per listener level for better visibility in the prometheus stats, it would be useful to add an additional label to identify the corresponding wasm instance. The listener name would be most helpful in our case, but also the wasm-id should work, if this is easier/quicker to implement, as we can configure it accordingly in our envoy configuration.

@jcchavezs
Copy link
Member

Indeed necessary. Up for a PR?

@iMaxGit
Copy link
Author

iMaxGit commented Feb 22, 2024

I am not a (Go) programmer, but I assume it would not be too complicated to do. I will give it a try and submit it for review once I have working implementation.

@iMaxGit
Copy link
Author

iMaxGit commented Feb 24, 2024

@jcchavezs I had a look at the data accessible by the wasm plugin and I could not find an option to retrieve the listener name or wasm plugin name. If there is a way to get those, please let me know.
If this is not possible then I would suggest to use an additional configuration option, like "stats_prefix" for example. I was pondering using the vm-id, as it is already available to the plugin. However, this might not be practical as it could impact efficiency, as it would prohibit running the plugin from two different listeners or filter chains in the same vm context, if the vm-id is different. Using an additional "stats_prefix" option would give the freedom to separate or consolidate different instances as one sees fit from a statistics point of view.

Any thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants