+
Skip to content

update sizing guide with user event metrics info #35641

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.

Sign up for GitHub

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

Merged
merged 5 commits into from
Dec 9, 2024
Merged

update sizing guide with user event metrics info #35641

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1f35cb7
update sizing guide with user event metrics info
kami619 Dec 5, 2024
af79e59
update review feedback
kami619 Dec 5, 2024
0a43e4b
Update docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc
kami619 Dec 6, 2024
718a462
Review
kami619 Dec 6, 2024
30c9692
Review
ahus1 Dec 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,24 @@ For every 100 login/logout/refresh requests per second:

The vCPU requirement is given as a range, as with an increased CPU saturation on the database host the CPU usage per request decreases while the response times increase. A lower CPU quota on the database can lead to slower response times during peak loads. Choose a larger CPU quota if fast response times during peak loads are critical. See below for an example.

=== Measuring the activity of a running {project_name} instance

Sizing of a {project_name} instance depends on the actual and forecasted numbers for password-based user logins, refresh token requests, and client credential grants as described in the previous section.

To retrieve the actual numbers of a running {project_name} instance for these three key inputs, use the metrics {project_name} provides:

* The user event metric `keycloak_user_events_total` for event type `login` includes both password-based logins and cookie-based logins, still it can serve as a first approximate input for this sizing guide.
If you are using a standard username and password form and want to retrieve only the number of password-based logins, use the metric `http_server_requests_seconds_count` with method `POST` and URI `+/realms/{realm}/login-actions/authenticate+` instead.
* Use the user event metric `keycloak_user_events_total` for the event types `refresh_token` and `client_login` for refresh token requests and client credential grants respectively.

See the <@links.observability id="event-metrics"/> and <@links.observability id="metrics-for-troubleshooting-http"/> {sections} for more information.

These metrics are crucial for tracking daily and weekly fluctuations in user activity loads,
identifying emerging trends that may indicate the need to resize the system and
validating sizing calculations.
By systematically measuring and evaluating these user event metrics,
you can ensure your system remains appropriately scaled and responsive to changes in user behavior and demand.

=== Calculation example (single site)

Target size:
Expand Down
1 change: 1 addition & 0 deletions docs/guides/observability/metrics-for-troubleshooting-http.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ Spikes or increases in the processing time may be an early sign that some node i
====
*Tags*

`method`:: HTTP method.
`outcome`:: A more general outcome tag.
`status`:: The HTTP status code.
`uri`:: The requested URI.
Expand Down
Loading
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载