Operate
DFE is deployed. Now it needs people, data, and a way to tell it's healthy.
The first week
In this order:
- Sign in as
adminand change the password. Where the logins are: Users and OIDC. - Connect your identity provider, so your people sign in as themselves. Same page.
- Add a source. Events land in
mainuntil you do. A source is one stream of events, with its routing, its table and its detections in one definition. - Reshape the stream if the record as it lands isn't enough: Transforms.
- If you want scheduled rules and alerts: Detections and hunts.
- Find out how you'll know when something breaks: Monitoring.
Sources
A source has one origin. Either the receiver matches pushed events to it, or a fetcher pulls them.
| Origin | How events arrive | Start at |
|---|---|---|
| Pushed | Your agents and devices send to dfe-receiver, which terminates their protocols at the edge | The source definition, then webhook callers for products that push alerts |
| Fetched | dfe-fetcher dials out to a SaaS or cloud API on an interval | Cloud and SaaS setup guides |
Sources is how you browse the catalogue of ready-made ones and create them in one call.
A source is active, dormant or disabled. Storing and operating a source says what each state does to its table. Data evolution is how a stream goes from landing raw to having its own columns, one field at a time.
Coming from Splunk or Elastic? You don't define a schema before data flows. Every field from a new source works from the first event. Then you put schema effort only into the fields that pay you back: promote them in the meta schema, tighten their definitions, and name the searches you need so DFE picks the right indexes. Promotion doesn't backfill: new records land in the column, older ones stay readable where they were. Nothing that already works breaks along the way. More in what's different.
Everything else
| You want to | Go to |
|---|---|
| Reshape events on the way in | Transforms |
| Let people in, and decide what they can do | Users and OIDC |
| Search, build dashboards, define rules and hunts | The console. Its menu runs in the order the data moves: Observe, Data flow, Detect, Stack, Access |
| Run rules on a schedule | Detections and hunts |
| Watch the stack's own health | Monitoring |
| Grow it | Autoscaling. Pods scale on KEDA on every target, and node scaling differs per target |
| Keep it running, and fix it when it isn't | Day to day and troubleshooting |
| Move to a newer release | Upgrades, and the rollback runbook |
| Keep the raw copy of every record | Set archive: true in a source's flow. The source flow says what that needs |