Observability
engineering

Telemetry pipelines, instrumentation and monitoring for engineering teams. Work directly with Jacky Pham, from the first investigation to handover.

Follow one signal

Inspect a synthetic event as its fields are checked, its destination fails and delivery recovers.

Keep the useful context

A service name, environment and correlation ID let a responder connect this event to an investigation.

The synthetic email is deliberately included to test redaction. In production, unnecessary personal data should be omitted at the source.

Field to remove
customer_email
The original event
{
  "service": "snoogz-demo",
  "event": "request.completed",
  "environment": "sandbox",
  "correlation_id": "demo-1042",
  "customer_email": "guest@example.test"
}

Remove the private field

The email has been removed. The fields needed to find the event remain unchanged.

Agree on an allowed schema, test the output at every destination and keep credentials out of telemetry.

Context preserved
demo-1042
The approved output
{
  "service": "snoogz-demo",
  "event": "request.completed",
  "environment": "sandbox",
  "correlation_id": "demo-1042"
}

Account for the interruption

The destination is unavailable in this example. The redacted event waits for a bounded retry; delivery is still pending.

A real pipeline needs agreed buffer limits, retry limits and an owner to alert when events are rejected or capacity is exhausted.

Delivery in this example
Pending
The event held for retry
{
  "service": "snoogz-demo",
  "event": "request.completed",
  "environment": "sandbox",
  "correlation_id": "demo-1042"
}

Find the same event

The destination is restored in this example. The same redacted event can be found using its original correlation ID.

Test recovery against the selected collector and destination. Document duplicates, drops and delivery guarantees rather than assuming them.

Investigation reference
demo-1042
The recovered event
{
  "service": "snoogz-demo",
  "event": "request.completed",
  "environment": "sandbox",
  "correlation_id": "demo-1042"
}

A browser-only simulation using synthetic data. Nothing is collected or sent. Actual buffering, retention and delivery behaviour depend on the tools and configuration agreed for your project.

Start with one service

Bring a difficult investigation. We trace the path from application to collector, pipeline and monitoring tool, then scope the change.

Capture the context
OpenTelemetry instrumentation and log processing that preserve the service, environment and request context your team needs.
Control the route
Field rules, destinations and retention shaped around existing tools, access, data volume and provider limits.
Support the responder
Dashboards and alerts tied to an investigation question, a named owner and a useful first step.

Production experience

lululemon

Observability pipelines with Edge Delta. Platform ownership of Splunk and Datadog, alongside AI tooling and use-case development.

Albertsons / Safeway

Grafana, Prometheus, Loki and OpenTelemetry instrumentation, with production incident support.

Experience from Jacky’s roles within these teams. Each Snoogz engagement has its own scope, access and review process.

Evidence at handover

Agree on acceptance before changing the pipeline. Review the test results and remaining limits together.

What we check

Trace the path
A known test event reaches its intended destination with the same investigation reference.
Check the fields
Approved context remains; prohibited fields are absent at every permitted output.
Exercise a failure
An interrupted destination exposes what is retained, retried, rejected or dropped.
Reach the responder
The agreed alert reaches the responsible team with accessible evidence and investigation instructions.

What you receive

The agreed configuration or code, test evidence, dashboards and a short runbook. Deployment, rollback, account access and alert ownership each have a named owner.

Choose a defined project or embedded engineering. Ongoing maintenance, response hours and incident responsibilities are scoped separately.

Start with an assessmentIf access or feasibility needs to be established first.

Before we start

Can we keep our current tools?

That is the starting point. We review the current collection and monitoring setup, the questions it must answer and the constraints on changing it. A new tool is an option when the existing setup cannot meet an agreed requirement.

Is this 24/7 monitoring?

A project or embedded engagement does not automatically include round-the-clock monitoring or incident response. Response hours, alert ownership and support responsibilities are agreed explicitly before work begins.

Where does AI fit?

Possible uses include preparing an incident summary or helping a responder search approved runbooks. We assess the information available to the tool and how its output will be checked. Access to production data and automated actions require an agreed scope; they are not assumed.

What should we bring?

Start with one difficult investigation, the tools involved and the result your team needed. Share sanitised examples first. We agree on access before reviewing production systems or sensitive telemetry.

Start a project

Tell me which workflow or system needs attention. Five short questions help outline a review, project or embedded engagement you can discuss by email.

Start a project Review your brief, then continue in email.
Prefer email?jacky@snoogz.ca

Snoogz Software is based in Canada and uses Google Workspace for email. These services may process your information outside your country. Please avoid sensitive personal information. Read our privacy notice.

Start a project
Snoogz Software

What would you like to start with?

Five short questions, then a brief you can review and email. Projects can cover integrations, internal tools, websites or observability.