> ## Documentation Index
> Fetch the complete documentation index at: https://docs-xcor.paloaltonetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Differences between the Prometheus Operator and Chronosphere Collector

> Compare the Prometheus Operator and Chronosphere Collector for deployment, alerting, service discovery, and long-term storage.

## Summary

| Requirement | Prometheus Operator | Chronosphere Collector |
| - | - | - |
| Deployment | StatefulSets managed by Prometheus Operator | Sidecar, Deployment, or DaemonSet |
| Alerting | AlertManagerConfig, AlertManager, PrometheusRule | Alerts and Monitors |
| High availability and long-term storage | Provided by Thanos | Natively supported |
| Service discovery | Probe, PodMonitor, ServiceMonitors | Annotations, ServiceMonitors, Prometheus Discovery |

## Alerting

Palo Alto Networks Cortex XCOR supports Prometheus alerts, but not
[AlertManagerConfig](https://prometheus.io/docs/alerting/latest/configuration/) or
[AlertManager custom resource definitions (CRDs)](https://prometheus-operator.dev/docs/getting-started/design/#alertmanager).
Cortex XCOR alerting (called *monitors*) has concepts that don't apply to
Prometheus alerting rules, has its own concepts and models, and doesn't support
complex routing trees. For more information, refer to the [monitors
documentation](/investigate/alerts/monitors).

Due to Cortex XCOR being a single data store, you can merge alerts, so an
alert queries all metrics and not only metrics local to a Prometheus instance.

You manage alerting configuration separate of any cluster or Chronosphere Collector
configuration with Cortex XCOR, [Chronoctl](/tooling/chronoctl), or
[Terraform](/tooling/infrastructure/terraform). This approach brings more
flexibility for managing configuration and means you can spread configuration
responsibility between teams.

## Scaling

### Thanos support

Cortex XCOR is a scalable backend for Prometheus and doesn't require
[Thanos](https://thanos.io) or the
[ThanosRuler CRD](https://prometheus-operator.dev/docs/getting-started/design/#thanosruler).

### Sharding across instances

The Prometheus Operator supports automatically sharding ServiceMonitors across
multiple Prometheus instances. However, you still need to setup a remote write
destination such as Thanos, or a single large instance.

The Collector handles scale by using a DaemonSet and scoping each instance of the
Collector to a particular node. Using a DaemonSet is the recommended way to deploy
the Collector, but there are other methods available you can read about in the
[Collector documentation](/ingest/metrics-traces/collector/install/kubernetes).

There are advantages and disadvantages to deploying the Collector as a DaemonSet:

* **Advantages**:
  * Using a DaemonSet means you don't need large or powerful instances to run the
    Collector.
  * The DaemonSet implementation reduces any impact of a single Collector instance
    experiencing issues.
* **Disadvantages**:
  * All instances created with a DaemonSet must have uniform resources.

## Configure Prometheus

Prometheus Operator has a
[Prometheus CRD](https://prometheus-operator.dev/docs/getting-started/design/#prometheus)
for configuring global settings on the instances it creates. Cortex XCOR
supports many of these settings, but instead you set them in Collector configuration.
For more information, visit the
[configuration documentation](/ingest/metrics-traces/collector/configure).

Some Prometheus Operator settings that don't transfer to the context of the Collector,
such as `volumeMounts` and `priorityClass`.

The Collector doesn't support the following fields from the ServiceMonitor CRD:

* `targetLabels`
* `podTargetLabels`

Instead, use [Prometheus `relabel_config`](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config)
which allows advanced modifications to any target and its labels before ingesting the
metrics.

## Service discovery

### Static scrape targets

To replicate the capabilities of the
[Prometheus Operator Probe CRD](https://prometheus-operator.dev/docs/getting-started/design/#probe),
Cortex XCOR recommends running a single instance of the Collector as a sidecar (if
possible), or a one instance Deployment. If you run the Collector as a DaemonSet, all
instances of the Collector attempt to scrape the same targets, resulting in multiple
copies of the same metrics. For more information about available options, refer to
the [Collector documentation](/ingest/metrics-traces/collector/install/kubernetes#install-the-collector).


## Related topics

- [Scrape configuration using Kubernetes](/ingest/metrics-traces/collector/discover/scrape-configuration.md)
- [Querying DogStatsD formatted metrics](/ingest/metrics-traces/collector/mappings/datadog/dogstatsd.md)
- [Derived telemetry](/investigate/querying/metrics/derived-telemetry.md)
- [Chronosphere Collector optimizations](/ingest/metrics-traces/collector/configure/optimizations.md)
- [Configure Chronosphere Collector service discovery for Prometheus metrics](/ingest/metrics-traces/collector/discover.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.