Controlled Evaluation and Coexistence Guide

Evaluation Principles

The controls that keep the evaluation bounded, reversible, and measurable:

1. 1. Choose a representative production boundary.

   Include enough related services and signals to reproduce the incident complexity you need to evaluate. Define approved fields, environment, expected volume, and data classification before routing telemetry.

2. 2. Keep the production control plane unchanged.

   Do not make the trial part of your production paging path. Compare what Epok detects and groups while the system your responders trust remains the source of truth.

3. 3. Define the decision before ingest.

   Score correct, incorrect, abstained, and missed outcomes separately. Compare alert fanout, time to verified cause, telemetry coverage, and responder effort, then make an explicit expand, coexist, or stop decision.

From Datadog

Keep the Datadog Agent and every monitor in place. The Agent is not a generic Epok forwarder, so mirror a representative production boundary through a second open collection path: add Epok to an existing OpenTelemetry pipeline, or let Vector or Fluent Bit read the same approved log sources Datadog already reads.

Evaluation steps

1. Keep the Datadog Agent, dashboards, and monitors unchanged.
2. Choose a representative service group, ownership domain, environment, or critical user journey. Add Epok as a second exporter in its existing OpenTelemetry Collector, or run an open shipper against the same approved sources.
3. Preserve `service`, `env`, and trace identifiers, then verify the same events arrive in both tools.
4. Compare the same incident cohort: correct, incorrect, abstained, and missed outcomes; alert fanout; time to verified cause; and responder effort.
5. Expand only after Epok clears the agreed quality, security, and operational gates; uninstall nothing during evaluation.

Config

# vector.toml — mirror an approved evaluation scope beside Datadog

[sources.evaluation_scope]
type = "file"
include = ["/var/log/my-service/*.log"]
read_from = "end"

[transforms.identify]
type = "remap"
inputs = ["evaluation_scope"]
source = '''
.service = "my-service"
.env = "production"
'''

[sinks.epok]
type = "elasticsearch"
inputs = ["identify"]
endpoints = ["https://ingest.getepok.dev"]
bulk.index = "logs"
# Required. Epok is not a real Elasticsearch: the default api_version "auto"
# sniffs the version against our root (404) and the sink then never starts.
api_version = "v8"
healthcheck.enabled = false

[sinks.epok.auth]
strategy = "basic"
user = "YOUR_EPOK_API_KEY"
password = "x"

Gotchas

• A Datadog-agent-only setup does not automatically fan out to Epok. Read the same files or container output with a second shipper; do not redirect the Agent and accidentally interrupt Datadog.
• Datadog tags are not magically copied across an independent path. Add stable `service` and `env` fields at the shipper and preserve trace IDs if you want cross-signal correlation.
• Datadog dashboards, monitors, archives, and rehydration workflows do not port automatically. Keep them active while Epok earns a narrower incident-response role.

From New Relic

Keep New Relic agents, dashboards, and alert conditions running. If you already collect through OpenTelemetry, add Epok as a second exporter. A proprietary-agent-only setup needs a separate OpenTelemetry or open-shipper path for the service under evaluation.

Evaluation steps

1. Leave New Relic and its alert conditions untouched.
2. Choose a representative production boundary. Duplicate its existing OpenTelemetry export to Epok, or add OpenTelemetry or an open log shipper if the relevant services are agent-only.
3. Verify `service.name`, environment, and trace context in both products.
4. Use the same incident cohort and scorecard: correct, incorrect, abstained, and missed outcomes; alert fanout; time to verified cause; and responder effort.
5. Treat replacement as a later decision. Epok can remain an incident layer while New Relic keeps broader APM and dashboards.

Config

# otel-collector.yaml — add Epok beside your existing New Relic exporter

exporters:
  # Keep your existing New Relic exporter exactly as configured.
  otlphttp/epok:
    endpoint: https://ingest.getepok.dev
    headers: { x-api-key: YOUR_EPOK_API_KEY }

service:
  pipelines:
    traces:
      # Keep the existing receivers and processors.
      exporters: [otlphttp/newrelic, otlphttp/epok]
    logs:
      exporters: [otlphttp/newrelic, otlphttp/epok]

Gotchas

• The exporter name `otlphttp/newrelic` is illustrative—keep the actual exporter name already present in your Collector config.
• New Relic proprietary agents are not general-purpose Epok exporters. Agent-only environments need a second path; limit it to the approved signals and fields in the evaluation boundary.
• NRQL alerts and dashboards stay in New Relic during evaluation. The trial tests Epok's incident output, not automatic translation of your existing estate.

From Splunk

Splunk HEC is a proprietary wire protocol. Epok provides a Vector-based shim: your app keeps sending HEC events; Vector translates them to Epok's Elasticsearch Bulk API in-flight.

Evaluation steps

1. Install Vector on the same host as your existing Heavy Forwarder (or anywhere HEC traffic can reach).
2. Configure Vector's `splunk_hec_logs` source with your existing HEC token — apps keep their Splunk config unchanged.
3. Sink into Epok's Elasticsearch Bulk API.
4. Cutover gradually: point half your forwarders at the Vector shim, watch Epok, then move the rest.
5. Retire Splunk indexers on your own schedule — no hard deadline.

Config

# vector.toml — Splunk HEC → Epok

[sources.splunk_in]
type = "splunk_hec_logs"
address = "0.0.0.0:8088"
token = "YOUR_EXISTING_HEC_TOKEN"

[sinks.epok]
type = "elasticsearch"
inputs = ["splunk_in"]
endpoints = ["https://ingest.getepok.dev"]
bulk.index = "logs"
# Required. Epok is not a real Elasticsearch: the default api_version "auto"
# sniffs the version against our root (404) and the sink then never starts.
api_version = "v8"
healthcheck.enabled = false

[sinks.epok.auth]
strategy = "basic"
user = "YOUR_EPOK_API_KEY"
password = "x"

Gotchas

• Splunk `sourcetype` and `host` become top-level fields in Epok — equivalent to `service` and `host` on the Epok side.
• SPL (Splunk Search Processing Language) → Epok search syntax: most searches translate 1:1. `index=main error | stats count by host` becomes `error | stats by (host) count()`.
• Splunk's `| lookup` and `| inputlookup` don't have direct equivalents; reproduce with saved searches and facet filtering.

From Grafana Loki

Easiest migration. Epok speaks native Loki push — no shim required. Point your existing Promtail, Grafana Alloy, or FluentBit clients at Epok and you're done.

Evaluation steps

1. Update your shipper's endpoint to `https://ingest.getepok.dev/loki/api/v1/push`.
2. Use Basic Auth: username = your Epok API key, password = any string.
3. Dual-ship to Loki and Epok for 24 hours to verify.
4. Flip alerts and dashboards to Epok. Loki can be retired on your own schedule.

Config

# Promtail / Grafana Alloy / FluentBit — same config, new URL + auth.

# promtail.yaml
clients:
  - url: https://ingest.getepok.dev/loki/api/v1/push
    basic_auth:
      username: YOUR_EPOK_API_KEY
      password: x

# grafana-alloy (alloy.river)
loki.write "epok" {
  endpoint {
    url = "https://ingest.getepok.dev/loki/api/v1/push"
    basic_auth {
      username = "YOUR_EPOK_API_KEY"
      password = "x"
    }
  }
}

Gotchas

• Loki labels map to Epok stream fields. `{app="api",env="prod"}` becomes searchable as `service:api AND env:prod` in Epok's search syntax.
• Loki queries use LogQL; Epok uses its own search syntax. Close cousins — most LogQL expressions translate with minor syntax tweaks.
• Ruler rules don't port automatically. Rewrite them as Epok threshold rules or let anomaly detection replace them.