Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
88 changes: 88 additions & 0 deletions blog/2026-06-22-observability-launch.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: Observability for Keycloak, with Zero Setup
slug: observability-launch
date: 2026-06-22
authors: phasetwo
tags:
[
phase_two,
hosting,
self-service,
observability,
metrics,
logs,
keycloak,
dedicated-clusters,
]
description: Phase Two Observability is here. View requests, event data, and live logs for your dedicated Keycloak cluster with zero setup — built right into the dashboard.
---

Today we're launching **Observability** for dedicated Keycloak clusters — built directly into the Phase Two dashboard with **zero setup**. Requests, event data, and live logs are all there the moment your cluster is running. No agents to install, no log shippers to configure, no Prometheus, Grafana, or Loki stack to stand up and maintain.

<!-- truncate -->

This is the feature we're most excited about this year, because of what it changes about getting Keycloak into production. Standing up the observability layer around a Keycloak cluster — metrics pipelines, log aggregation, dashboards, alerting — is the kind of work that normally takes a devops team **weeks to months**. With Phase Two, it's already done. Getting up and running on a fully observable Keycloak cluster is now a matter of **minutes**.

:::info
**Available for Dedicated Clusters**
Observability is included with all Phase Two **dedicated cluster** plans. Open the **Metrics** or **Logs** section on your cluster in the [self-service dashboard](https://dash.phasetwo.io/clusters) to get started.
:::

## See your whole system at a glance

Start with the big picture: _understanding what your cluster is doing_, at a glance, without building a single chart yourself.

**Event Metrics** chart Keycloak authentication and admin activity over any time range: user events by type, successful and failed logins, active users per day, new registrations, password resets, MFA enrollment, and login-error reasons.

<figure>
<img src="/docs/observability/user-events.png" alt="Event Metrics — user events by type charted over time" />
<figcaption>Event Metrics: authentication and admin activity, derived from Keycloak events.</figcaption>
</figure>

**Request Metrics** chart the HTTP traffic and performance of the cluster: requests by endpoint type and status class, error rate, cache hit ratio, latency and TTFB percentiles (p50 / p95 / p99), bytes served, top endpoints, and top user agents.

<figure>
<img src="/docs/observability/requests.png" alt="Request Metrics — requests by endpoint type charted over time" />
<figcaption>Request Metrics: HTTP traffic, errors, caching, and latency for the cluster.</figcaption>
</figure>

Spot an anomaly in a chart, then drop straight into the logs to find the exact requests and events behind it. The metrics tell you _something changed_; the logs tell you _exactly what_.

## Debugging that takes minutes, not days

When something goes wrong with an authentication flow — a login that fails intermittently, a theme that won't load, a token error that only some users hit — the slowest part has always been _seeing what actually happened_. Traditionally that meant SSH-ing into nodes, grepping through container logs, or waiting for someone with cluster access to pull the right files.

Phase Two Observability collapses that loop. Open the **Logs** section, filter to the realm and time window, and watch the relevant lines stream in live.

<figure>
<img src="/docs/dashboard/cluster-observability-stream-logs-2.png" alt="Phase Two Dash — live Cluster Logs streaming with filters for time range, realm, level, and search" />
<figcaption>Stream and inspect cluster logs live — filter by time range, realm, and level, then click any line for the full structured payload.</figcaption>
</figure>

The streaming view gives you everything you need to chase down an issue without leaving the browser:

- **Live streaming** with auto-refresh, so new lines appear as they happen
- **Realm and level filters** (`INFO`, `WARN`, `ERROR`, `DEBUG`, `TRACE`, `FATAL`)
- **LogQL-style search** — `|=` to match, `!=` to exclude, `|~` for regex. For example, `|= "LOGIN_ERROR" != "admin-cli"` finds login failures while filtering out a known source, and `|= "NullPointerException"` surfaces Java exception lines instantly.
- **Click into any line** to open the full payload, logger name, and stack trace

What used to be a multi-hour, multi-person investigation becomes a few clicks.

## What's included

Observability is split into two sections in the dashboard, both fully time-range and realm filterable, with all timestamps in **UTC**:

- **Metrics** — [Event Metrics](https://phasetwo.io/docs/self-service/metrics/#event-metrics) and [Request Metrics](https://phasetwo.io/docs/self-service/metrics/#request-metrics): aggregated, charted views of authentication activity and HTTP traffic.
- **Logs** — [Cluster Logs](https://phasetwo.io/docs/self-service/logs/#cluster-logs) (live streaming), [Event Logs](https://phasetwo.io/docs/self-service/logs/#event-logs), [Request Logs](https://phasetwo.io/docs/self-service/logs/#request-logs), and [Download Logs](https://phasetwo.io/docs/self-service/logs/#download-logs) for retained files you can pull for offline review, auditing, or support cases.

This is the full realization of the observability work we [previewed back in February](https://phasetwo.io/blog/cluster-observability-and-logs/), which started with log downloads. Live streaming, structured event and request views, and the metrics charts are all here now.

## Why this matters

Running Keycloak yourself means running everything around it too — and the observability stack is one of the heaviest parts of that "everything." Phase Two gives you that layer for free, built in, from the moment your cluster comes up. Your team spends its time shipping authentication features and resolving issues, not building and babysitting monitoring infrastructure.

Zero setup. Requests, events, and logs in one place. Debugging in minutes. A production-ready, observable Keycloak cluster in the time it takes to read this post.

---

Ready to try it? Log in to the [Phase Two Dash](https://dash.phasetwo.io/clusters) and open the **Metrics** and **Logs** sections on your cluster. Learn more in the [Observability documentation](https://phasetwo.io/docs/self-service/observability/). Questions? Reach us at [support@phasetwo.io](mailto:support@phasetwo.io).
75 changes: 63 additions & 12 deletions docs/self-service/logs.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Use **Cluster Logs** when you need to investigate a recent issue, narrow activit
If you have not selected a time range yet, the streaming view starts with the last hour of logs.

<figure>
<img src="/docs/dashboard/cluster-observability-stream-logs.png" className="max-w-2xl" alt="Phase Two Dash - Cluster Logs" />
<img src="/docs/dashboard/cluster-observability-stream-logs-2.png" className="max-w-2xl" alt="Phase Two Dash - Cluster Logs" />
<figcaption>Stream and inspect logs</figcaption>
</figure>

Expand Down Expand Up @@ -80,33 +80,84 @@ Use the dedicated **Realm** and **Level** filters when possible instead of encod

## Event Logs

**Event Logs** show Keycloak event entries — logins, registrations, admin actions, and similar — over the selected time range, with the same time-range and realm filters as the streaming view. Use these when you want to follow authentication activity as discrete events rather than raw cluster log lines.
**Event Logs** show Keycloak event entries — logins, registrations, admin actions, and similar — over the selected time range. Use these when you want to follow authentication activity as discrete, structured events rather than raw cluster log lines.

:::note Screenshot needed
`logs-events.png` — the Event Logs view listing Keycloak event entries.
:::
Event Logs are split into two tabs that share the common time-range and realm filters. A realm must be selected to view events.

<figure>
<img src="/docs/dashboard/cluster-observability-event-logs.png" className="max-w-2xl" alt="Phase Two Dash - Event Logs" />
<figcaption>Browse Keycloak user and admin events</figcaption>
</figure>

### User events

User events cover authentication and account activity — logins, logouts, registrations, token exchanges, and similar. Alongside the shared filters, you can narrow by:

- **Event type** (for example `LOGIN`, `LOGOUT`, `CODE_TO_TOKEN`)
- **User ID**
- **Client ID**
- **IP address**
- **Search (details)** — free-text match against the event details

The results table shows **Time**, **Type**, **User**, **Client**, **IP**, and **Error**.

### Admin events

Admin events cover administrative changes made through the admin console or API. The filters here are:

- **Resource type** (for example `USER`, `CLIENT`)
- **Operation** (for example `CREATE`, `UPDATE`, `DELETE`)
- **Resource path** (for example `users/…`)
- **User ID** and **Client ID**
- **Search (repr/details)** — free-text match against the representation or details

The results table shows **Time**, **Resource**, **Operation**, **Path**, **Auth user**, **IP**, and **Error**.

### Limit and row count

Choose how many rows to fetch with **Limit** (`100`, `200`, `500`, `1000`, `2000`, or `5000`; default `500`). The count above the table shows how many rows matched, and notes when results are capped at the selected limit.

### Inspecting an event

Click any row to open the detail drawer. It shows the full structured **Event** record, the **Details** payload, and — for admin events — the changed **Representation**. Each section is JSON-formatted and can be copied directly.

## Request Logs

**Request Logs** present individual HTTP requests in a structured, sortable table. Columns include:
**Request Logs** present individual HTTP requests in a structured table over the selected time range. Unlike Event Logs, a realm is not required — by default you see requests across the whole cluster, and realm is an optional filter.

<figure>
<img src="/docs/dashboard/cluster-observability-request-logs.png" className="max-w-2xl" alt="Phase Two Dash - Request Logs" />
<figcaption>Inspect individual HTTP requests</figcaption>
</figure>

### Filters

In addition to the shared time-range filter, you can narrow requests by:

- **Endpoint type** (for example `oidc`, `admin`)
- **Status class** — `All`, `2xx`, `3xx`, `4xx`, or `5xx`
- **Method** (for example `GET`, `POST`)
- **Host header**
- **Client IP**
- **Realm (optional)**
- **Path contains** — free-text match against the request path
- **Limit** — `100`, `200`, `500`, `1000`, `2000`, or `5000` (default `500`)

### Columns

- **Time**, **Method**, **Status**, **Type** (endpoint type)
- **Host**, **Path**
- **Customer**, **Realm**
- **Cache** (edge result), **Latency (s)**, **IP**

Click a row to open a detail drawer with the full request record. Request Logs pair well with the [Request Metrics](./metrics.md#request-metrics) charts: use the charts to spot an anomaly, then drop into Request Logs to find the specific requests behind it.

:::note Screenshot needed
`logs-requests.png` — the Request Logs table with the request detail drawer open.
:::
Click a row to open a detail drawer with the full request record as JSON, which you can copy directly. Request Logs pair well with the [Request Metrics](./metrics.md#request-metrics) charts: use the charts to spot an anomaly, then drop into Request Logs to find the specific requests behind it.

## Download Logs

Use **Download Logs** when you need retained logs for offline review, auditing, or support cases.

<figure>
<img src="/docs/dashboard/cluster-observability-download-logs.png" className="max-w-2xl" alt="Phase Two Dash - Download Logs" />
<img src="/docs/dashboard/cluster-observability-download-logs-2.png" className="max-w-2xl" alt="Phase Two Dash - Download Logs" />
<figcaption>Browse and download retained log files</figcaption>
</figure>

Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.