Transports

The SkyAPM .NET agent buffers the tracing, metrics, profiling, management, and log data it collects, then ships it to the SkyWalking OAP backend through a transport (also called a reporter). This guide explains how to pick a transport and how to tune it. For the full configuration model, file locations, and override precedence, see Configuration.

Selecting a transport

The transport is selected by a single setting:

{
  "SkyWalking": {
    "Transport": {
      "Reporter": "grpc"
    }
  }
}

When Reporter is omitted, the agent defaults to grpc. All transports use the SkyWalking v8 / sw8 protocol; this is the only protocol the agent speaks (Transport.ProtocolVersion defaults to v8, HeaderVersions defaults to ["sw8"]).

Common transport tuning

These options live directly under SkyWalking:Transport and apply regardless of which reporter you choose. The agent maintains Parallel independent queue/worker pairs; the totals below are the per-queue values multiplied by Parallel.

{
  "SkyWalking": {
    "Transport": {
      "Reporter": "grpc",
      "ProtocolVersion": "v8",
      "QueueSize": 10000,
      "BatchSize": 2000,
      "Parallel": 5,
      "Interval": 50
    }
  }
}

Raise QueueSize / BatchSize (or Parallel) for high-throughput services that would otherwise drop data; lower Interval to reduce reporting latency at the cost of more frequent backend round-trips.

gRPC transport (default)

The gRPC transport streams data directly to the OAP gRPC receiver (default port 11800). Its options live under SkyWalking:Transport:gRPC.

Servers

Servers accepts one or more addresses separated by commas (,). Each address is normalized as follows: if it does not already contain a :// scheme, the agent prefixes it with http://. This lets you point at a single backend, a fixed set of backends, or a gRPC name-resolver / load-balancing scheme.

{
  "SkyWalking": {
    "Transport": {
      "Reporter": "grpc",
      "gRPC": {
        "Servers": "oap-host:11800",
        "ConnectTimeout": 10000,
        "Timeout": 10000,
        "ReportTimeout": 600000
      }
    }
  }
}

Multiple explicit addresses (each gets an http:// prefix automatically):

{
  "SkyWalking:Transport:gRPC:Servers": "oap-1:11800,oap-2:11800,oap-3:11800"
}

Using a gRPC load-balancing scheme — because these include a ://, the agent leaves them untouched:

• dns:// — resolve a DNS name to the live set of OAP backends, e.g. dns:///oap.skywalking.svc:11800 (lets the gRPC client load-balance across all resolved addresses, ideal for Kubernetes headless services).
• static:// — a fixed, comma-style list handled by the gRPC client’s static resolver, e.g. static://oap-1:11800,oap-2:11800.

{
  "SkyWalking:Transport:gRPC:Servers": "dns:///oap.skywalking.svc:11800"
}

Authentication

If the OAP backend has token authentication enabled, set Authentication to the shared token. The agent sends it on every gRPC call as the metadata header Authentication. Leave it empty to disable.

{
  "SkyWalking": {
    "Transport": {
      "gRPC": {
        "Servers": "oap-host:11800",
        "Authentication": "your-oap-token"
      }
    }
  }
}

Kafka transport

The Kafka transport publishes data to Kafka topics instead of calling the OAP gRPC receiver directly. OAP then fetches the data from those topics.

When to use it

Choose Kafka when you want to decouple agents from the OAP backend with a durable buffer — for example to absorb large traffic spikes, to survive temporary OAP outages without dropping data, or to fan data into a Kafka-centric ingestion pipeline. For most deployments the default gRPC transport is simpler and is the recommended starting point.

OAP-side requirement

The Kafka transport only works if SkyWalking’s Kafka fetcher is enabled on the OAP side (the kafka-fetcher module in the backend). The agent’s topic names must match the topics the OAP fetcher consumes. Configure and enable the fetcher on the backend before switching the agent to kafka; otherwise the published data will never be ingested.

Configuration

Set Reporter to kafka and configure the broker list and topic names under SkyWalking:Transport:Kafka.

The default topic names match SkyWalking’s defaults, so you normally only need to set Reporter and BootstrapServers. Override the topic names only if your OAP Kafka fetcher is configured to consume from different topics.

Example

{
  "SkyWalking": {
    "ServiceName": "your_service_name",
    "Transport": {
      "Reporter": "kafka",
      "Interval": 50,
      "QueueSize": 10000,
      "BatchSize": 2000,
      "Parallel": 5,
      "Kafka": {
        "BootstrapServers": "kafka-1:9092,kafka-2:9092",
        "TopicTimeoutMs": 3000,
        "MessageTimeoutMs": 5000,
        "TopicMeters": "skywalking-meters",
        "TopicCLRMetrics": "skywalking-clr-metrics",
        "TopicSegments": "skywalking-segments",
        "TopicProfilings": "skywalking-profilings",
        "TopicManagements": "skywalking-managements",
        "TopicLogs": "skywalking-logs"
      }
    }
  }
}

Overriding via environment variables

Every transport setting can be supplied through environment variables using the double-underscore (__) separator, which is convenient for containers and CI. Environment variables override values from the config file. For example:

export SKYWALKING__TRANSPORT__REPORTER=grpc
export SKYWALKING__TRANSPORT__GRPC__SERVERS=oap-host:11800
export SKYWALKING__TRANSPORT__GRPC__AUTHENTICATION=your-oap-token

See Configuration for the complete list of settings and the configuration source precedence.