Before learning the tool, understand the question it answers.

Every running application does things over and over: it serves web pages, processes payments, reads from databases, sends emails and retries failed work. The people who run these applications constantly ask simple questions. How many orders did we process today? How many requests failed in the last hour? How many emails were sent? Is the number of errors growing? Are we getting busier than last week?

All of these are counting questions. Answering them by reading log files would be slow and costly, because someone would have to search millions of lines and count by hand. A much better approach is to have the application keep a small running tally for each thing worth counting and to report that tally regularly. That tally is what we call a metric, and the simplest kind of metric tally is the Counter.

A short refresher on the surrounding vocabulary makes everything easier.

OpenTelemetry, often called OTel, is an open-source project that defines how software describes its own behavior. It is vendor neutral, which means it does not belong to any one monitoring company. It describes three kinds of data, called signals: traces, metrics and logs. This guide lives in the world of metrics, which are numbers measured over time.

A Counter is a synchronous instrument that records values which only ever increase.

Let us define it carefully. A Counter in OpenTelemetry is a metric instrument used to record a value that accumulates over time and can only go up. You use it by calling an add operation each time something happens, and each call adds a non-negative amount to the running total. Most of the time you add exactly one, such as one more request served. Sometimes you add a bigger number, such as the number of bytes in a response.

The two most important properties are the word monotonic and the word synchronous. Monotonic means the value never decreases. Synchronous means that your own code calls the instrument right at the moment the event happens, as part of the normal flow of work. We will look closely at both ideas.

The one-way nature of a Counter is not a limitation. It is the whole point.

You might wonder why a Counter refuses to go down. Surely it would be more flexible to allow both directions. The answer is that the one-way promise makes the data far easier to understand and far more reliable when it travels through many systems.

When a value only increases, any tool reading it can make safe assumptions. If the reading today is bigger than the reading yesterday, the difference is exactly the number of events in between. If a reading ever appears smaller than the previous one, the tool knows something special happened, usually that the application restarted and began counting from zero again. Tools can then adjust for the reset instead of drawing a false drop on the chart.

What if I try to add a negative number?

The specification says a Counter should only accept non-negative values. If code tries to add a negative number, the library is expected to ignore it, and it may log a warning. This protects the promise that the total never goes down.

What if I need a number that goes up and down?

Then a Counter is the wrong tool. For things like the number of people currently in a queue, which rise and fall, OpenTelemetry offers a different instrument called the UpDownCounter. We compare them in a later chapter.

OpenTelemetry offers two ways to feed a Counter, depending on who does the counting.

The regular Counter is synchronous. Your code is in charge. Whenever the event happens, your code calls add. This is the natural choice for events your application itself performs, such as handling a request or processing an order.

The second style is the asynchronous Counter, also called an observable Counter. Here, you do not call add on every event. Instead, you register a small function called a callback. Every time the library is about to collect metrics, it calls your function, and your function simply reports the current total. This is useful when the total already lives somewhere else and you merely want to read it, for example a total kept by the operating system, such as the number of bytes a network card has sent since boot.

Good Counters answer questions people actually ask.

A Counter fits anything where you care about the total number of occurrences. The key test is simple: does it only make sense to ask how many so far, and would the number never need to shrink? If yes, it is probably a Counter.

Knowing the limits prevents the most common beginner mistakes.

Counters are wonderful, but they are not a universal tool. Picking the wrong instrument gives you confusing charts. Here are things that look like Counter candidates but are not.

A side-by-side comparison makes the right choice obvious.

OpenTelemetry offers several instruments, each designed for a different shape of question. The easiest way to choose is to ask what the number does over time and what question you want to answer.

flowchart TD
  Q1{"Does the value only ever grow?"}
  Q1 -->|"Yes, and I want a total of events"| C["Counter"]
  Q1 -->|"No, it rises and falls by steps"| U["UpDownCounter"]
  Q1 -->|"No, it is a reading at a moment"| G["Gauge"]
  Q1 -->|"I care about the spread of values"| H["Histogram"]
        

A good Counter introduces itself clearly so that strangers can understand it.

When you create a Counter, you give it a few pieces of descriptive information. These matter more than beginners expect, because the person reading a chart six months later will not remember what you meant.

Naming habits that help

Use lowercase words separated by dots to build a clear hierarchy, from general to specific. Do not stuff units or the word total into the name when the unit field already says it, since many backends add such suffixes automatically. Keep names stable, because renaming a Counter breaks charts and alerts that depend on the old name. Follow the OpenTelemetry semantic conventions whenever one exists for what you are counting, so that your numbers line up with those of other teams and tools.

Attributes are labels that let a single Counter answer many questions.

Counting all requests together is useful, but usually not enough. You also want to know how many requests were successful versus failed, how many came to each route, or how many came from each region. Instead of creating a separate Counter for every combination, you attach attributes to each addition. An attribute is a small key and value pair, such as the status of the response or the route that was called.

Behind the scenes, OpenTelemetry keeps a separate running total for every unique combination of attribute values. Each one is called a time series. A backend can then show the total of everything, or break it down by any attribute you recorded.

flowchart LR
  A["Counter: http.server.requests"] --> B["Series: route is checkout, status is 200"]
  A --> C["Series: route is checkout, status is 500"]
  A --> D["Series: route is search, status is 200"]
  A --> E["Series: route is search, status is 404"]
        

A good attribute is small and stable

The best attributes have a small, known set of possible values, such as the HTTP method, the status class, the region or the name of a route pattern. These give tidy, readable breakdowns and cost little to store.

The most expensive mistake with Counters is adding labels that have too many possible values.

Because every unique attribute combination creates a new series, the number of series can explode if you choose attributes carelessly. This number of possible combinations is called cardinality. High cardinality means huge memory use in your application, large bills at your monitoring vendor, and slow dashboards.

Suppose you add the customer’s user identifier as an attribute to a request Counter. If you have one million users, you may create a million separate series for one Counter. If you add a request identifier, which is different every single time, you create a brand-new series for every event, and the Counter stops being a summary and becomes a very expensive log.

Let us follow a single increment from your code all the way to a dashboard.

Understanding the journey helps you reason about delays, resets and missing data. Here is what happens when an application serves a request and counts it.

sequenceDiagram
  participant App as Application Code
  participant SDK as SDK Aggregator
  participant R as Metric Reader
  participant E as Exporter
  participant B as Backend
  App->>SDK: Add 1 with attributes
  App->>SDK: Add 1 with attributes
  App->>SDK: Add 1 with attributes
  Note over SDK: Running sum grows in memory
  R->>SDK: Collect on timer
  SDK-->>R: Current sums
  R->>E: Hand over snapshot
  E->>B: Send metrics
        

The raw additions are folded into a summary called a sum.

OpenTelemetry separates the act of recording from the way recorded values are summarized. The act of recording is what your code does with the Counter. The summary is called the aggregation. For a Counter, the default aggregation is a Sum, and because the Counter never decreases, that sum is marked as monotonic. This marker tells backends they may safely compute rates.

Why not send every single addition? Because that would be as heavy as logging every event. By summing inside the application, the system trades individual detail for low cost and high speed, which is exactly the right trade for a metric.

There are two ways to report a growing total, and backends have preferences.

When the Counter’s sum is sent out, it can be described in one of two styles, called temporality. This single concept causes a lot of confusion, but the analogy of a car makes it easy.

Which should I choose?

The choice usually depends on the backend. Systems built around scraping and computing rates from growing totals prefer cumulative. Some systems prefer delta because it uses less memory in the application and is naturally robust when a program restarts. OpenTelemetry lets the metric exporter choose the temporality, and the Collector can convert between the two in many cases.

The total on its own is rarely what you chart. The rate is.

A cumulative Counter that says three million requests so far is hard to interpret. Is that a lot? Is it growing? What people really want is the rate: how many requests per second are happening now. Backends compute this by taking two readings, subtracting, and dividing by the elapsed time. That is why the monotonic promise is so valuable.

What happens when the program restarts?

When an application restarts, its in-memory Counter begins again from zero. A naive chart would show a sudden crash to zero. Because the Counter is known to be monotonic, tools detect any drop as a reset and treat the post-restart value as growth from zero. OpenTelemetry also records the start time of each series, which helps backends recognize resets precisely.

flowchart LR
  A["Reading at 10:00 is 1000"] --> B["Reading at 10:01 is 1060"]
  B --> C["Restart at 10:01:30"]
  C --> D["Reading at 10:02 is 40"]
  D --> E["Tool detects the drop as a reset and still computes a sensible rate"]
        

Views let operators adjust how a Counter is reported, with no code edits.

Sometimes the people who run the application want to change how a metric is reported without asking developers to modify and redeploy code. OpenTelemetry provides views for this purpose. A view is a rule, set up in the SDK configuration, that selects one or more instruments and changes how they are aggregated or presented.

Counters work best when they cooperate with traces and logs.

Metrics are the early warning system. They are cheap, fast and great for spotting that something changed. But a Counter tells you only that errors increased, not which request failed or why. For that you need traces and logs. A healthy workflow uses all three together.

The real payoff of counting comes when people and tools act on the numbers.

Counters are the raw material for many of the most important charts and alerts in operations. Because they are cheap and precise, teams build their basic health picture on them.

A short checklist that saves hours of confusion later.

Every design choice has a price, and Counters are no exception.

Balancing detail and cost

Every attribute you add increases the detail you can see, and also the cost you must pay. A Counter with no attributes is nearly free but answers only one question. A Counter with a handful of well-chosen attributes answers many questions at modest cost. A Counter with unbounded attributes answers everything and bankrupts your monitoring budget. The craft lies in choosing the middle path.

Seeing how teams use Counters makes the ideas concrete.

It is a metric instrument that records a running total of how many times something has happened, and that can only ever increase.

Not while the program is running. Negative additions are ignored. A Counter can appear to drop only when the program restarts and begins again from zero, and tools handle that as a reset.

It means the value never decreases. It may stay the same or grow, but it never shrinks.

Use it when the quantity rises and falls by steps, such as items waiting in a queue or connections currently open.

A Counter accumulates events and only grows. A Gauge reports a current reading, such as temperature, which may go up or down freely.

No. Use a Histogram, which keeps the distribution of values. A Counter of total time hides whether most requests are fast and a few are very slow.

It is a Counter whose total is reported through a callback at collection time, used when another system already keeps the running total and you simply read it.

Attributes are labels that split a Counter into separate series. They are risky when they have many possible values, because each unique combination creates a new series and raises memory use and cost.

You are probably charting the raw cumulative total. Chart the rate or the increase over a time window instead, which shows how fast events are happening.

Cumulative reports the total since the start, like a car odometer. Delta reports only the change since the last report, like a resettable trip meter.

On the metric reader’s interval, commonly about once a minute by default. Many additions are folded into one number per series between exports.

Very little. Each addition is a tiny in-memory operation. The heavy work of exporting happens rarely and off the main path.

Yes. Views in the SDK configuration can rename, drop or reshape Counters and remove unwanted attributes.

We began with the odometer in a car, a number that only climbs and that tells its story when you compare two readings. A Counter in OpenTelemetry is exactly that: a simple, cheap, one-way instrument for counting events such as requests, errors, orders and bytes. Your code adds to it, the SDK folds the additions into a running sum, a reader exports the sum on a schedule, and the backend turns it into rates, charts and alerts. Choose its attributes with care, pick the right instrument when a value can go down or needs a distribution, and the humble Counter will quietly carry a large share of your daily observability work.