VictoriaMetrics & VictoriaLogs: Observability for NIS-2 and DORA

TL;DR

• Modern compliance requirements like NIS-2, DORA, and GDPR demand robust, verifiable observability: metrics, logs, and traces must be systematically collected, analyzed, and stored long-term.
• VictoriaMetrics offers a high-performance, Prometheus-compatible metrics platform with efficient long-term retention—ideal for regulatory-compliant representation of SLOs, capacities, and incidents.
• VictoriaLogs complements this with structured, high-performance, tamper-proof log management, enabling audit trails, forensic analysis, and audit-proof evidence.
• Combined with Grafana and a tracing backend, a complete observability stack is created that supports proactive monitoring, rapid incident handling, and reliable reporting for NIS-2, DORA, and GDPR.
• ayedo designs, implements, and operates such observability stacks based on VictoriaMetrics, VictoriaLogs, and Grafana—technically deep, regulation-aware, and with a clear focus on your compliance requirements.

Observability as a Foundation for NIS-2, DORA, and GDPR

Observability is more than “Monitoring 2.0.” It is the ability to understand the state of complex distributed systems from their behavior—even when specific error patterns were previously unknown. For regulated companies, this ability has become a core component of governance.

The three classic pillars:

1. Metrics
   Time series like latencies, error rates, resource utilization. Ideal for trends, SLOs, and proactive alerting.

2. Logs
   Event-oriented data—from API requests to authentication attempts to database errors. Basis for forensic analysis and audit trails.

3. Traces
   Track individual transactions through microservices, queues, and databases. Indispensable for complex ICT incidents and performance bottlenecks.

Observability becomes regulatory relevant when structured processes emerge from this data:

• Early detection of disruptions and security incidents
• Traceability of decisions and interventions
• Documentation of causes, impacts, and countermeasures

Instead of viewing compliance as a burden, a change in perspective is worthwhile: A good observability stack reduces downtime, accelerates incident analysis, and creates exactly the transparency that laws demand today—and that is technically sensible anyway.

Regulatory Framework: What Observability Must Achieve

NIS-2: Incident Handling with Verifiability

The NIS-2 Directive came into force on January 16, 2023. By October 17, 2024, EU member states must transpose it into national law; from October 18, 2024, the national implementations apply.

Key points related to observability:

• Processes for handling security incidents
  This includes the ability to detect incidents in a timely manner—which is hardly possible without metrics and logs.
• Reporting significant incidents
  Here, you need reliable data on duration, impact, and affected systems.
• Proof of technical and organizational measures
  Logs and metrics are not just operational aids but evidence of your risk management.

DORA: ICT Incident Management in the Financial Sector

The DORA Regulation (Digital Operational Resilience Act) also came into force on January 16, 2023, and applies directly to financial companies and certain service providers from January 17, 2025.

DORA requires, among other things:

• Structured ICT incident processes including categorization, escalation, reporting
• Testing and continuous improvement of resilience
• Comprehensive documentation of ICT incidents

Without comprehensive observability, this ICT incident management is practically unfeasible: You must be able to detect, classify, prioritize incidents, and later prove which measures were effective.

GDPR: Audit Trails and Access Evidence

The General Data Protection Regulation (GDPR / GDPR) came into force on May 25, 2018. It requires, among other things:

• Accountability: You must be able to prove how personal data was processed.
• Access logging: Who accessed which data and when?
• Rapid information retrieval in case of data breaches: Which systems, data, and people were affected?

This is where structured, immutable logs and long-term stable metrics come into play. A well-constructed observability stack is thus a central pillar of your GDPR compliance.

VictoriaMetrics: Efficient Metrics for Long-term Transparency

VictoriaMetrics is a high-performance, Prometheus-compatible time series database optimized for large data volumes and long retention periods. This is particularly relevant for regulated environments because incidents and trends often need to be analyzed over months or years.

Prometheus-compatible but Scalable

Many organizations start with Prometheus—and rightly so. But as soon as:

• multiple clusters are consolidated,
• retention periods of several years are required,
• or query load from reporting and audits increases,

A dedicated metric engine like VictoriaMetrics comes into play. It understands the Prometheus ecosystem (scraping, remote write, PromQL) and can therefore be integrated into existing instrumentation without adjusting application code.

Performance and Storage Efficiency

Technically, VictoriaMetrics relies on:

• aggressive compression of time series,
• efficient indices,
• horizontal scaling.

For you, this translates into:

• Lower infrastructure costs with growing metric volume
• Stable query performance even with extensive dashboards and long-term analyses
• Plannable retention strategies, e.g., several years for compliance-relevant services

In the context of NIS-2 and DORA, this means: You can not only use SLOs and availability metrics operationally but also retrospectively demonstrate how your systems have developed—including peak loads, resource bottlenecks, and times when measures were effective.

VictoriaLogs: Structured, Tamper-proof Logs

While metrics represent the “vital signs” of your platform, logs provide the detail for audits and forensics. VictoriaLogs is a log database in the VictoriaMetrics ecosystem designed specifically for this requirement.

Structured Log Management

Unlike traditional file logs or simple log aggregators, VictoriaLogs relies on:

• Schema-friendly, structured storage of fields (e.g., user ID, request ID, service, tenant)
• Indexing of relevant attributes, so that queries remain performant even with billions of events
• Flexible query language, combining filters, aggregations, and time ranges

The effect: You can efficiently answer specific questions, such as:

• Which user group accessed a sensitive system during a specific period?
• Which services were involved in a specific ICT incident?
• Which configuration change triggered a specific disruption?

Tamper-proof Logs for Audit and Forensics

For compliance, the content of logs is not the only important factor, but also their integrity. Tamper-proof logs are relevant in several dimensions:

• Accountability under GDPR: You must credibly demonstrate that access logs are unchanged.
• Forensics after security incidents: Investigations rely on the integrity of log data.
• Internal and external audits: Auditors increasingly focus on WORM and integrity properties.

VictoriaLogs supports this through an append-only design, clear separation of write and read paths, and integrity mechanisms at the segment level. In practice, many organizations combine this with:

• restrictive access rights (write-only pipelines, separate audit projects),
• cryptographic signatures at the export level,
• and audit-proof storage backends.

Compared to alternatives like Loki, VictoriaLogs focuses more on high throughput, structured queries, and scalable long-term retention—exactly what you need for DORA-compliant ICT incident reports and comprehensive audit trails.

Grafana Dashboards and Traces: From Data Mountain to Decision

Data alone does not create resilience. What matters is how teams work with this data. This is where Grafana comes into play as a visualization and analysis frontend.

A Practical Example: System Monitoring in a Dashboard

A typical dashboard in a VictoriaMetrics/VictoriaLogs stack could include:

• Service Health and SLO Status
  Latencies, error rates, throughput per critical service—directly from VictoriaMetrics.
• Resource Utilization
  CPU, memory, I/O, and network usage at cluster and node level.
• Incident Timeline
  Annotations for incidents, deployments, and changes to make correlations visible.
• Drill-down in Logs
  Panels that automatically open matching log queries in VictoriaLogs when clicking on a metric (e.g., all error logs with the same trace ID in the relevant period).

This creates a workflow that directly supports regulatory requirements:

1. An alert signals a potential ICT incident (metric-based).
2. The team opens the dashboard, identifies affected services and time windows.
3. Relevant logs and—if available—traces are loaded via links or integrated panels.
4. The results are documented for the incident report and later used for DORA or NIS-2 notifications.

Traces as the Third Pillar

Even though this article focuses on VictoriaMetrics (metrics) and VictoriaLogs (logs), the third pillar—traces—should not be underestimated. Whether you use OpenTelemetry, Jaeger, or another tracing stack:

• Traces connect metrics and logs at the transaction level.
• They show which microservices, databases, or external services were involved in an incident.
• For complex ICT incidents, as addressed by DORA, traces are often the key to root cause analysis.

A well-thought-out observability stack therefore integrates all three perspectives into a unified operating concept.

Frequently Asked Questions

1. Is a classic monitoring setup sufficient for NIS-2 and DORA?

A classic monitoring setup that only includes availability checks and a few host metrics will generally not be sufficient for NIS-2 or DORA-compliant environments.

Regulations require not only the detection of disruptions but also:

• Classification and prioritization of ICT incidents,
• Traceability of causes and impacts,
• Reliable reports on measures and effectiveness,
• and sometimes multi-year histories.

For this, you need:

• Metrics with sufficient detail and retention (e.g., VictoriaMetrics),
• Structured logs with integrity properties (e.g., VictoriaLogs),
• Clear processes for capturing, evaluating, and documenting incident information.

Monitoring is one component—observability is the complete picture.

2. How does VictoriaLogs differ from established log platforms?

Many traditional log platforms have historically grown from file-based logging and scale only with significant effort in truly large data volumes. They often focus on full-text search, which is only partially ideal for compliance requirements.

VictoriaLogs, on the other hand, focuses on:

• consistently structured data (fields instead of pure text),
• performant indices on frequently used attributes