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

Provide prometheus endpoint #50

Open
sebastianw opened this issue Jun 2, 2021 · 8 comments
Open

Provide prometheus endpoint #50

sebastianw opened this issue Jun 2, 2021 · 8 comments

Comments

@sebastianw
Copy link

Hello,

currently there is no way to get validation statistics out of FORT. It would be nice if you could provide a prometheus HTTP endpoint for it.

The format is described here:

https://prometheus.io/docs/instrumenting/exposition_formats/

Also there seems to be a C library for it:

https://github.com/digitalocean/prometheus-client-c

Maybe you could also take a look a the metrics that Routinator exports so that there is similarity between the endpoints:

https://routinator.docs.nlnetlabs.nl/en/stable/monitoring.html

@ties
Copy link

ties commented Jun 2, 2021

👍

In addition the http endpoint could serve the json.
Alternatively someone could build an orchestrator that creates metrics from logs (white-box approach) like I did with https://github.com/ties/rpki-client-web but a first party solution would be a lot better imo.

@ydahhrk
Copy link
Member

ydahhrk commented Jun 4, 2021

I understand this is important, but I'm not going to be able to squeeze it in my schedule in the near future.

Will report again in one month or earlier.

@pcarana
Copy link
Contributor

pcarana commented Jun 4, 2021

Closest effort is a fork that I've done a months ago, precisely using a customized C library based on that offered by DigitalOcean. Due to l a lack of time, I still can't finish it, but any help is really appreciated :)

The fork is at https://github.com/pcarana/FORT-validator, still needs some checks and also to define what data will be reported.

@ydahhrk
Copy link
Member

ydahhrk commented Jun 4, 2021

@pcarana Ok, thank you.

@ydahhrk
Copy link
Member

ydahhrk commented Jul 9, 2021

This is still far from feasible. Will report again in September or earlier.

@momorientes
Copy link

I too would greatly appreciate this feature, it's currently holding us back from retiring octorpki in favor of fort.

@rfc1036
Copy link

rfc1036 commented Aug 26, 2021

Me too! :-)

@ydahhrk
Copy link
Member

ydahhrk commented Sep 29, 2021

Question: Why do you need this?

I have a prototype, but it only tracks a small amount of statistics. I'm going to have to release 1.5.2 soon, so I'm debating whether I should include the prototype or not.

ydahhrk added a commit that referenced this issue Nov 9, 2021
Requested by Ties de Kock:

> Since some RPs now includes an upper limit on object size (some use
> 2MB if I recall correctly) I would appreciate a warning if an object
> goes over "a large fraction" of this limit (and a sample of the
> warning in the changelog and metrics if possible) - so people know
> what they need to alert on. In this situation operators can monitor
> for "natural growth" of an object and intervene, while the case that
> this check prevents (maliciously large objects) is still covered.
>
> The largest object I could find in the wild is 1.2MB (APNIC AS0 ROA).
> The RIPE NCC's largest object is smaller at the moment (but the CRL
> grows quickly if we do member CA keyrolls - since it adds all object
> on it).
>
> In summary:
>
> - I would recommend a warning (and preferably a metric) when an object
>   of 50% of the object size limit is encountered.
> - I would like it if the hard limit is "safe" - especially CRLs can
>   grow in some cases.

The metric will be added later, as part of #50. The warning is eg.

	File size exceeds 50% of the configured limit (10/20 bytes).

50% is hardcoded at the moment.

Notice that this is an HTTP-only patch. rsync does not warn.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants