Skip to content
CosmoTrace
Menu

Platform · CosmoEdge

One binary. No configuration file. A report of what it could not reach.

CosmoEdge is the part of CosmoTrace that lives on your node, so it is the part we expect you to judge us on. This page says what it needs from you, what it does to data before that data leaves, what it recognises, what it does with the rest, and where it draws its limits.

What happens on the node

Discover, parse, mask, buffer, ship — and report

CosmoEdge: what happens to data on the node Events from five sources on a node flow through discover, parse, mask and a disk buffer, then leave over port 443. A coverage report underneath records what was refused, sampled or lost. Animated; static when reduced motion is requested. ON THE NODE CosmoEdge · one binary · no configuration file /var/log/* journald container stdout auth · sudo · exec process tree discover what exists parse or keep opaque mask · classify before it leaves buffer on disk CosmoStream outbound 443 coverage report refused /var/log/secure no permission for user cosmo sampled container stdout 1:8 over search budget lost 0 events buffer 14% · link up shipped with the data measured: 110k events/s · 1 vCPU · under 100 MB resident
Events flow through discover, parse, mask and the disk buffer; the coverage report underneath records what was refused, sampled or lost. Static if your system asks for reduced motion.

Where it runs

Any node that produces data

Store
Point-of-sale and retail back-office boxes with little CPU to spare. The half-core figures below are for these.
Plant
OT gateways and industrial hosts where the link to the datacenter is slow or intermittent. The disk buffer is for these.
Tower
Telco far-edge sites: many small nodes, one operator, no one on site. Coverage reporting is for these.
Kubernetes node
A DaemonSet. Discovers pods and their metadata as they come and go.
Host
A VM or bare metal under systemd. The plain case.

What it needs from you

Three things

A way to run it
A statically linked binary under systemd, or a DaemonSet. There is no configuration file to write; the environment it lands in is the configuration.
Outbound 443
To your stream endpoint — ours in a region you pick, or yours on your network. No inbound ports. No ingress rules.
Read access to what you want covered
It does not need root. Whatever it cannot read is listed in the coverage report as refused, with the path and the permission it lacked, so the fix is one line in your provisioning.

Discovery and parsing

What it recognises, and what it does with the rest

On start the agent walks the node: files under the usual log paths, journald, container runtime output, Kubernetes pod metadata when present, the authentication and privilege trail (sshd, sudo, exec), and the live process tree. It keeps walking; a service that appears at 3 a.m. is discovered at 3 a.m.

For each source it recognises the format, it parses fields on the node so that class and masking can be applied before the event leaves. Formats recognised at launch:

| Family | Formats | | --- | --- | | Structured | JSON lines · logfmt · journald fields · CRI and Docker JSON-file container logs | | System | syslog RFC 3164 and RFC 5424 · auth and sudo logs · kernel ring buffer | | Web servers | Apache and Nginx combined and error logs | | Runtimes | glog / klog · multi-line Java and Python stack traces joined into one event | | Databases | PostgreSQL CSV and stderr logs |

The opaque fallback. Anything else is kept as a line — unmodified, with time, source path, node and the full hierarchy attached. It is searchable as text, it counts toward coverage, and it is never dropped for being unfamiliar. When a format is added later, historical opaque lines from that source are re-parsed in the lake; nothing was lost in the meantime.

Coverage

Refusal, sampling and loss are visible, not silent

Every agent ships a coverage report alongside its data, and the console shows it beside the node it came from. It has three sections and each entry names a cause and a fix.

Refused
A source exists and the agent could not read it. The path and the missing permission are recorded. The event count is zero and you know why.
Sampled
A source exceeded the budget you set for its class. The rate and the rule applied are recorded; evidence-class sources are never sampled, so you are told when a policy would have sampled them and did not.
Lost
The disk buffer filled or the link stayed down past the buffer's horizon. The window and the count are recorded. Loss is a number in your report, not a gap you find during an incident.

Limits

Measured ceilings

You set a CPU and memory cap; the agent stays under it and reports sampling if the cap was the reason. These are the numbers we have measured on a fixed event shape. We will not quote a number for your estate until we have replayed the same test on your node.

110kevents/s
1 vCPU

Under 100 MB resident. Parse, mask and classify on.

25kevents/s
0.5 vCPU

50 MB resident. Sort and mask on.

0OOM kills
150 MB cap

Half-core run, full duration.

<100MB
Binary and resident memory

One statically linked executable.

Measurements are first-party. Third-party comparisons are not published here; if you want them, ask and we will show you the runs.

Put CosmoEdge on one node.

A design-partner run replays these figures on your event shape, with masking on, and leaves your current agent in place.

Request a demo