Test

The Receiver runs alongside your log forwarder and acts on events as they flow through. It decides a per-pattern action for every pattern it sees: pass, sample, compact, tier_down, offload, or drop. An AI agent picks the action per service through the log10x MCP (the configure_engine tool); the engine enforces it, and the decision travels as a config change through the GitOps repo.

The actions:

pass: forward unchanged.
sample: forward a rate-limited share against a per-pattern budget.
compact: replace repeated lines with an encoded form the destination expands (lossless only where the destination supports it: Splunk, self-hosted Elasticsearch, ClickHouse; a no-op elsewhere). Requires the expand plugin installed in Splunk or Elasticsearch.
tier_down: tag the pattern for a cheaper storage tier the destination enforces (Datadog Flex, CloudWatch IA).
offload: route the pattern to customer-owned object storage (S3, GCS, Azure Blob) instead of the destination.
drop: stop forwarding the pattern.

The Receiver also runs in read-only mode (observation): receive events from the forwarder, run aggregators, and publish pattern-identity metrics with the event stream untouched. Use it for visibility into per-pattern volume and cost before any action is applied. Read-write mode (default) applies the per-pattern actions above.

Log10x is normally driven by an AI agent (Claude, or a model the customer brings) through the log10x MCP server, which installs, configures, and queries via MCP tools. The agent's configure_engine tool turns a target percent or budget into a per-pattern action set, carried as a cap/action CSV that lands in the config repo through a GitOps PR and hot-reloads on the next pull. The hand-authored cap YAML and CSV shown below are the same representation an agent produces.

Compact action

The compact action replaces repeated lines with an encoded form the destination expands at query time, operating on stable pattern identity. It is lossless only on Splunk, self-hosted Elasticsearch, and ClickHouse, where it typically cuts log volume by 50-80%, and a no-op on managed/SaaS destinations (there the levers are offload or drop). For SIEM-side plugin install, see the Splunk and Elasticsearch pages.

Setup Guide

Follow the steps below. Steps that require customization link to the relevant Config Files section where you can edit on github.dev or locally.

Step 1: Install

Install the Edge or JIT-Edge binary flavor on the same machine as your log forwarder:

Step 2: Set Environment Variables

Set these environment variables before running. See path configuration for details.

Variable	Description
`TENX_MODULES`	Path to your modules directory
`TENX_CONFIG`	Path to your configuration directory
`TENX_LICENSE_KEY`	Your Log10x license JWT (download from console)

export TENX_MODULES=/etc/tenx/modules
export TENX_CONFIG=/etc/tenx/config
export TENX_LICENSE_KEY="$(cat license.jwt)"

For production deployments, mount the license as a file and set TENX_LICENSE_FILE instead. See deploy.

Step 3: Configure Your Forwarder

Fluentd Fluent-bit Filebeat Logstash OTel Collector Vector Splunk UF Datadog Agent Test (no forwarder)

Step 1: Include the 10x receiver configuration:

my-fluentd.conf

# Nix/OSX
@include "#{ENV['TENX_MODULES']}/pipelines/run/modules/input/forwarder/fluentd/conf/tenx-receive-unix.conf"

# Windows
# @include "#{ENV['TENX_MODULES']}/pipelines/run/modules/input/forwarder/fluentd/conf/tenx-receive-stdio.conf"

Step 2: Apply the @TENX label to route events through the receiver:

Route StartRoute EndMid-Route

Process events directly after reading from input (simplest setup):

my-fluentd.conf

<source>
  @type tail
  path /path/to/file
  tag my_tag
  @label @TENX
</source>

Received events are marked with @TENX-PROCESSED. To re-apply @ROOT:

@include "#{ENV['TENX_MODULES']}/pipelines/run/modules/forwarder/fluentd/conf/auxiliary/root.conf"

Process events after all filters have been applied:

my-fluentd.conf

<source>
  @type tail
  tag my_logs
</source>

<filter my_logs>
  @type filter1
</filter>

<filter my_logs>
  @type filter2
</filter>

<match my_logs>
  @type relabel
  @label @TENX
</match>

<label @TENX-PROCESSED>
  <match my_logs>
    @type stdout
  </match>
</label>

Insert the receiver between specific plugins:

my-fluentd.conf

<source>
  @type tail
  tag my_logs
</source>

<filter my_logs>
  @type filter1
</filter>

<match my_logs>
  @type relabel
  @label @TENX
</match>

<label @TENX-PROCESSED>
  <filter my_logs>
    @type filter2
  </filter>

  <match my_logs>
    @type stdout
  </match>
</label>

Note

For large files or volume surges, set XMX or use read_bytes_limit_per_second.

Sidecar topology

Fluent Bit and Log10x run as peer processes that exchange events over the Fluent Forward protocol in both directions. No Lua filter, no io.popen() subprocess. The bypass (preventing the ingest filters from re-firing and the ingest [OUTPUT] forward from looping events) is tag-prefix namespacing. Fluent Bit has no labels like Fluentd, so the egress [INPUT] forward uses Tag_Prefix tenx. to put returning events on a tag namespace that the ingest pipeline doesn't match.

Step 1: Copy the Fluent Bit sidecar recipe:

cp $TENX_MODULES/pipelines/run/modules/input/forwarder/fluentbit/conf/tenx-sidecar.conf /etc/fluent-bit/

Step 2: Update sources, filters and destination outputs to match your environment. The recipe wires the ingest [OUTPUT] forward to log10x:24224 (matching your source tags) and the egress [INPUT] forward listening on :24225 with Tag_Prefix tenx., your destinations match tenx.*:

tenx-sidecar.conf

[SERVICE]
    Flush        1
    Log_Level    info

# Replace with your real sources, tag with anything NOT starting
# with `tenx.` so the bypass works.
[INPUT]
    Name         tail
    Path         /var/log/app.log
    Tag          app.logs
    Parser       json

# Enrichment filters Match the user-tag scheme only (NOT `*`).
[FILTER]
    Name         modify
    Match        app.*
    Add          cluster ${CLUSTER_NAME}

# Ingest: hand off to the Log10x sidecar.
[OUTPUT]
    Name         forward
    Match        app.*
    Host         127.0.0.1
    Port         24224
    Retry_Limit  False

# Egress: receive processed events back from Log10x. `Tag_Prefix
# tenx.` is the bypass, `app.logs` returns as `tenx.app.logs`,
# which filters and the ingest forward output don't match.
[INPUT]
    Name         forward
    Listen       0.0.0.0
    Port         24225
    Tag_Prefix   tenx.

# Destinations Match `tenx.*`, replace stdout with your real
# destination (es, splunk, kafka, s3, …).
[OUTPUT]
    Name         stdout
    Match        tenx.*
    Format       json_lines

Step 3: Start Log10x first so the Forward port is listening, then Fluent Bit:

tenx run @run/input/forwarder/fluentbit @apps/receiver
fluent-bit -c /etc/fluent-bit/tenx-sidecar.conf

Two structurally separate stages prevent loops and double-enrichment: ingest filters/output match app.* only, destination outputs match tenx.* only. The original tag survives the round trip as the suffix of the prefixed tag (tenx.app.logs), so destinations that route on the suffix behave the same as without Log10x in the path.

Step 1: Add the 10x input for receiving filtered events:

my-filebeat.yml

filebeat.config.inputs:
  enabled: true
  # Nix/OSX
  path: ${TENX_MODULES}/pipelines/run/modules/input/forwarder/filebeat/conf/tenxNix.yml
  # Windows
  # path: ${TENX_MODULES}/pipelines/run/modules/input/forwarder/filebeat/conf/tenxWin.yml

Step 2: Add the receiver processor:

my-filebeat.yml

filebeat.inputs:
  - type: filestream
    id: my-filestream-id
    paths:
      - /path/to/log

    processors:
      - script:
          lang: javascript
          file: ${TENX_MODULES}/pipelines/run/modules/input/forwarder/filebeat/script/tenx-receive.js

Set up multiple pipelines in pipelines.yml:

pipelines.yml

- pipeline.id: raw_input
  path.config: "/path/to/conf/upstream.conf"
- pipeline.id: tenx_pipeline
  path.config: "${TENX_CONFIG}/pipelines/run/input/forwarder/logstash/receive/tenx-pipe-out.conf"
- pipeline.id: tenx_unix_pipeline
  path.config: "${TENX_CONFIG}/pipelines/run/input/forwarder/logstash/receive/tenx-pipe-in-unix.conf"
- pipeline.id: processed
  path.config: "/path/to/conf/downstream.conf"

upstream.conf

input {
  file { path => /path/to/log }
}
output {
  pipeline { send_to => tenx_input_pipeline }
}

downstream.conf

input {
  pipeline { address => user_output_pipeline }
}
output {
  stdout { codec => json }
}

Distribution

Both directions use OTLP/gRPC (Collector → Log10x and Log10x → Collector), so the core otelcol distribution is sufficient. No otelcol-contrib build is required. Tested against otelcol v0.151.0+.

Step 1: Copy the Collector sidecar recipe:

cp $TENX_MODULES/pipelines/run/modules/input/forwarder/otel-collector/conf/tenx-sidecar.yaml /etc/otelcol/

Step 2: Update receivers and destination exporters to match your environment. The logs/to-tenx pipeline carries your receivers and enrichment processors through the otlp/tenx exporter; the logs/from-tenx pipeline carries returning events directly to your destination exporters:

tenx-sidecar.yaml

receivers:
  # Replace with your real Collector receivers
  filelog:
    include:
      - /var/log/**/*.log
    start_at: end

exporters:
  # Replace `debug` with your real destinations, elasticsearch, splunk_hec, kafka, awss3, etc.
  debug:
    verbosity: detailed

service:
  pipelines:
    logs/to-tenx:
      receivers: [filelog]
      processors: [batch]
      exporters: [otlp/tenx]
    logs/from-tenx:
      receivers: [otlp/tenx]
      exporters: [debug]

Step 3: Start Log10x first so the OTLP/gRPC port is listening, then the Collector:

tenx run @run/input/forwarder/otel-collector @apps/receiver
otelcol --config=/etc/otelcol/tenx-sidecar.yaml

Keep the egress pipeline (logs/from-tenx) processor-free, it carries returning events directly to your destination exporters so enrichment runs exactly once.

Requires Vector v0.34+

For the fluent source and socket sink with mode: unix. Vector communicates with the 10x sidecar over Unix domain sockets, newline-delimited text outbound, Fluent Forward inbound.

Step 1: Copy the Vector configuration:

cp $TENX_MODULES/pipelines/run/modules/input/forwarder/vector/receive/tenxNix.yaml /etc/vector/

Step 2: Update sources and final sinks to match your environment:

tenxNix.yaml

sources:
  # Replace with your real Vector sources
  app_logs:
    type: file
    include:
      - /var/log/**/*.log
    read_from: end

sinks:
  # Replace `console` with your real destination(s), elasticsearch, splunk_hec, kafka, s3, etc.
  final:
    type: console
    inputs:
      - tenx_out
    encoding:
      codec: json

Step 3: Start Log10x first, then Vector:

tenx run @run/input/forwarder/vector/receive @apps/receiver
vector --config /etc/vector/tenxNix.yaml

Two disconnected component chains in Vector's graph prevent loops: app_logs → tenx_in (events out to 10x) and tenx_out → final (received events in from 10x) never wire together.

File Relay Pattern

This integration uses a file relay pattern: Fluent Bit + 10x reads from Folder A, receives events, and writes to Folder B. Splunk UF monitors Folder B and handles forwarding to Splunk indexers.

Step 1: Set up folder paths:

export FOLDER_A=/var/log/app        # App writes here
export FOLDER_B=/var/log/processed  # UF reads from here
mkdir -p ${FOLDER_B}

Step 2: Configure Fluent Bit to read from Folder A, hand off to log10x, and write the processed events back out to Folder B. The egress [INPUT] forward Tag_Prefix tenx. is the bypass, only events that have round-tripped through log10x (and thus carry the tenx. prefix) hit the file output.

fluent-bit-splunk.conf

[SERVICE]
    Flush        1
    Log_Level    info

[INPUT]
    Name         tail
    Path         ${FOLDER_A}/*.log
    Tag          app.logs

# Ingest: hand off to the Log10x sidecar.
[OUTPUT]
    Name         forward
    Match        app.*
    Host         127.0.0.1
    Port         24224
    Retry_Limit  False

# Egress: receive processed events back from Log10x with Tag_Prefix
# bypass. `app.logs` returns as `tenx.app.logs`.
[INPUT]
    Name         forward
    Listen       0.0.0.0
    Port         24225
    Tag_Prefix   tenx.

# Write processed events (those with the tenx. prefix only) to Folder B.
[OUTPUT]
    Name         file
    Match        tenx.*
    Path         ${FOLDER_B}
    Format       plain

Start log10x first, then fluent-bit: tenx run @run/input/forwarder/fluentbit @apps/receiver && fluent-bit -c fluent-bit-splunk.conf.

Step 3: Configure Splunk UF to monitor Folder B:

inputs.conf

[monitor://${FOLDER_B}]
index = main
sourcetype = app_logs

This keeps Splunk UF as the forwarder (handling buffering, retries, timeouts) while 10x receives events inline. See the Splunk UF module for details.

File Relay Pattern

This integration uses a file relay pattern: Fluent Bit + 10x reads from Folder A, receives events, and writes to Folder B. Datadog Agent monitors Folder B and handles forwarding to Datadog.

Step 1: Set up folder paths:

export FOLDER_A=/var/log/app        # App writes here
export FOLDER_B=/var/log/processed  # DD Agent reads from here
mkdir -p ${FOLDER_B}

Step 2: Configure Fluent Bit to read from Folder A, hand off to log10x, and write the processed events back out to Folder B. The egress [INPUT] forward Tag_Prefix tenx. is the bypass, only events that have round-tripped through log10x (and thus carry the tenx. prefix) hit the file output.

fluent-bit-datadog.conf

[SERVICE]
    Flush        1
    Log_Level    info

[INPUT]
    Name         tail
    Path         ${FOLDER_A}/*.log
    Tag          app.logs

# Ingest: hand off to the Log10x sidecar.
[OUTPUT]
    Name         forward
    Match        app.*
    Host         127.0.0.1
    Port         24224
    Retry_Limit  False

# Egress: receive processed events back from Log10x with Tag_Prefix
# bypass. `app.logs` returns as `tenx.app.logs`.
[INPUT]
    Name         forward
    Listen       0.0.0.0
    Port         24225
    Tag_Prefix   tenx.

# Write processed events (those with the tenx. prefix only) to Folder B.
[OUTPUT]
    Name         file
    Match        tenx.*
    Path         ${FOLDER_B}
    Format       plain

Start log10x first, then fluent-bit: tenx run @run/input/forwarder/fluentbit @apps/receiver && fluent-bit -c fluent-bit-datadog.conf.

Step 3: Configure Datadog Agent to monitor Folder B:

conf.d/tenx.d/conf.yaml

logs:
  - type: file
    path: ${FOLDER_B}/*.log
    service: myapp
    source: myapp

This keeps Datadog Agent as the forwarder (handling buffering, retries, metadata enrichment) while 10x receives events inline. See the Datadog Agent module for details.

Test the receiver without setting up a forwarder using the Dev CLI.

The dev app uses the file input module to read sample log files and writes output to a file, allowing you to verify receiving behavior before integrating with your forwarder.

No forwarder configuration required - provide sample log files to the file input module and skip to Step 9 to run the test.

Step 4: Symbol Library (optional)

Load custom Symbol library files to transform events into typed TenXObjects.

Place symbol files in the symbolPaths folders specified in the symbol config.

Step 5: Pair with Retriever (optional)

Archive all events to S3 before receiving for full retention alongside cost control. The receiver filters what reaches your SIEM; filtered events remain in S3, queryable via Retriever for incident investigation, compliance, and auditing.

Configure your forwarder to duplicate the event stream, one copy to S3 (all events), one through the receiver (filtered events to SIEM):

Fluent-bit Fluentd OTel Collector Logstash Splunk UF Datadog Agent

Use the rewrite_tag filter to duplicate events onto an s3.* tag before they hit the ingest [OUTPUT] forward to the 10x sidecar:

[FILTER]
    Name         rewrite_tag
    Match        app.*
    Rule         $log .+ s3.$TAG true

# S3 archive: gets every event (`app.*` originals AND their `s3.app.*` copies
# adjust the rule above if you want only the copies).
[OUTPUT]
    Name         s3
    Match        s3.*
    bucket       your-archive-bucket
    region       us-east-1
    total_file_size 50M
    upload_timeout 60s

# Ingest: hand off to the Log10x sidecar (processed path).
[OUTPUT]
    Name         forward
    Match        app.*
    Host         127.0.0.1
    Port         24224
    Retry_Limit  False

Events tagged s3.* go to S3 (every event for full retention); events tagged app.* continue through the sidecar (processed). The egress [INPUT] forward Tag_Prefix tenx. and destinations matching tenx.* are unchanged from the main recipe.

Use the copy output plugin to send events to both S3 and the 10x sidecar:

<match app.**>
  @type copy
  <store>
    @type s3
    s3_bucket your-archive-bucket
    s3_region us-east-1
    path logs/
    <buffer time>
      timekey 3600
      timekey_wait 10m
    </buffer>
  </store>
  <store>
    @type forward
    # → 10x sidecar
  </store>
</match>

Fan out to the Retriever destination from the ingest pipeline (before 10x receives), so the archive sees full-volume events. The destinations that consume the egress pipeline (logs/from-tenx) get the receiver-processed stream:

exporters:
  awss3:
    s3uploader:
      region: us-east-1
      s3_bucket: your-archive-bucket
  # → 10x sidecar processes and receives, results land on logs/from-tenx
  otlp/tenx:
    endpoint: 127.0.0.1:4317
    tls:
      insecure: true

service:
  pipelines:
    logs/to-tenx:
      receivers: [filelog]
      processors: [batch]
      # Full-volume fanout: archive + 10x sidecar
      exporters: [awss3, otlp/tenx]
    logs/from-tenx:
      receivers: [otlp/tenx]
      exporters: [otlp/siem]   # receiver-processed stream

Use multiple outputs. Logstash natively sends to all configured outputs:

output {
  s3 {
    bucket => "your-archive-bucket"
    region => "us-east-1"
    size_file => 52428800
    time_file => 60
  }
  pipe {
    command => "/opt/tenx-edge/bin/tenx run ..."
    # → 10x sidecar processes and receives these events
  }
}

Splunk UF uses a file relay pattern. Fluent Bit + 10x reads from Folder A, processes events, and writes to Folder B. Splunk UF monitors Folder B and forwards to indexers.

Add the S3 output to the Fluent Bit configuration alongside the file output:

[FILTER]
    Name         rewrite_tag
    Match        app.*
    Rule         $log .+ s3.$TAG true

[OUTPUT]
    Name         s3
    Match        s3.*
    bucket       your-archive-bucket
    region       us-east-1
    total_file_size 50M
    upload_timeout 60s

# Received events written to Folder B for Splunk UF
[OUTPUT]
    Name         file
    Match        *
    Path         ${FOLDER_B}
    Format       plain

Splunk UF continues to monitor Folder B via inputs.conf. No changes to the UF configuration.

Datadog Agent uses a file relay pattern. Fluent Bit + 10x reads from Folder A, processes events, and writes to Folder B. The Datadog Agent monitors Folder B and forwards to Datadog.

Add the S3 output to the Fluent Bit configuration alongside the file output:

[FILTER]
    Name         rewrite_tag
    Match        app.*
    Rule         $log .+ s3.$TAG true

[OUTPUT]
    Name         s3
    Match        s3.*
    bucket       your-archive-bucket
    region       us-east-1
    total_file_size 50M
    upload_timeout 60s

# Received events written to Folder B for Datadog Agent
[OUTPUT]
    Name         file
    Match        *
    Path         ${FOLDER_B}
    Format       plain

The Datadog Agent continues to monitor Folder B via conf.d. No changes to the Agent configuration.

Step 6: Configure Receivers (optional)

Configure rate receivers for common scenarios. Edit these settings in your receiver config.yaml.

Per-Pattern Cap Multi-App Kubernetes Mute File (GitOps)

Cap any single log pattern at 20% of its container's volume. The Level Classifier enriches events with severity, so the floor keeps ERROR events flowing even when a pattern is over its cap.

rateReceiver:
  fieldNames:
    - symbolMessage              # the pattern identity
  containerField: container      # scopes the share denominator
  maxSharePerFieldSet: 0.2       # no pattern exceeds 20% of its container
  severityFloors:
    - INFO=0.1
    - WARN=0.3
    - ERROR=0.5

The floor beats the cap: a pattern over 20% still keeps Error 50%, Warn 30%, Info 10%. At or below the cap every event passes through untouched.

Cap each pattern per app, scoped by container so all of an app's replicas share one cap. The container name stays constant across pods.

rateReceiver:
  fieldNames:
    - symbolMessage
  containerField: container      # same name across all pod replicas

Each (pattern, container) pair gets its own 20% cap. Scaling from 1 to 10 pods does not bypass it because the container name is stable across replicas.

Layer a declarative mute file over the rate receiver, pulled from a git repo. Entries are keyed by the same fieldNames values the rate receiver uses (e.g. symbolMessage), so mutes target the same patterns a Reporter attributes cost to. A listed, active pattern is decided by its entry; every other pattern stays on the cap. Each entry has an explicit sample rate and epoch expiry, so mutes are diff-reviewed, audited, and self-healing.

rateReceiver:
  fieldNames:
    - symbolMessage
  lookup:
    file: /etc/log10x/config/data/sample/mutes/mutes.csv
    retain: 300000                 # mark stale after 5 minutes

Entries in mutes.csv look like Error_syncing_pod=0.10:1744848000:pod error spam OPS-4821. See protection list for the format and workflow.

Step 7: Enrichments (optional)

Enrichments add context (severity, HTTP codes) for richer aggregation and filtering.

To enable:

In the app config, uncomment the desired enrichment include entries
In the initializers section below, configure each enrichment's settings

Step 8: Metrics Output (optional)

Publish aggregated metrics to time-series databases (Prometheus, Datadog).

To enable:

In the app config, uncomment the desired metric output include entry
In the metric outputs section below, configure connection details

Step 9: Run

Start your forwarder with the updated configuration:

Fluentd Fluent-bit Filebeat Logstash OTel Collector Splunk UF Datadog Agent Test (no forwarder)

$ fluentd -c my-fluentd.conf

Start Log10x first so its Forward port is listening when Fluent Bit starts, then start Fluent Bit:

$ tenx run @run/input/forwarder/fluentbit @apps/receiver
$ fluent-bit -c /etc/fluent-bit/tenx-sidecar.conf

Nix/OSX

$ filebeat -c my-filebeat.yml -e 2>&1 | /opt/tenx-edge/bin/tenx run @run/input/forwarder/filebeat @apps/receiver

Windows

$ filebeat -c my-filebeat.yml -e 2>&1 | "c:\program files\tenx-edge\tenx" run @run/input/forwarder/filebeat @apps/receiver

$ logstash -f my-logstash.conf

Start Log10x first so its OTLP/gRPC port is listening when the Collector starts, then start the Collector:

$ tenx run @run/input/forwarder/otel-collector @apps/receiver
$ otelcol --config=/etc/otelcol/tenx-sidecar.yaml

Step 1: Start Log10x first, then Fluent Bit:

$ tenx run @run/input/forwarder/fluentbit @apps/receiver
$ fluent-bit -c fluent-bit-splunk.conf

Step 2: Start (or restart) Splunk UF to pick up Folder B:

$ splunk restart

Fluent Bit reads from Folder A, hands off to the Log10x sidecar, and writes processed events back out to Folder B. Splunk UF monitors Folder B and forwards to indexers.

Step 1: Start Log10x first, then Fluent Bit:

$ tenx run @run/input/forwarder/fluentbit @apps/receiver
$ fluent-bit -c fluent-bit-datadog.conf

Step 2: Start (or restart) the Datadog Agent to pick up Folder B:

$ sudo systemctl restart datadog-agent

Fluent Bit reads from Folder A, hands off to the Log10x sidecar, and writes processed events back out to Folder B. Datadog Agent monitors Folder B and forwards to Datadog.

Use the Dev CLI to test event processing with sample log files.

Step 1: Provide sample log files to the file input module:

$ cp /path/to/sample.log $TENX_CONFIG/data/sample/input/

Step 2: Run the dev app:

$ tenx run @apps/dev

The dev app reads events from data/sample/input/*.log via the file input module, processes them through the receiving pipeline, and writes results to the configured file output.

Verify output:

$ wc -l $TENX_CONFIG/data/sample/output/encoded.log

Compare input vs output line counts to verify event processing.

Step 10: Verify

Verify no errors appear in the log file. For debugging techniques including enabling verbose logging, see Engine Logging.

View results in the dashboard:

Once running, view your cost analytics in the Receiver Dashboard.

Step 11: Teardown

Nothing runs in the background. Uninstall removes only what was installed.

Homebrew Linux Windows Docker

brew uninstall log10x

sudo rm -rf /opt/tenx-edge /etc/tenx /etc/profile.d/tenx-edge.sh

If installed via DEB: sudo apt-get remove tenx-edge If installed via RPM: sudo yum remove tenx-edge

Uninstall from Settings > Apps > Installed apps.

docker rmi log10x/pipeline-10x:latest

Config Files

To configure the Receiver app, Edit these files:

Main Config

The main config file loads the Receiver app's required modules.

Uncomment selected modules at: receiver/config.yaml.

Name	Description
receiverOptimize	Enable optimization (compact mode) to encode emitted events for volume reduction
receiverReadOnly	Read-only mode, receive events, emit metrics, do not write back to the forwarder

Test

Compact action

Setup Guide

Config Files

Main Config

Initializers

message

level

group

httpCode

lookup

k8s

geoIP

Receivers

rate

compact

Metric Outputs

log10x

scrape

push-gateway

remote-write

datadog

cloudwatch

elastic

signalFx

log

Advanced Config Files

Bootstrap

Github Sync

Symbols

Aggregators

Template

Transform

timestamp

fields

symbol

group

parallelize

Options

receiverOptimize

receiverReadOnly

`receiverOptimize`

`receiverReadOnly`