Hub
Application

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 true

Event Types

Event IDDescriptionFrequencyCategory
POST /api/ds/query 200Request Completed line for a data source query43.7% of linesweb
GET /api/dashboards/uid/<uid> 200Request Completed line for a dashboard read13.2% of linesweb
GET /api/annotations 200Request Completed line for an annotations read11.6% of linesweb
GET /api/search 200Request Completed line for a dashboard search10.2% of linesweb
POST /api/frontend-metrics 200Request Completed line for frontend metrics7.5% of linesweb
GET /api/user 200Request Completed line for the signed-in user4.9% of linesweb
GET / 200Request Completed line for the home page4.2% of linesweb
Successful Loginhttp.server message after a form login1.23% of linesauthentication
POST /login 200Request Completed line for a successful form login1.23% of linesweb, authentication
GET /login 200Request Completed line for the login page0.85% of linesweb
Successful Logouthttp.server message on logout0.36% of linesauthentication
GET /logout 302Request Completed line for a logout redirect0.36% of linesweb
GET /api/serviceaccounts/search 200Request Completed line for a service account search0.19% of linesweb
Invalid username or passwordcontext logger error line for a failed form login, with the lockout text after repeated failures0.13% of linesauthentication
POST /login 401Request Completed line for a failed form login0.13% of linesweb, authentication
GET /api/serviceaccounts/<id>/tokens 200Request Completed line for a service account token list0.13% of linesweb
POST /api/serviceaccounts/<id>/tokens 200Request Completed line for a service account token creation0.06% of linesweb
DELETE /api/serviceaccounts/<id>/tokens/<tokenId> 200Request Completed line for a service account token deletion0.06% of linesweb

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

ParameterDefaultDescription
grafana_hostgrafana-01host.name of the Grafana server
root_urlhttps://grafana.example.testScheme and host used in referer values
anomaly_modetrueAdd recurring anomaly chain episodes to the background; false emits only background
anomaly_interval_hours24Hours between episode due times, 6 to 8,760

Related Generators

Application

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.

Application

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.

Application

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.