How VerOps works
VerOps has four layers. Agents and SDKs collect data where your systems run. An ingest gateway authenticates and filters it. Telemetry is stored per organisation in ClickHouse, and configuration in a relational database. The web app, the API and Vera read from that one store.
- Collect
- OpenTelemetry plus VerOps agents
- Ingest
- API-key authenticated gateway
- Store
- ClickHouse, isolated per organisation
- Use
- Web app, API and Vera
The data path
- 01
Collect
OpenTelemetry SDKs and Collectors, the VerOps agents and the browser SDK send data out to VerOps. Agents connect outbound, so you do not open inbound ports.
- 02
Ingest
The gateway accepts OTLP over HTTP, identifies your organisation from the API key, and applies your ingestion filters before anything is stored.
- 03
Store and query
Traces, metrics, logs, RUM and inventory history go to ClickHouse, where every query is restricted to your organisation. Long time ranges read from rollups.
- 04
Act
Dashboards, explorers, alerting, war rooms, workbooks, reports, the public API and Vera all work from the same data.
Agents and SDKs
Install only what you need. Each one is documented with its requirements and configuration.
| Collector | Runs on | What it does |
|---|---|---|
| OpenTelemetry SDKs and Collector | Any language or host | Traces, metrics and logs over OTLP |
| VerOps Java agent | JVM, Java 11 and later | Automatic tracing for common Java libraries |
| Machine agent | Linux and Windows servers | Host health, processes, log reads on request, optional inventory |
| Kubernetes agent | Kubernetes, installed with Helm | Cluster objects, workloads, events and kubelet stats |
| Network agent | Linux and Windows | Network tests, agent mesh, SNMP, LAN discovery |
| Synthetic agent | VerOps cloud, or inside your network | Browser journeys and API checks |
| Scout | Windows and Linux endpoints | Hardware and software inventory, software activity, presence |
| Browser SDK | Your web pages | Core Web Vitals, errors, sessions, custom events |
Modules
One account and one set of permissions across all of them.
APM and distributed tracing
Service map, waterfall and flame graph for Java and OpenTelemetry services.
Learn moreLogs and metrics
OTLP logs and metrics, explorers, SQL and ingestion filters.
Learn moreInfrastructure and Kubernetes
Linux and Windows hosts, Kubernetes clusters, AWS and Azure metrics.
Learn moreReal user monitoring
Core Web Vitals, errors and funnels from real visitors.
Learn moreSynthetic monitoring
Browser journeys and API checks from cloud or private agents.
Learn moreNetwork monitoring
Nine test types, SNMP polling and traps, topology.
Learn moreAlerting and on-call
Rules, schedules, escalation, SLOs and war rooms.
Learn moreDashboards and Data Explorer
Widgets, variables, SQL and read-only share links.
Learn moreWorkbooks
Runbooks and release checks with branches and approvals.
Learn moreIT asset management
Inventory, patch posture, presence, financials and reports.
Learn moreSoftware usage and licences
Active use per product and licence position.
Learn moreVera
An assistant over your data that proposes changes for approval.
Learn moreSentinel
Quality and safety monitoring for your own AI agents.
Learn more
Core concepts
Organisation
Your isolated workspace. All data, users and settings belong to one organisation.
DocumentationRoles and permissions
Permissions per module, view or manage, bundled into roles.
DocumentationAPI keys
Keys identify the organisation that data belongs to. They are stored as hashes and shown once.
DocumentationEntities
Services, servers, containers and pods are derived from standard OpenTelemetry resource attributes.
Documentation
Read more in the docs
Try it on your own systems
Create a workspace, or tell us about your environment and we will walk you through it.