{"id":1531,"date":"2026-09-10T23:43:45","date_gmt":"2026-09-11T02:43:45","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2026\/09\/openobserve-observabilidade-logs-metricas-traces\/"},"modified":"2026-09-10T23:43:45","modified_gmt":"2026-09-11T02:43:45","slug":"openobserve-observabilidade-logs-metricas-traces","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/en\/2026\/09\/openobserve-observabilidade-logs-metricas-traces\/","title":{"rendered":"OpenObserve: logs, metrics, and traces in one platform"},"content":{"rendered":"<p><img loading=\"lazy\" decoding=\"async\" src=\"\/wp-content\/uploads\/2026\/09\/openobserve-observabilidade-v1.webp\" alt=\"Mascote LinuxPro usando o OpenObserve para analisar logs, m\u00e9tricas e traces\" width=\"1486\" height=\"856\" \/><\/p>\n<p>When a service starts failing, the signs are usually scattered: metrics in Prometheus, logs in another backend, traces in a third tool, and alerts without context. The <strong>OpenObserve<\/strong> tries to gather this work in an open source platform for logs, metrics, traces, RUM, dashboards, alerts and incidents. Written in Rust, it queries logs and traces with SQL, metrics with SQL or PromQL, and uses Parquet with object-oriented storage to reduce retention costs.<\/p>\n<blockquote><p><strong>Video summary:<\/strong> the official two-minute demo shows installation and first steps of OpenObserve. <strong>URL:<\/strong> <a href=\"https:\/\/www.youtube.com\/watch?v=zJDvDBvVi3k\" target=\"_blank\" rel=\"noopener\">OpenObserve 2-Minute Demo: Quick Install and Setup<\/a>.<\/p><\/blockquote>\n<div class=\"video-container\" style=\"position:relative;padding-bottom:56.25%;height:0;overflow:hidden;margin:1.5em 0;\">\n  <iframe loading=\"lazy\" src=\"https:\/\/www.youtube.com\/embed\/zJDvDBvVi3k\" title=\"OpenObserve 2-Minute Demo: Quick Install and Setup\" width=\"560\" height=\"315\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen style=\"position:absolute;top:0;left:0;width:100%;height:100%;\"><\/iframe>\n<\/div>\n<h2>What is OpenObserve<\/h2>\n<p>OpenObserve, also called O2, is a unified observability platform. The idea is not to replace every agent that collects telemetry, but to provide a common destination and interface for the signals: logs, metrics, and distributed traces. The platform also includes dashboards, alerts, ingestion pipelines, incident management, real user monitoring (RUM), and observability features for AI applications.<\/p>\n<p>The project is <a href=\"https:\/\/github.com\/openobserve\/openobserve\" target=\"_blank\" rel=\"noopener\">open source under AGPL-3.0<\/a>. There is also an Enterprise edition and the OpenObserve Cloud service. This matters in the choice: the OSS edition is useful for those who want control over infrastructure and data residency; specific enterprise features like SSO, granular RBAC, federated search, and load management belong to the Enterprise offering.<\/p>\n<h2>Why gather logs, metrics and traces<\/h2>\n<p>The three signals answer different questions:<\/p>\n<ul>\n<li><strong>Metrics<\/strong> show trend and aggregated state: CPU usage, error rate, latency, and request volume.<\/li>\n<li><strong>Logs<\/strong> preserve the event and context: application messages, errors, structured fields, and auditing.<\/li>\n<li><strong>Traces<\/strong> follow a request through services, queues, and databases, making visible where time was spent.<\/li>\n<\/ul>\n<p>The value of a unified platform appears in investigation. An error spike in the graph can lead to traces of that service and, from them, to logs from the same period. This does not eliminate the need to instrument the application well nor fix excessive cardinality; it only reduces context switching between tools.<\/p>\n<p>If you already monitor Linux machines, start with our guide of <a href=\"\/en\/2026\/09\/monitorando-servidores-linux-com-prometheus\/\">Prometheus and Node Exporter<\/a>. OpenObserve can complement this flow by centralizing other signals, but there's no reason to urgently migrate a stable stack just because one platform gathers more functions.<\/p>\n<h2>How the architecture reduces the number of pieces<\/h2>\n<p>In single-node mode, OpenObserve uses SQLite for metadata and can write locally or to object storage. It's the path for lab, development, and workloads that don't require high availability. The documentation also covers single node with S3, GCS, MinIO, or Azure Blob: continues simple to operate, but Parquet files go to more durable storage.<\/p>\n<p>In high availability, the topology changes: the project separates the roles of Router, Ingester, Compactor, Querier, and Scheduler. Kubernetes orchestrates the nodes; PostgreSQL stores metadata; NATS coordinates the cluster; and object storage maintains the Parquet files. This scales better, but it's not \u201ca binary without operation\u201d: it's a production architecture that requires capacity, backups, planned updates, networking, and observability of the backend itself.<\/p>\n<p>Parquet is a columnar format suitable for analytical queries. Combined with object storage use, it's the basis of the project's claim of up to 140\u00d7 less storage cost compared to Elasticsearch. Treat that number as a vendor reference, not a guarantee: volume, retention, compression, query patterns, index, and your bucket cost determine the actual bill.<\/p>\n<h2>Main features<\/h2>\n<table>\n<thead>\n<tr>\n<th>Area<\/th>\n<th>What OpenObserve offers<\/th>\n<th>Attention point<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Logs<\/td>\n<td>Text search, filters, SQL and visual query building.<\/td>\n<td>Define schema, retention and useful fields before sending everything indiscriminately.<\/td>\n<\/tr>\n<tr>\n<td>Metrics<\/td>\n<td>Query via SQL or PromQL, graphs and alerts.<\/td>\n<td>Query compatibility does not replace reviewing existing rules.<\/td>\n<\/tr>\n<tr>\n<td>Traces<\/td>\n<td>Exploring OpenTelemetry traces, waterfall, flame graph and service graph.<\/td>\n<td>The result depends on correct context propagation between services.<\/td>\n<\/tr>\n<tr>\n<td>Dashboards and alerts<\/td>\n<td>Panels, variables, visualizations, alerts and incidents.<\/td>\n<td>Alerts must have an owner, severity, route and response procedure.<\/td>\n<\/tr>\n<tr>\n<td>Pipelines<\/td>\n<td>Ingestion transformations, normalization and conversion of logs into metrics.<\/td>\n<td>Test transformations on a sample; an incorrect parser can destroy context.<\/td>\n<\/tr>\n<tr>\n<td>RUM and AI<\/td>\n<td>Core Web Vitals, errors, session replay, and signals for GenAI\/LLM applications.<\/td>\n<td>RUM and AI data require extra attention to PII, consent, and retention.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Quick Docker installation for lab<\/h2>\n<p>The procedure below uses the OSS image indicated by the project repository. It is for local testing or a proof of concept; do not expose port 5080 directly to the internet and do not use an example password on an accessible server.<\/p>\n<pre data-no-translation=\"\"><code class=\"language-bash\" data-no-translation=\"\">mkdir -p ~\/openobserve\/data\ncd ~\/openobserve\n\nexport ZO_ROOT_USER_EMAIL=\"admin@example.com\"\nexport ZO_ROOT_USER_PASSWORD=\"$(openssl rand -base64 32)\"\n\nprintf '%s\\n' \"$ZO_ROOT_USER_PASSWORD\" &gt; senha-inicial.txt\nchmod 600 senha-inicial.txt\n\ndocker run -d \\\n  --name openobserve \\\n  --restart unless-stopped \\\n  -v \"$PWD\/data:\/data\" \\\n  -p 127.0.0.1:5080:5080 \\\n  -e ZO_DATA_DIR=\"\/data\" \\\n  -e ZO_ROOT_USER_EMAIL \\\n  -e ZO_ROOT_USER_PASSWORD \\\n  public.ecr.aws\/zinclabs\/openobserve:latest<\/code><\/pre>\n<p>Open <code data-no-translation=\"\">http:\/\/127.0.0.1:5080<\/code> on the host itself or make an SSH tunnel. For a team, publish the interface behind a reverse proxy with TLS and appropriate authentication. In production, prefer a tested image tag instead of <code data-no-translation=\"\">latest<\/code> and follow the <a href=\"https:\/\/openobserve.ai\/docs\/releases\/\" target=\"_blank\" rel=\"noopener\">releases<\/a>.<\/p>\n<p>The root user is defined on first startup. Store the credential outside shell history and shared files, for example in a secrets manager. Before cleaning up the test, stop the container and intentionally remove the data directory: that is where the local telemetry was persisted.<\/p>\n<h2>From lab to production<\/h2>\n<p>A production installation starts with data decisions, not the Docker command:<\/p>\n<ol>\n<li><strong>Choose retention by signal type.<\/strong> Debug logs and session replay do not need the same window as capacity metrics.<\/li>\n<li><strong>Plan storage.<\/strong> For durability and scale, use a bucket compatible with the design recommended by the project; for HA, local storage is not supported.<\/li>\n<li><strong>Use OpenTelemetry when possible.<\/strong> Standardizing instrumentation and context reduces dependency on specific agents.<\/li>\n<li><strong>Separate organizations, streams, and credentials.<\/strong> Do not mix production, staging, and sensitive data without a clear policy.<\/li>\n<li><strong>Treat access as part of the architecture.<\/strong> The official comparison states that OSS does not provide granular RBAC; validate SSO, audit, and permission requirements before opening the platform to multiple teams.<\/li>\n<li><strong>Test restoration.<\/strong> Untested backup is just hope. Verify data, metadata, and the configurations needed to recover the environment.<\/li>\n<\/ol>\n<p>The official guide makes clear that HA mode requires Kubernetes, PostgreSQL, NATS, and object storage. If the team lacks maturity to operate these components, the Cloud edition or a well-bounded single node may be a safer decision than an undersized HA deployment.<\/p>\n<h2>Queries, dashboards and alerts<\/h2>\n<p>Logs and traces can be explored with SQL; metrics can use SQL or PromQL. The practical advantage is preserving languages that many teams already know instead of forcing a proprietary DSL. Still, dashboard and alert migration requires review: metric names, labels, time windows, aggregations, and function semantics need to be validated against the previous result.<\/p>\n<p>Start with a small, actionable dashboard: availability, error rate, percentile latency, and saturation signals. For each alert, document which dashboard to open, which fields to filter, who responds, and what action can be taken. Alerting on everything is the shortest path to ignoring alerts.<\/p>\n<blockquote><p><strong>Official video:<\/strong> this tutorial from the OpenObserve channel walks through building dashboards. <strong>URL:<\/strong> <a href=\"https:\/\/www.youtube.com\/watch?v=Noe3v5EU08I\" target=\"_blank\" rel=\"noopener\">Building Dashboards with OpenObserve: A Comprehensive Tutorial<\/a>.<\/p><\/blockquote>\n<div class=\"video-container\" style=\"position:relative;padding-bottom:56.25%;height:0;overflow:hidden;margin:1.5em 0;\">\n  <iframe loading=\"lazy\" src=\"https:\/\/www.youtube.com\/embed\/Noe3v5EU08I\" title=\"Building Dashboards with OpenObserve\" width=\"560\" height=\"315\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen style=\"position:absolute;top:0;left:0;width:100%;height:100%;\"><\/iframe>\n<\/div>\n<h2>Open source, Enterprise and Cloud<\/h2>\n<p>The OSS edition is AGPL-3.0 and free, with logs, metrics, traces, RUM, dashboards, and alerts. According to the official download table, it has basic user support but without granular RBAC: users have full access. The Enterprise edition adds, among other items, SSO, custom roles, groups, audit, federated search, workload control, and advanced pipeline and security features.<\/p>\n<p>At the time of query, the commercial page states that the self-hosted Enterprise edition is free up to 50 GB\/day of ingestion; beyond that and for paid support, commercial contact is required. For OpenObserve Cloud, the page shows charges per GB ingested and queried, plus standard retention. Commercial pricing, limits, and features change: confirm the <a href=\"https:\/\/openobserve.ai\/pricing\/\" target=\"_blank\" rel=\"noopener\">pricing page<\/a> and the <a href=\"https:\/\/openobserve.ai\/downloads\/\" target=\"_blank\" rel=\"noopener\">OSS versus Enterprise comparison<\/a> before finalizing a quote.<\/p>\n<h2>When it makes sense \u2014 and when it doesn't<\/h2>\n<p>OpenObserve is a good option for those wanting to consolidate telemetry around OpenTelemetry, SQL, PromQL, and object storage; for teams already paying dearly for log retention; or for those preferring to operate an integrated platform instead of piecing together multiple components.<\/p>\n<p>It may not be the right choice if the team only needs metrics from a few hosts, if there's already a platform with mature SLOs and integrations that serves well, or if there's no capacity to operate data, backups, and upgrades. \u201cA single binary\u201d simplifies initial testing; it doesn't eliminate operational responsibility, access governance, nor storage cost.<\/p>\n<h2>Another video: comparison with Splunk<\/h2>\n<p>For a product positioning view, this WPoers TV video features a conversation with OpenObserve comparing to Splunk. It's a complementary source, it doesn't replace load testing and cost calculation in your environment.<\/p>\n<div class=\"video-container\" style=\"position:relative;padding-bottom:56.25%;height:0;overflow:hidden;margin:1.5em 0;\">\n  <iframe loading=\"lazy\" src=\"https:\/\/www.youtube.com\/embed\/Rq40GYZ-xDY\" title=\"OpenObserve vs Splunk: The Future of Observability\" width=\"560\" height=\"315\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen style=\"position:absolute;top:0;left:0;width:100%;height:100%;\"><\/iframe>\n<\/div>\n<h2>Official sources and next steps<\/h2>\n<ul>\n<li><a href=\"https:\/\/github.com\/openobserve\/openobserve\" target=\"_blank\" rel=\"noopener\">OpenObserve repository on GitHub<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/docs\/\" target=\"_blank\" rel=\"noopener\">Official documentation<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/docs\/features\/\" target=\"_blank\" rel=\"noopener\">Platform Features<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/docs\/architecture\/\" target=\"_blank\" rel=\"noopener\">Architecture and Deployment Modes<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/docs\/getting-started\/\" target=\"_blank\" rel=\"noopener\">Quickstart: Cloud e self-hosted<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/blog\/\" target=\"_blank\" rel=\"noopener\">OpenObserve Blog<\/a><\/li>\n<li><a href=\"https:\/\/openobserve.ai\/pricing\/\" target=\"_blank\" rel=\"noopener\">Pricing<\/a> and <a href=\"https:\/\/openobserve.ai\/downloads\/\" target=\"_blank\" rel=\"noopener\">Downloads<\/a><\/li>\n<\/ul>\n<p>The best next step is small: run the lab, send a log source and a metric you already know, create a single alert and calculate real ingestion and retention. Only then decide if it's worth scaling the platform.<\/p>","protected":false},"excerpt":{"rendered":"<p>When a service starts failing, the signals are usually scattered: metrics in Prometheus, logs in another backend, traces in a third tool, and alerts without context. OpenObserve aims to bring this work together in an open-source platform for logs, metrics, traces, RUM, dashboards, alerts, and incidents. Written in Rust, it queries logs and traces with \u2026 <a title=\"OpenObserve: logs, metrics, and traces in one platform\" class=\"read-more\" href=\"https:\/\/www.linuxpro.com.br\/en\/2026\/09\/openobserve-observabilidade-logs-metricas-traces\/\" aria-label=\"Read more about OpenObserve: logs, m\u00e9tricas e traces em uma plataforma\">Read more<\/a><\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[46,21,2],"tags":[47,456,457,455,454,459,125,458],"class_list":["post-1531","post","type-post","status-publish","format-standard","hentry","category-devops","category-infra","category-linux","tag-devops","tag-logs","tag-metricas","tag-observabilidade","tag-openobserve","tag-opentelemetry","tag-prometheus","tag-traces"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=1531"}],"version-history":[{"count":0,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/1531\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=1531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=1531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=1531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}