AppSignal

The AppSignal sink delivers observability data from Kron TP to AppSignal over the AppSignal Push API. It supports both log and metric events, batches outbound traffic for efficiency, and provides at-least-once delivery semantics. Because delivery is at-least-once, duplicates are possible in retry scenarios and should be considered normal in failure conditions.

This sink is currently marked as beta. In practice, that means you should treat changes between Kron TP versions as more likely than for stable sinks, and you should validate behavior in a staging environment before rolling out widely.

Kron TP collects events from upstream components and sends them to the AppSignal API endpoint. Events are grouped into batches and optionally compressed before transmission. The sink is stateless, meaning it does not maintain long-term delivery state beyond the configured buffering model (memory or disk).

AppSignal ingestion uses an app-level push API key. If that key is invalid, missing, or revoked, the sink will fail to deliver and will continuously retry according to the configured retry policy.

push_api_key This is mandatory and must be a valid AppSignal Push API key for the target application. It authorizes ingestion into your AppSignal account and application context. Treat it like a secret: store it in a secret manager, inject it via environment/secret mechanisms, and avoid placing it directly into config repositories.

inputs A list of upstream source or transform IDs that feed data into this sink. Wildcards can be used to subscribe to multiple components. Since this sink accepts both logs and metrics, ensure your pipeline routes only the desired event types into it.

endpoint Defines the URI of the AppSignal API endpoint used for ingestion. In most deployments you should not change this. You would only override it if AppSignal provides an alternate endpoint, if you are using an internal forwarder, or if your environment requires routing through a gateway that exposes a different hostname.

batch.max_bytes The maximum uncompressed size of a batch before it is flushed. This controls memory usage and request payload size. Larger values typically improve throughput efficiency but may increase the impact of a single retry if a batch fails.

batch.max_events The maximum number of events in a single batch before it is flushed. This provides an event-count cap independent of total byte size.

batch.timeout_secs The maximum time Kron TP will hold a batch before sending it, even if it has not reached size or event thresholds. This controls delivery latency. Lower values reduce latency but can increase request rate.

buffer.type Selects whether events are buffered in memory or on disk. Memory buffering is faster but loses data if the process crashes or is restarted. Disk buffering is more durable and survives restarts but requires sufficient disk capacity and is less performant.

buffer.max_size The maximum amount of memory or disk space allocated to the buffer. For disk buffers, Telemetry Pipelines requires a minimum size threshold; ensure the allocated space meets the minimum and that the underlying disk has enough free capacity.

buffer.max_events Limits the number of events in the buffer when using memory buffering. This helps prevent runaway memory usage in bursty conditions.

buffer.when_full Controls what worker does when the buffer is full. The blocking mode applies backpressure upstream, which preserves data but can cause ingestion slowdowns. The drop-newest mode favors throughput and system stability but intentionally loses data during saturation.

compression Controls whether payload compression is used for outbound requests. The default here is gzip. Compression reduces bandwidth consumption and can improve performance over constrained links, but increases CPU usage. In high-throughput environments, you may need to account for CPU overhead when compression is enabled.

encoding.only_fields Restricts the event to only the specified fields before serialization. This is useful for reducing payload size and controlling what data leaves the cluster.

encoding.except_fields Excludes specific fields from being sent. This is commonly used to prevent sensitive fields from leaving the environment (for example credentials, tokens, or internal identifiers).

encoding.timestamp_format Controls how timestamps are represented when serialized. Choose a format compatible with your downstream expectations. RFC3339 is generally the safest for human readability and interoperability.

request.concurrency Controls how many concurrent outbound requests the worker may issue. This can be set to a fixed value or to adaptive mode. Adaptive concurrency dynamically adjusts concurrency based on observed latency and is generally recommended.

request.adaptive_concurrency parameters These tune the adaptive behavior (how quickly concurrency increases/decreases and how sensitive it is to latency changes). In most environments, defaults are appropriate. Mis-tuning can create unstable behavior, such as oscillation between too many and too few requests.

request.rate_limit_num and request.rate_limit_duration_secs Limits the number of requests per time window. This is a protection against API throttling and helps prevent self-inflicted overload during spikes.

request.retry_attempts and retry backoff parameters Controls retry count and timing when requests fail. Retries follow a Fibonacci-style backoff with optional jitter. Jitter is recommended to avoid synchronized retry storms when multiple agents recover at the same time.

request.timeout_secs The maximum time allowed for a request. Setting this too low may increase retry frequency and duplicates; setting it too high can delay recovery when endpoints are truly unavailable.

proxy.enabled Enables proxy handling for outbound connections.

proxy.http and proxy.https Defines proxy endpoints for HTTP and HTTPS traffic. Use these when the environment requires egress via a corporate proxy.

proxy.no_proxy Defines host patterns or CIDRs that should bypass the proxy. Use this to avoid proxying internal or special-case endpoints.

tls.enabled Requires TLS for outbound connections when enabled. Most deployments keep TLS enabled, especially when sending data over the public internet.

tls.ca_file Provides an additional CA bundle when AppSignal endpoints are intercepted or re-signed by corporate TLS inspection, or when using private endpoints with internal certificates.

tls.crt_file and tls.key_file Client certificate authentication settings. Only use if your network path requires mutual TLS.

tls.verify_certificate When enabled, validates the certificate chain. Disabling it is not recommended because it removes protection against MITM attacks.

tls.verify_hostname When enabled, ensures the remote certificate matches the hostname you are connecting to. Disabling it is not recommended for the same reasons.

tls.server_name Overrides the SNI name used during TLS negotiation. This is only needed for advanced routing or when connecting via IP address behind an SNI-based gateway.

Unique key management Treat the push API key as a secret. Rotate it using your secret management practice and validate that old keys are revoked if compromised.

At-least-once duplicates If the endpoint is slow or intermittent and retries occur, duplicates can be produced. Make sure downstream alerting and dashboards tolerate duplicates or deduplicate when possible.

Backpressure vs dropping Blocking when full preserves data but can slow ingestion and make upstream buffers grow. Dropping preserves system responsiveness but loses data under load. Choose based on whether availability or completeness is more important.

Batch sizing trade-offs Larger batches reduce overhead but can increase memory usage and can amplify the impact of a failed request (more events retried). Smaller batches reduce retry blast radius but increase request rate.