Onelogic DRH
Diagnostics, turned into an asset.
A platform that changes how an organization handles software incidents: less time wasted, knowledge that compounds, faster response toward customers.
When a production service runs into trouble, the evidence — logs, payloads, application state — is scattered, ephemeral, hard to piece together. DRH packages it into a portable, compressed, encrypted and documented format (.cdpkg), brings it into a central hub, and makes it searchable. On top of that material, an AI-powered Knowledge Base accumulates the patterns it has already seen and proposes solutions the next time around.
More services, less visibility: the microservices paradox.
The more distributed a system becomes, the slower and more expensive its incident diagnosis gets. Three recurring symptoms, one common root cause: diagnostic knowledge stays scattered, unshared, unreusable.
Scattered data
Logs, payloads and application state live on different systems, in different formats, behind different access rules. Reassembling the picture of a single incident is manual work.
Broken context
TraceIds get lost in transit between services. Seeing a business transaction from start to finish becomes hard, even when the individual steps are observable.
Knowledge that evaporates
Diagnostic times keep growing. Every time you start from scratch: the same problem, already solved in the past, gets re-tackled as if it were new. Solutions stay in the head of whoever found them. Almost always a developer, pulled away from their work because support doesn't have the tools to diagnose on its own.
One platform, multiple contexts of use.
The same diagnostic asset generates value in different ways depending on who adopts it — and how.
Software development
The team building the product stops being the bottleneck of every non-trivial diagnosis. The context needed to understand an incident is available to whoever handles it first. Developers go back to developing. Knowledge about error patterns stays in the platform, not in individual heads.
Running systems in production
Whoever maintains mission-critical applications — internal or customer-facing — shortens resolution times and reduces dependence on a few expert individuals. The learning curve for new team members shortens too: incident history, with resolutions and patterns, is queryable.
End-customer support
Whoever provides assistance gains in responsiveness and — above all — in diagnostic autonomy. With the diagnostic package in hand and a Knowledge Base suggesting patterns it has already seen, first- and second-level support resolves a large share of incidents. Without involving the development team. Perceived customer value goes up; the people who build the product stay free to build.
Product and offering
DRH can be embedded as an observability module in the projects you propose to customers, or delivered as a dedicated SaaS service. Advanced diagnostic capability becomes part of what you sell — not an invisible implementation detail, but a describable advantage.
Diagnostics by design, not by auto-capture.
The developer decides what domain information to expose. DRH collects it, indexes it, makes it available to whoever needs to analyze an incident — and learns from previous resolutions.
Why auto-instrumentation isn't enough
Auto-instrumentation tools capture large volumes of infrastructure data — CPU, memory, latencies, network calls — without business context. For most real incidents, what matters is the application domain: which operation was being performed, on which entity, with which parameters. DRH starts from there.
For every event — an error, a performance anomaly, a specific trace — DRH produces a self-contained package. Inside is everything needed for analysis: logs, application payloads, system state, domain traits, metadata. The package (.cdpkg format) is transferable, archivable, analyzable even offline.
Collection from federated applications
When an incident crosses multiple services, DRH queries each of them and gathers the evidence into a single package. Correlation between traces and identifiers is reconstructed automatically. No more copy/paste across log windows.
Search across domain data
Not just logs and error messages: application payloads (JSON, XML, CSV) also become full-text searchable. "All orders above a given threshold with error status in the last seven days" is a query, not a manual extraction exercise.
Intentional design
The developer chooses what to expose using a dedicated kit: semantic traits (tenant identifier, transaction identifier, operation type), state datasets, correlation rules. It's an upfront cost in exchange for a compounding payoff: the data collected is the data that actually matters.
AI-powered Knowledge Base
Every analyzed incident leaves a trace: error patterns, identified root causes, applied solutions. An AI agent indexes them and surfaces them as references on new cases, with citations to the original packages. Knowledge no longer stays with individuals — it becomes queryable.
Question
What happened in TraceId T1?
Answer
Known pattern detected (94 percent confidence): IBAN validation error in the customer registry module. Suggestion from a previous case: verify tenant identifier synchronization. References: packages 7a3c, b21f.
Progressive adoption, no disruption.
DRH activates in three cumulative phases. You start with a minimal footprint that requires no network ports to be opened; you progressively add more advanced capabilities as the customer's context allows.
Offline acquisition
From the customer's perspective nothing changes. A dedicated CLI collects diagnostic packages directly on the machines where the applications live and transfers them out in a controlled way. No network ports to open, no new accesses to grant — suitable even for the most constrained security and compliance contexts, like banking or healthcare.
Centralized online hub
Applications expose dedicated diagnostic endpoints. DRH queries them, correlates, and materializes packages into a single hub. The viewer shows logs, payloads and traits in a common interface, browsable by trace, by project, by application.
Knowledge Base and AI suggestions
The pipeline that indexes error patterns and surfaces them as references on new incidents is activated. The agent becomes contextual on individual packages and capable of querying the entire corpus. From here value starts to compound: every new incident analyzed feeds the next ones.
DRH alongside traditional APM systems, not in place of them.
Tools like Datadog, Dynatrace or New Relic solve infrastructure monitoring. DRH is designed for the layer above: incident diagnosis that requires domain context. On the dimensions that matter for that problem, the choices are different.
Let's talk.
For your team. For the customers you serve. As a module to include in an offering. The best way to understand whether DRH fits your situation is to tell us about your context. If it makes sense, a few-week proof of concept is the natural next step.