Log Management & Analysis

Bleemeo can collect logs from virtually any source. This includes: log files (any file path or pattern), syslog (RFC3164 and RFC5424), container logs (Docker, containerd, Kubernetes pods), application stdout/stderr, and logs sent via OTLP over gRPC or HTTP. Glouton automatically discovers and collects logs from running containers and services when auto-discovery is enabled.

Glouton uses an OpenTelemetry Collector-based log processing pipeline. It supports JSON parsing, regex pattern matching, Grok patterns, and custom parsers using Stanza operators. You can define known log formats (like nginx_access, apache_combined) and apply them to files, containers, or services. The system extracts timestamps, severity levels, and structured fields automatically.

Yes, Bleemeo offers powerful filtering capabilities. You can filter logs using OpenTelemetry Transformation Language expressions, regex patterns on log bodies or attributes, severity levels, and resource attributes. Filters can include or exclude logs based on multiple conditions. You can also disable log collection for specific containers using the glouton.log_enable=false label.

Bleemeo provides a powerful search interface in the cloud panel. You can perform full-text searches across all your logs, use regex queries for complex pattern matching, filter by time range, severity level, source, or any structured field. Search results are returned in milliseconds, even across large volumes of log data. You can also save frequently used queries for quick access.

Yes, Bleemeo supports log-based alerting. You can create alerts triggered by specific log patterns, error messages, or regex matches. You can also alert on threshold conditions like error rate exceeding a certain number per minute. Alerts are processed in real-time, so you're notified within seconds of a critical log event occurring.

Log retention depends on your plan and can be configured to meet your requirements. Bleemeo supports flexible retention policies with automatic archiving and compression. Hot storage keeps recent logs immediately accessible, while older logs can be moved to cold storage. This allows you to balance search performance with storage costs while maintaining compliance requirements.

Yes, this is a core strength of Bleemeo's unified observability approach. You can view logs and metrics side-by-side in dashboards, jump from a metric anomaly directly to related logs, and see the full context of an issue in one place. This correlation enables faster troubleshooting by providing infrastructure metrics alongside application logs.

When Glouton is deployed in Kubernetes (via Helm chart), it automatically discovers and collects logs from all pods. You can control log collection per pod using the glouton.log_enable annotation. Custom log formats and filters can be applied using pod annotations (glouton.log_format, glouton.log_filter) or via Glouton configuration. Container stdout/stderr logs are captured without any additional configuration.

Glouton's log processing is designed to be lightweight and efficient. It uses a streaming architecture that processes logs incrementally without loading entire files into memory. Log transmission is batched and compressed to minimize network overhead. For very high-volume scenarios, you can use filters to reduce the volume of logs sent to the cloud while keeping local processing minimal.

Yes, Bleemeo can create metrics from log patterns. By defining regex patterns in your configuration, Glouton counts matching log lines and exposes them as metrics (e.g., errors per second, specific event rates). This allows you to alert on log-derived metrics, track trends over time, and visualize log patterns in dashboards alongside your infrastructure metrics.