Skip to main content

Tlscheck Receiver

Status Available in: contrib Maintainers: @atoulme, @michael-burt Source: opentelemetry-collector-contrib

Supported Telemetry

Metrics

Overview

Getting Started

By default, the TLS Check Receiver will emit a single metric, tlscheck.time_left, per target. This is measured in seconds until the date and time specified in the NotAfter field of the x.509 certificate. After certificate expiration, the metric value will be a negative integer measuring the time in seconds since expiry.

Example Configuration

Note: This receiver was renamed from tlscheck to tls_check to match the snake_case naming convention. The deprecated component type tlscheck is still accepted as an alias and will log a deprecation warning.
Targets are configured as a remote endpoint accessed via TCP, a PEM-encoded certificate file stored locally on disk, or a Java-format keystore file (JKS or PKCS#12).

Configuration Fields

JKS Keystores

JKS files may contain multiple aliases. One tlscheck.time_left metric is emitted per leaf certificate found:
  • TrustedCertificateEntry — the single certificate stored in the entry is used.
  • PrivateKeyEntry — the first certificate in the chain (the leaf) is used.

Certificate Verification

This component does not provide hostname, validity period, path, or CRL / OCSP verification on the certificate.

Certificate File Validation

If a certificate file specified in the configuration does not exist or is unable to be opened, an error will be logged on each scrape cycle and the otelcol_scraper_errored_metric_points metric will be incremented. If you would like to monitor for the existence of specific certificate files on disk, consider using the File Stats receiver.

Metrics

Details about the metrics produced by this receiver can be found in metadata.yaml.

Metrics

Attributes

Resource Attributes


Last generated: 2026-08-24