A practical walkthrough of Jujing OBSERVE's log search: SQL-like structured queries, full-text fuzzy matching, aggregation, and alert linkage — with copy-paste query syntax and indexing tips to cut time-to-locate from minutes to seconds.
The core job of any log platform is to help you find the one line that matters. When production breaks, whether you can locate that critical log in seconds decides if your MTTR is five minutes or two hours. Jujing OBSERVE's log search is designed around three goals: fast, precise, and cheap. This article breaks down its core capabilities with query syntax you can use right away.
Keyword-only search forces you to guess regular expressions or pull everything down and grep. OBSERVE parses logs into structured fields at ingest time and indexes the fields you use most. On the query side you get a SQL-like syntax:
status_code >= 500 AND service = "order-svc" AND latency_ms > 2000Field types drive the available operators: numeric fields accept >, <, and BETWEEN; text fields accept =, LIKE, and IN; time fields accept relative windows such as last 5m. Combine conditions with AND/OR/NOT and group with parentheses, so a complex condition no longer needs a script.
Not every log line has clean fields. Stack traces and request bodies are long free text, and for those you still need full-text search. OBSERVE ships an inverted index and supports tokenized fuzzy matching with LIKE '%timeout%' as well as CONTAINS 'timeout' for exact substrings. For Chinese logs the default tokenizer splits by word, so "支付超时" matches "支付接口超时" instead of missing it to character-by-character matching. Declare frequently-queried fields as indexed in the ingest config, and search latency drops from seconds to milliseconds.
Once you locate a single error line, the next question is usually how many times it happened and on which instances. Aggregation syntax is embedded right after the query:
status_code >= 500 | stats count() by service, instanceThis groups counts by service and instance; add top 10 and sort by count desc to control the output. Aggregate results switch to bar or line charts with one click, so you can tell at a glance whether an error is a sudden spike or steady degradation.
Save high-frequency conditions as saved queries and share a common set of investigation patterns across the team, so new joiners don't start from zero. More importantly, link a saved query to an alert rule — for example, "more than 50 5xx in the last 5 minutes". When the alert fires it carries the query link and a summary of matched logs; whoever receives the page opens it and lands straight on the scene, without replaying the investigation path.
Search speed is decided at ingest time, not query time. Parse and index the fields you actually query — status_code, service, instance, latency_ms — and leave free-form text to the inverted index. Don't index every field blindly: each extra index costs disk and write throughput, and on a busy cluster that cost compounds across terabytes of daily logs.
A common mistake is treating trace_id and request_id as full-text. They are exact-match fields, so search with = or IN, never LIKE, which forces a scan even for a unique value. For high-cardinality fields such as user_id, consider dropping the index and using = against the raw column only when you already hold the exact value.
Always keep a raw copy of every log for forensics and re-indexing, but point routine searches at the parsed, indexed columns. Two habits pay off quickly: turn any query used more than once a day into a saved query pinned to a dashboard, and promote any condition that keeps surfacing the same problem into an alert rule. The goal is to stop discovering outages by accident and start finding them by design.
Pick the right signal for the question. Logs answer "what happened at this exact moment" and are unbeatable for a specific error's stack trace. Metrics answer "is the system healthy" and scale to thousands of services cheaply. Traces answer "how did one request flow across services". Don't force one signal to do another's job: using logs as your only metric source is slow and expensive, and stuffing traces with everything blows up storage. OBSERVE keeps the three linked — a slow span links to its logs, and an alert links to the traces and logs that fired it — so you can start from any signal and walk to the others.
A practical tip: before going live, save the basic queries for every service and environment. During an incident you only change the conditions, which is far faster than composing syntax from scratch.