Grafana OSS JSON Server Log
Grafana OSS 9.5.1 server log lines in the JSON log format, wrapped in ECS JSON, for testing detections of login abuse and service account token creation in Grafana. One instance with router logging on serves 80 browser users, four of them organization admins, and four service accounts that call the HTTP API around the clock; about 32,000 lines a day follow a working-day curve in UTC. Recurring episodes show failed form logins from one admin workstation address, a successful login and a service account token creation.
Quick Start
uv tool install eventum-generator
git clone https://github.com/eventum-generator/content-packs.git
cd content-packs
eventum generate \
--path generators/application-grafana-server-json/generator.yml \
--id grafana \
--live-mode trueEvent Types
| Event ID | Description | Frequency | Category |
|---|---|---|---|
| POST /api/ds/query 200 | Request Completed line for a data source query | 43.7% of lines | web |
| GET /api/dashboards/uid/<uid> 200 | Request Completed line for a dashboard read | 13.2% of lines | web |
| GET /api/annotations 200 | Request Completed line for an annotations read | 11.6% of lines | web |
| GET /api/search 200 | Request Completed line for a dashboard search | 10.2% of lines | web |
| POST /api/frontend-metrics 200 | Request Completed line for frontend metrics | 7.5% of lines | web |
| GET /api/user 200 | Request Completed line for the signed-in user | 4.9% of lines | web |
| GET / 200 | Request Completed line for the home page | 4.2% of lines | web |
| Successful Login | http.server message after a form login | 1.23% of lines | authentication |
| POST /login 200 | Request Completed line for a successful form login | 1.23% of lines | web, authentication |
| GET /login 200 | Request Completed line for the login page | 0.85% of lines | web |
| Successful Logout | http.server message on logout | 0.36% of lines | authentication |
| GET /logout 302 | Request Completed line for a logout redirect | 0.36% of lines | web |
| GET /api/serviceaccounts/search 200 | Request Completed line for a service account search | 0.19% of lines | web |
| Invalid username or password | context logger error line for a failed form login, with the lockout text after repeated failures | 0.13% of lines | authentication |
| POST /login 401 | Request Completed line for a failed form login | 0.13% of lines | web, authentication |
| GET /api/serviceaccounts/<id>/tokens 200 | Request Completed line for a service account token list | 0.13% of lines | web |
| POST /api/serviceaccounts/<id>/tokens 200 | Request Completed line for a service account token creation | 0.06% of lines | web |
| DELETE /api/serviceaccounts/<id>/tokens/<tokenId> 200 | Request Completed line for a service account token deletion | 0.06% of lines | web |
Realism Features
- 80 browser users, four of them organization admins, sign in with the login form, open dashboards and run data source queries, occasionally mistype passwords, give up or hit the brute-force lockout (the sixth failure within five minutes gets the lockout text), and sign out. About 9% of POST /login requests fail: about one admin login in six starts with one or more failures, against one in twenty-five for other users. A session lasts about 40 minutes (median, up to eight hours); admins work in sessions of about 15 minutes and sign in about 11 to 17 times a day. About 30% of sessions end with an explicit logout.
- Admins list, create and delete service account tokens: about 15 tokens a day, mostly for the service account each admin looks after, each deleted later by an admin signed in at that time, usually within an hour (a token created late in the day may stay until the next morning). Four service accounts call the API with bearer tokens at a flat 0.05 lines/s, day and night.
- Browser users follow a working-day curve in UTC: about 0.07 lines/s at night, rising from 05:00, peaking at about 0.95 lines/s near 10:40 and back to the night level after 18:00, with about 15 distinct accounts active an hour at night and about 70 at the peak. Weekends look like weekdays. Requests of a session are seconds to minutes apart, so the burst of panel queries a real dashboard load makes within one second is not reproduced; the two lines of one request are microseconds apart. Request mix, session lengths, sign-in frequency, failure rates, token activity and data request durations and sizes are synthetic.
- event.original is compact JSON with alphabetically sorted keys, an RFC 3339 t with up to nine fractional digits (trailing zeros dropped), and level, logger and msg on every line; four real 9.5.0/9.5.1 lines in Grafana issue 67582 confirm the layout and the Request Completed field set. Request Completed fields follow the 9.5.1 request logging middleware: Go duration text, whole-millisecond time_ms and the registered route pattern in handler, whose trailing-slash forms for /api/search and /api/user are inferred from route registration. Login, logout and token-deletion body sizes are exact.
- Ordinary traffic in both modes contains failed logins by every admin, runs of three or more failures from one address within 10 minutes (about 4-5 a day), lockouts (about one a day), three or more failures followed by a successful login (about 2 a day) and token creations within ten minutes of a login (about 6 a day). The failed-login line names no username, so failures of different accounts from one address look the same.
- Grafana defaults to text logs and router_logging = false; with router logging off only the 302 and 401 request lines and the Invalid username or password, Successful Login and Successful Logout messages remain. Not modeled: static files, /api/health probes, live websocket traffic, 304, 403, 404 and 5xx responses, expired-session and API-key authentication, LDAP/OAuth/JWT logins, alerting and provisioning logs, and tracing (traceID stays empty). The clock is UTC; ECS fields repeat values from the native line only.
Sample Output
{
"@timestamp": "2026-09-01T12:45:46.243362+00:00",
"ecs": {
"version": "8.17.0"
},
"event": {
"action": "invalid-username-or-password",
"category": [
"authentication"
],
"dataset": "grafana.server",
"kind": "event",
"module": "grafana",
"original": "{\"error\":\"invalid username or password\",\"level\":\"error\",\"logger\":\"context\",\"msg\":\"Invalid username or password\",\"orgId\":0,\"remote_addr\":\"10.40.2.21\",\"t\":\"2026-09-01T12:45:46.243362334Z\",\"traceID\":\"\",\"uname\":\"\",\"userId\":0}",
"outcome": "failure",
"reason": "invalid username or password",
"type": [
"info"
]
},
"grafana": {
"log": {
"error": "invalid username or password",
"level": "error",
"logger": "context",
"msg": "Invalid username or password",
"orgId": 0,
"remote_addr": "10.40.2.21",
"t": "2026-09-01T12:45:46.243362334Z",
"traceID": "",
"uname": "",
"userId": 0
}
},
"host": {
"name": "grafana-01"
},
"log": {
"level": "error",
"logger": "context"
},
"message": "Invalid username or password",
"related": {
"hosts": [
"grafana-01"
],
"ip": [
"10.40.2.21"
]
},
"service": {
"name": "grafana",
"type": "grafana",
"version": "9.5.1"
},
"source": {
"ip": "10.40.2.21"
}
}Parameters
| Parameter | Default | Description |
|---|---|---|
| grafana_host | grafana-01 | host.name of the Grafana server |
| root_url | https://grafana.example.test | Scheme and host used in referer values |
| anomaly_mode | true | Add recurring anomaly chain episodes to the background; false emits only background |
| anomaly_interval_hours | 24 | Hours between episode due times, 6 to 8,760 |
Related Generators
1C:Enterprise Event Log
1C:Enterprise 8.3.27 event-log collector projection for a client/server, single-data-area infobase: ECS-style JSON with snake_case source fields under one_c.event_log, not a native XML or .lgf export and without event.original. Six staff accounts, four reusable temporary account names and five configured objects with explicit permissions. Recurring episodes, weekly by default, join an administrator's failed logins, a temporary FullAccess account, its payroll reads, its deletion and an event-log reduction.
1C:Enterprise Technological Log
1C:Enterprise 8.3.27 technological-log JSON records (SCALL, CALL, TLOCK, EXCP) of one rphost process serving fourteen client and service sessions of one infobase, in an ECS envelope. About 44,000 records a day: interactive users follow a working day in UTC, background jobs keep the same pace day and night. Managed locks on document keys are granted at once, queued, or time out after 20 seconds. Recurring episodes are lock convoys: one very long posting blocks a busy document key until six distinct sessions have timed out on it within 50 minutes.
Nextcloud Admin Audit
Nextcloud 35.0.0 admin_audit HTTP records from the dedicated audit.log file backend, with each native JSON line in event.original and parsed under nextcloud.audit, for testing detections on logins, file access and public links. 180 users work in sessions over 1,154 files, about 10,800 records a day. Recurring episodes show a guessed password followed by publishing a file for outside access through a public link.