> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/connectors/count.md).

# Count

Counts the telemetry events passing through a pipeline and emits the totals as metrics. It bridges pipelines: it consumes logs, metric data points, and spans from the source pipeline and feeds count metrics into the destination pipeline. Leave it with defaults to emit the connector's built-in counts, or define custom count metrics scoped to specific signal types.

### Supported Telemetry Types

| Input                 | Output  |
| --------------------- | ------- |
| Logs, Metrics, Traces | Metrics |

The connector consumes the selected signal types and emits count metrics, so the output is always Metrics regardless of which input signals you count.

### Configuration

#### Basic Configuration

<figure><img src="/files/40WJwC4g3N7Ntnf9OQU4" alt="Bindplane docs - Count - image 1"><figcaption></figcaption></figure>

| Parameter              | Type               | Required | Default               | Description                                                                                                                                                                                                                                                                        |
| ---------------------- | ------------------ | -------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Choose Telemetry Types | Telemetry Selector | Yes      | Logs, Metrics, Traces | Which telemetry types this connector counts.                                                                                                                                                                                                                                       |
| Custom Counts          | Count Metrics      | No       | *(empty)*             | Define custom count metrics. Leave empty to emit the connector's default counts (`log.record.count`, `metric.count`, `metric.datapoint.count`, `trace.span.count`, `trace.span.event.count`). Defining a custom count for a signal type suppresses that signal's default emission. |

**Default metrics**

With Custom Counts left empty, the connector emits these metrics per selected telemetry type:

| Telemetry Type | Metrics Emitted                              |
| -------------- | -------------------------------------------- |
| Logs           | `log.record.count`                           |
| Metrics        | `metric.count`, `metric.datapoint.count`     |
| Traces         | `trace.span.count`, `trace.span.event.count` |

### Examples

#### Count log records and spans with defaults

Count all log records and trace spans passing through the pipeline using the built-in metrics. Set Choose Telemetry Types to `Logs` and `Traces`, and leave Custom Counts empty.

```yaml
- name: telemetry_types
  value:
    - Logs
    - Traces
```

This emits `log.record.count`, `trace.span.count`, and `trace.span.event.count` as sum metrics.

### Configuration Tips

* Leave Custom Counts empty to get the default counts. You only need custom counts when you want to scope a count by a condition or group it by attributes.
* A custom count's `signalType` (`logs`, `datapoints`, `spans`, `spanevents`) only takes effect if the matching telemetry type is selected in Choose Telemetry Types.
* Defining any custom count for a signal type replaces that signal's default count, so re-declare the default metric if you still want it alongside a new one.

### Troubleshooting

#### No count metrics appear in the destination

Symptoms: the pipeline produces no `*.count` metrics after adding the connector.

Solutions:

1. Confirm the signal type you expect to count is selected in Choose Telemetry Types.
2. Verify the source pipeline is actually carrying that signal type to the connector.

#### A signal's default count stopped emitting

Symptoms: a default metric (for example `log.record.count`) disappeared after you added a custom count.

Solutions:

1. A custom count for a signal type suppresses that signal's default. Re-add the default metric explicitly under Custom Counts if you still need it.

### Standalone Connector

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Connector
metadata:
  name: count
spec:
  type: count
  parameters:
    - name: telemetry_types
      value:
        - Logs
        - Metrics
        - Traces
    - name: metrics
      value: []
```

### Related Resources

* [Count Connector — OpenTelemetry reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/connector/countconnector/README.md)

### Bindplane Resources

* [Signal to Metrics](/integrations/connectors/signal-to-metrics.md) — for filtered or attribute-grouped counting with OTTL expressions
* [Routing](/integrations/connectors/routing.md) — route counted signals to different downstream pipelines


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/connectors/count.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
