Welcome! Simplifi'ED is now Omnivya. We're excited to announce that Simplifi'ED has evolved into Omnivya! This transformation reflects our commitment to serving you even better, with expanded expertise in Cloud Native, Kubernetes, GreenOps, FinOps, and DevSecOps. Our new brand embodies innovation, sustainability, and security so you can accelerate your digital journey with confidence. Thank you for trusting us as your technology partner! Learn more

Area of expertise

OpenTelemetry and observability

Collecting more telemetry does not automatically shorten investigations. Without operational questions, conventions, and volume control, signals become expensive yet remain hard to interpret.

Operational definition

Observability connects traces, metrics, and logs to reliability questions. OpenTelemetry provides instrumentation conventions and pipelines, but does not replace the service model or operational decisions.

Problems actually encountered

  • 01

    Abundant telemetry without a service model

  • 02

    Cardinality and retention causing unexpected cost

  • 03

    Context propagation broken across components

  • 04

    Dashboards unable to explain an incident

Decisions involved

  • Define the questions each signal must answer
  • Choose conventions, instrumentation points, and sampling strategy
  • Balance pipeline, storage, retention, and provider independence

Common errors

  • Instrumenting everything before defining use cases
  • Copying dashboards without checking semantics
  • Moving provider dependency into an opaque collection layer

Signals that external expertise becomes useful

  • Every incident triggers ad hoc collection
  • Costs rise faster than useful coverage
  • Two teams assign different meaning to the same attribute

Omnivya method

  1. 1.

    Start from representative incidents and decisions

  2. 2.

    Map services, propagation, and signal consumers

  3. 3.

    Assess telemetry quality, cost, and gaps

  4. 4.

    Define conventions and testable changes

Possible deliverables

  • Service model and signal-question matrix
  • Documented OpenTelemetry conventions
  • Instrumentation, sampling, and cost-control plan

Evidence of reasoning

  • Repeatable investigation queries
  • Conventions validated on real flows
  • Telemetry budget tied to use cases

Browse public work

Explicit limits

  • No recommendation to retain everything
  • No presenting OpenTelemetry as a complete strategy
  • No guarantee that a tool will resolve incidents

Related mission formats

Frequently asked questions

Does OpenTelemetry reduce provider lock-in?
It improves instrumentation portability, but storage, queries, dashboards, and operating practices may remain dependent.
Should we start with traces?
Not always. The first signal depends on the question, system, and quality of existing data.
Can you review observability costs?
Yes, by connecting ingestion, cardinality, retention, and queries to the use cases that justify those costs.

Make observability testable

If this tension is yours, let’s frame the decision before widening the scope.

Make observability testable