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

New and updated Prometheus metrics #3844

Merged
merged 7 commits into from
Aug 15, 2024
Merged

Conversation

tillprochaska
Copy link
Contributor

@tillprochaska tillprochaska commented Aug 12, 2024

This PR adds a few new metrics and extends existing metrics based on feedback. I’d recommend taking a look at the individual commits when reviewing this PR.

Corresponding documentation changes are in #3845 because the release/4.0.0 branch doesn’t yet have the recently updated tech docs from develop.

Users

I’ve added new active and locale labels to the aleph_users metric. This allows querying for the number of active users (e.g. within last 24h, 7d, 30d, …) and the number of users that use a specific UI locale.

# Number of all users
aleph_users{active="all"}

# Number of all users using the (default) English localization
aleph_users{locale="en", active="all"}

# Number of monthly active users using the German localization
aleph_users{active="30d", locale="de"}

Collections

Previously, there was a single aleph_collections metric that allowed querying for the number of collections by category (e.g. "casefile", "leak", "gazette", …). I have renamed this metric to be consistent with two new metrics that expose the number of collections by country and language.

# Number of leaks
aleph_collection_categories{category="leak"}

# Number of datasets or investigations
aleph_collection_categories{type="dataset"}
aleph_collection_categories{type="investigation"}

# Number of datasets or investigations by country
aleph_collection_countries{type="dataset", country="fr"}
aleph_collection_countries{type="investigation", country="fr"}

# Number of datasets or investigations by language
aleph_collection_languages{type="dataset", language="fra"}
aleph_collection_languages{type="investigation", language="fra"}

Entities

I’ve added a new metric to track the number of entities per schema type. This re-uses collection statistics that are pre-computed and cached in Redis, i.e. we do not send any (potentially expensive) ES aggregation queries during metrics collection.

# Number of `Person` entities
aleph_entities{schema="Person"}

API HTTP requests

I have added a new label auth_method to the aleph_http_requests_total. This allows us to query for the number of API requests that used an API key vs. a UI session token.

# Number of requests to `/api/2/entities` using an API key
aleph_http_requests_total{api_endpoint="entities.index", auth_method="api_key"}

Previously, there was one `aleph_collections` metric with a `category` label. In addition to collection counts by category, we also want to track collection counts by country and languages. In order to keep metric cardinalities under control, I've decided to split the `aleph_collections` metric into three separate metrics: `aleph_collection_categories`, `aleph_collection_countries`, and `aleph_collection_languages`.

Each of these metrics has one additional label `type` which can be either `dataset` or `casefile`. This allows to query for the datasets or investigations in a particular language or related to a particular country.

I have also removed the `category` label from the `aleph_collection_users` metric as it wasn't that useful.
This allows us to get a better understanding of API requests that originate from the UI and requests from third parties using an API key.
@tillprochaska
Copy link
Contributor Author

@catileptic This is now ready for review, even though one test is still failing. As discussed, this test fails because of an update of the phonenumbers Python package. The new version of the package has validation changes, and as a result phone numbers used in that particular test are determined to be invalid which causes the test to fail.

I haven’t yet understood completely whether phonenumbers is actually right about thes test phone numbers and the numbers are indeed invalid or if this is a regression and they should be treated as valid. At first glance they look like a reasonable German mobile phone number, but phone number prefixes in Germany are weird.

I’ll keep the test as is until I’ve found a definitive answer, but that shouldn’t block a review of the actual changes proposed in this PR.

Copy link
Contributor

@catileptic catileptic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. Really appreciate adding the tests! Let's get this merged.

This test started to fail with an upgrade of the `phonenumbers` package (imported via `followthemoney`) which included updated phone number validation rules. As a result, the phone numbers in this test case didn’t pass validation anymore and were cleaned from the entites created.

At first glance these numbers seemed to be valid German mobile phone numbers and I was worried that there might be a regression in `phonenumbers`. But according to the International Telecommunication Union, a phone number with the prefix `176` has to be 11 digits long. I adjusted the tests accordingly.

https://www.itu.int/oth/T0202000051/en
@tillprochaska tillprochaska merged commit 8d9a478 into release/4.0.0 Aug 15, 2024
2 checks passed
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

Successfully merging this pull request may close these issues.

2 participants