Observability metrics (platform monitoring)

OpenCTI exposes operational metrics using the OpenTelemetry standard, which can be exported to various systems such as Prometheus or OTLP collectors. These metrics provide insights into the platform's performance and health, and are intended for your own monitoring infrastructure.

This is NOT anonymous usage telemetry

This page documents the operational metrics you can scrape to monitor your OpenCTI deployment. If you are looking for information about the anonymous product analytics automatically sent to Filigran, see Reference > Usage telemetry.

Configuration

To enable metrics, you need to configure the telemetry section in your platform configuration. See Configuration for details on how to enable and configure exporters.

Available Metrics

The following metrics are exposed by the OpenCTI API.

Metric Name	Type	Description	Unit
`opencti_sent_email`	Counter	Counts the total number of emails sent by the platform.	Count
`opencti_api_requests`	Counter	Counts the total number of API requests received.	Count
`opencti_api_errors`	Counter	Counts the total number of API errors encountered.	Count
`opencti_api_latency`	Histogram	Measures the latency of API query execution.	Milliseconds
`opencti_api_direct_bulk`	Gauge	Measures the size of bulks for direct ingestion (fast path).	Count
`opencti_api_side_bulk`	Gauge	Measures the size of bulks for absorption impacts (worker path).	Count
`opencti_dependency_up`	Gauge	Reports the connectivity state of a platform dependency: `1` when the dependency answers, `0` when it fails.	Boolean
`opencti_elasticsearch_used_size_bytes`	Gauge	Reports the total ElasticSearch/OpenSearch primary store size, replicas excluded.	Bytes
`opencti_storage_used_size_bytes`	Gauge	Reports the total size of the objects stored in the S3/MinIO bucket.	Bytes
`opencti_queue_consumers`	Gauge	Reports the number of active consumers on the push queues, per connector type.	Count

Platform Health Metrics

A background monitor refreshes the health metrics periodically, so scraping them never triggers a request to a dependency. The same collected state answers the /health endpoint, which therefore never probes ElasticSearch, S3, RabbitMQ or Redis per request. Configure both refresh intervals with app:health_monitoring:dependency_check_interval and app:health_monitoring:usage_metrics_interval (see Configuration).

Dependency checks run on every node, so each node reports the connectivity it observes itself. Usage metrics are cluster wide instead: collecting them is expensive (full bucket scan, engine stats), so a dedicated manager (platform_usage_metrics_manager, see Configuration) computes the value once per interval and shares it with the rest of the cluster through Redis; every node then just adopts that shared value on its own polling cycle, which keeps every node reporting the same figure.

A usage metric that cannot be collected is not exported, instead of being exported as 0.

The platform reports raw consumer counts per connector type and does not aggregate them into an ingestion capacity value. Consumers of the metric decide how to combine the types that are relevant to them.

Dependency Metrics Attributes

Applies to: opencti_dependency_up

Attribute	Description	Example
`dependency`	The monitored platform dependency.	`elasticsearch`, `storage`, `rabbitmq`, `redis`

Queue Consumers Metrics Attributes

Applies to: opencti_queue_consumers

Attribute	Description	Example
`connector_type`	The connector type declared on the push queue. Queues without a declared type are reported as `UNKNOWN`.	`EXTERNAL_IMPORT`, `INTERNAL_ENRICHMENT`, `INTERNAL_IMPORT_FILE`, `INTERNAL_EXPORT_FILE`

Metric Attributes

Metrics exported by OpenCTI include various attributes (labels) to provide granular context.

API Metrics Attributes

Applies to: opencti_api_requests, opencti_api_errors, opencti_api_latency

Attribute	Description	Example
`operation`	The GraphQL operation type.	`query`, `mutation`, `subscription`
`name`	The name of the GraphQL operation.	`StixCoreObjectFind`, `Unspecified`
`status`	The outcome of the request.	`SUCCESS`, `ERROR`
`type`	The error type (only present if status is ERROR).	`AUTH_REQUIRED`, `FORBIDDEN_ACCESS`
`user_agent`	The client user agent initiating the request.	`Mozilla/5.0...`, `OpenCTI-Client`

Email Metrics Attributes

Applies to: opencti_sent_email

Attribute	Description	Example
`category`	The functional category of the email.	`hub-registration`, `dissemination`, `password-reset`, `notification`
`identifier`	The ID of the related entity (e.g., user, trigger, list).	`uuid-v4-string`

Bulk Metrics Attributes

Applies to: opencti_api_direct_bulk, opencti_api_side_bulk

Attribute	Description	Example
`type`	The context or source of the indexing operation.	`import`, `connector`

Node.js Runtime Metrics

In addition to the application-specific metrics above, OpenCTI also exposes standard Node.js runtime metrics provided by opentelemetry-node-metrics. These include metrics for:

Process: CPU usage, memory usage, uptime, etc.
Event Loop: Lag, active handles, etc.
GC: Garbage collection duration and counts.
Memory: Heap usage, heap limits, etc.

Common examples include: - process_cpu_user_seconds_total - process_cpu_system_seconds_total - process_resident_memory_bytes - nodejs_eventloop_lag_seconds - nodejs_gc_duration_seconds