Query Logs Directly Where They Live

Traditional platforms charge per-GB for ingestion plus indexing, forcing organizations to sample logs or face exponential costs. Logs Monitoring (querying logs in place) is not billed, so the same infrastructure costs dramatically less regardless of log volume. Logs Management (collecting, storing and indexing logs) is in Free Preview. You also eliminate cluster infrastructure costs (no Elasticsearch nodes, Kafka, Logstash) and operational overhead, achieving 90% total cost reduction.

Netdata queries logs directly where they’re generated using memory-mapped I/O and libsystemd APIs optimized for concurrent reading. Traditional platforms ship logs to centralized clusters, adding network latency plus cluster processing time. Netdata leverages OS page cache optimization and parallel file reading to deliver sub-second responses on million+ entry datasets. During incidents, engineers iterate rapidly instead of waiting for results.

Traditional platforms sample limited log entries before timeout to maintain query speed, creating statistical uncertainty. Netdata’s intelligent sampling algorithm evaluates significantly more entries, achieving dramatically tighter confidence intervals. This means you see actual prevalence of issues during troubleshooting, not rough estimates. Every field is indexed automatically, so filtering accuracy is substantially higher.

Yes. Netdata supports Windows Event Logs (WEL), Event Tracing for Windows (ETW), and TraceLogging natively via windows-events.plugin. All Windows event channels are auto-discovered with the same unified interface as Linux journals. System fields are indexed for fast filtering; user fields support full-text search. Complete enterprise Windows coverage including Active Directory, IIS, Hyper-V, and SQL Server.

Yes. Netdata Logs Management collects logs from any source through the OpenTelemetry Collector and stores them centrally with every field indexed, and journals centralize with standard systemd-journal-upload/remote tools: Netdata automatically detects remote journals and provides unified views with namespace isolation for multi-tenancy. Alternatively, Netdata Cloud federates queries across distributed Agents/Parents without requiring log centralization. All approaches work - choose based on your requirements for local troubleshooting vs centralized compliance.

Netdata provides complete data sovereignty - logs stay on your infrastructure and are not stored in Netdata Cloud - and role-based access control (log data needs the permission to view sensitive data) and encrypted transport support GDPR, HIPAA, and PCI DSS data residency requirements. For systemd-journal, Forward Secure Sealing (FSS) provides cryptographic tamper detection with sealing keys regenerated via non-reversible process and verification keys stored off-system. This provides tamper-evident journal storage that supports audit requirements for HIPAA, PCI DSS, and SOX.

Yes. Netdata’s otel-plugin receives OTLP logs over gRPC or HTTP and stores them in Netdata’s log store, a write-ahead log sealed into indexed files with every field indexed. Records are queryable immediately, in the same logs explorer as your existing logs. Your OpenTelemetry instrumentation remains portable while gaining Netdata’s superior query performance and cost efficiency. The same OTLP endpoint also accepts traces - see distributed tracing.

log2journal converts text logs, JSON, or logfmt into systemd-journal format. Define patterns using PCRE2 regex to extract fields, map to journal fields, enrich with severity and correlation IDs, and output as structured journal entries. Ships with nginx and Apache patterns; supports custom patterns for any log format. Legacy applications with text logs become fully structured and searchable without application changes.

Yes. Netdata reads journal files non-destructively, so existing log platforms continue working. Many customers use Netdata for real-time troubleshooting (sub-second queries, native metrics correlation) while keeping Elasticsearch where they need its query language for analytics, or Splunk for security operations (the OpenTelemetry Collector stage can forward copies of logs to it). For retention and historical analysis, Netdata Logs Management stores logs from any source with every field indexed and offloads older files to S3-compatible or filesystem storage.

Minimal. The systemd-journal.plugin uses memory-mapped I/O and libsystemd APIs optimized for concurrent reading. Query overhead is typically very low CPU, bounded by disk I/O. Real-time streaming (PLAY mode) uses minimal CPU continuously. Storage overhead: journal files match or exceed text log compression efficiency with ZSTD/LZ4 compression.

Metrics and logs come from the same Netdata Agent, sharing labels like _HOSTNAME, _BOOT_ID, _SYSTEMD_UNIT, and CONTAINER_NAME. Click any metric anomaly to query logs for the same timeframe automatically - same source, same timeline, zero timestamp matching. The global datetime picker affects both metrics and logs simultaneously. Anomaly ribbons on metric charts correlate with log ERROR spikes, providing unified troubleshooting without tool switching.

Retention is what you configure. Configure journal retention per node with systemd-journal settings (size, time, or count limits); Logs Management retains logs by size, age and file count and offloads older files to S3-compatible or filesystem storage, fetching them back on demand. Journal format with ZSTD/LZ4 compression enables years of data in gigabytes instead of terabytes, with no hot/cold tiers for journals - all journal data equally fast via OS page cache optimization. For centralized deployments, use Netdata Logs Management (any source, through the OpenTelemetry Collector) or standard systemd-journal-remote, each with configurable retention policies.

No. Netdata provides point-and-click filtering and full-text search without query languages. Select fields from dropdowns, enter search terms, apply filters - the interface generates queries automatically. This eliminates the learning curve of LogQL (Loki), SPL (Splunk), or Elasticsearch DSL while providing powerful analysis capabilities. Engineers troubleshoot problems instead of learning query syntax.

Every field of every record is indexed automatically, and the indexing strategy adapts to each field’s number of distinct values. Dynamic fields like ephemeral container IDs, session tokens, and request IDs work natively without clustering failures or performance degradation. This is critical for Kubernetes environments where labels change constantly. Traditional platforms impose cardinality limits or require careful label selection - Netdata eliminates these constraints entirely.

Logs Monitoring (querying logs in place) is not billed, and neither are metrics volume, users, data retention or containers; Logs Management (collecting, storing and indexing logs) is in Free Preview. See Netdata pricing. Every field of every record is indexed.

Three-phase approach: (1) Deploy Netdata alongside existing platform (non-disruptive), (2) Run side-by-side for 2-4 weeks proving value, (3) Gradually shift teams to Netdata as confidence builds. Since Netdata auto-discovers logs, migration is primarily training. Many customers maintain both initially - Netdata for real-time troubleshooting, existing tools for long-term analytics - then consolidate after proving ROI.