The short answer first, then the words that make it clear.

A View in OpenTelemetry is a rule, registered inside your program, that says: “For measurements that match this description, change how they are summarised and sent.” A view can rename a measurement, change its description, keep only some of its labels, switch it to a different way of summarising, or turn it off entirely. It does all this inside the program, before any data travels over the network.

Let us unpack the vocabulary. OpenTelemetry, often shortened to OTel, is a free, open source framework, hosted by the Cloud Native Computing Foundation, that gives developers one standard way to produce telemetry: the stream of traces, metrics, and logs that describes how software behaves. A metric is a number measured over time, such as “requests per second” or “memory in use.” Code creates metrics through instruments. An instrument is a small object, such as a counter or a histogram, that your code calls each time something worth measuring happens. Each call is a measurement.

Between the moment your code records a measurement and the moment a number leaves your program, something must summarise the measurements. Imagine one million requests in a minute: nobody wants one million separate numbers on the wire. The summarising step is called aggregation. It adds counts together, remembers the latest value, or sorts durations into groups. A view is the rule that controls which aggregation is used, and how the result is labelled and named.

What a view answers

• Which measurements? A view chooses its targets by name, type, unit, or the library that created them.
• What name should it have? A view can give the outgoing metric a clearer or standard name.
• Which labels matter? A view can keep only the labels you care about and discard the rest.
• How should it be summarised? A view can switch a histogram’s group boundaries, or choose a different kind of aggregation.
• Should it be sent at all? A view can switch a noisy metric off completely.

What a view is not

A view is not a new metric. It does not invent measurements that your code never recorded. It is also not a query: it cannot ask questions of data that has already left. And it is not part of the instrumented library. Library authors write the measurements; the application owner writes the views. That separation is the whole point, because the person running the program usually knows better than the library author what is useful and what is wasteful.

A Closer Look at the Word “View”

Database people will recognise the word. A database view is a saved lens over a table: you do not change the table, but you look at it through a filter, with renamed columns and some rows or columns hidden. An OpenTelemetry view works the same way. The raw measurements stay as the instruments recorded them. The view is a lens that shapes how those measurements are presented to the outside world.

This lens idea explains a rule you will meet again and again: a view affects what is exported, not what your code records. Your code still calls the instrument in exactly the same way. The savings happen afterward, in the summarising step, which is why views can cut costs without any change to the program’s business logic.

Why Beginners Find Views Confusing at First

Newcomers often expect that the code which records a measurement is also the code that decides how it is reported. In many older tools that was true, and so a change in reporting meant a change in code. OpenTelemetry deliberately separates the two. The code that records measurements belongs to the library author, and the code that decides reporting belongs to the person who runs the program. The view is the bridge between these two worlds.

Once this separation is clear, many other details fall into place. It explains why views are registered on the provider and not on instruments, why they cannot change values, and why they can safely be applied to libraries you did not write. Keep this picture of two worlds and one bridge in mind as you read the rest of the guide.

One-size-fits-all defaults are a good start and a poor finish.

When people share instrumented libraries, a web framework or a database driver for example, the library author must choose names, labels, and summarising styles without knowing who will use the library. The author imagines a typical user, and the defaults reflect that guess. But your program is not typical. Your latencies might be much faster or slower. Your traffic might carry labels the author never imagined. Your monitoring tool might expect different names.

Without views, you would have only two bad choices. You could change the library, which is not yours to change, or you could live with the defaults and fix everything later in the backend, after paying to send and store the unwanted data. Views give you a third, much better choice: adjust the output at the source, in your own program’s startup settings, leaving the library untouched.

A short history

The Cost of Doing Nothing

Teams that never use views often discover the cost slowly. At first, one service sends a hundred series and nobody worries. Then the team adopts a new library with twenty metrics, then a second service, then a third, and the series count climbs quietly. A year later, the monitoring bill is one of the largest line items in the budget, and no single decision caused it. Views let a team put a brake on this slow growth, by agreeing early on what each service is allowed to send.

There is also a human cost. Dashboards crowded with unused metrics are harder to read, and engineers waste time searching for the few lines that matter. A tidy set of metrics, shaped by views, is not only cheaper but easier to understand during an emergency, when every minute counts.

Eight small ideas hold up the whole topic. Learn these and the rest will feel natural.

How the ideas fit together

Here is the whole story in one breath. Your code calls an instrument and records a measurement with some attributes. The meter provider checks its list of views to see which ones match the instrument. For each matching view, or for a default if none match, it creates a metric stream. Measurements flow into the stream, where the aggregation boils them down. On a timer, the reader collects the finished streams, and the exporter sends them out.

The stream is the unit of everything

Beginners often picture one instrument producing one metric. In fact, one instrument can produce several streams, one for each view that matches it, or one default stream if no view matches. This is why views can be used to send the same measurement to two destinations in two different shapes. It is also why careless views can accidentally create duplicate names, which we will study in a later chapter.

Why Attributes and Aggregation Interact

It is worth understanding one connection before moving on. Aggregation happens per combination of attributes. A counter with three label values keeps three separate running totals, one for each combination. When a view removes a label, the combinations that differed only by that label collapse into one, and their totals are added. This is why removing a label is so effective at reducing cost: it does not merely hide information, it reduces the number of running totals the program must keep in memory.

This connection also explains why a view that filters labels saves memory inside the application, not only storage in the backend. Fewer combinations mean fewer objects, less work at each measurement, and smaller exports, so the benefit is felt at every step along the path.

Every view has two halves: a way to find its targets, and a description of what to do to them.

A view is like a work order at a repair shop. The top half says which vehicles the order applies to. The bottom half says what to do to each of them. In OpenTelemetry the top half is called the selection criteria and the bottom half is called the stream configuration.

The selection criteria

The criteria decide which instruments the view applies to. You can use one criterion or several together. When you give several, an instrument must satisfy all of them to match.

The wildcard deserves a moment. A single star in a name criterion matches everything, and a star inside a pattern matches any run of characters. A view with only a star as its name criterion therefore applies to every instrument in the program. This is a powerful tool for company-wide rules, and also a dangerous one if used carelessly.

The stream configuration

The configuration says what the resulting stream should look like. Every field is optional. Anything you leave out keeps its default, which comes from the instrument itself.

Two things views deliberately cannot change

First, a view cannot change the kind of instrument. A counter stays a counter. The rules about what a counter means, that it only goes up, are fixed by the instrument, and no view can override them. Second, a view cannot change the unit or the value of the measurements. It changes how they are grouped and labelled, not what they say. If you need to convert milliseconds to seconds, you must fix the instrumentation or do the conversion later in a Collector.

Reading a View Aloud

A good way to check a view is to read it aloud as a sentence. For example: “For every histogram created by the web framework library, keep only the route, method, and status labels, and use these bucket boundaries.” If the sentence sounds natural and describes exactly what you intend, the view is probably right. If it sounds vague, such as “for everything, remove some labels,” the view is probably too broad, and you should tighten the criteria before shipping it.

This habit also helps when reviewing a colleague’s work. A reviewer who can read the view as a plain sentence can quickly spot a wildcard that is too greedy or a rename that will surprise someone downstream.

Before you change anything, you should know what already happens when you change nothing.

If you register no views at all, the SDK still produces a stream for every instrument, using a standard default aggregation for each kind. This is why metrics appear in your backend even when nobody has configured anything. Knowing these defaults helps you decide when they are good enough and when they need a view.

The default histogram buckets

A histogram sorts measurements into buckets, which are numeric ranges. The default explicit histogram uses a fixed list of boundaries: 0, 5, 10, 25, 50, 75, 100, 250, 500, 750, 1,000, 2,500, 5,000, 7,500, and 10,000. That gives sixteen buckets, from “zero to five” up to “over ten thousand.” These numbers were chosen with milliseconds in mind, as a general-purpose spread.

Here lies one of the most common reasons to write a view. If your instrument records durations in seconds, a typical request of 0.2 seconds, 0.35 seconds, or 1.2 seconds all fall into the very first bucket, “zero to five,” or the second, “five to ten.” The histogram becomes a single useless lump, and every percentile you compute from it will be wrong. A view that supplies better boundaries fixes this immediately, without touching the code.

The default cardinality limit

The SDK also protects you with a default cap. By default, each metric stream may hold up to 2,000 distinct label combinations. When a stream reaches its limit, further new combinations are not stored one by one. Instead they are merged into a single special series that carries an overflow marker. This stops a runaway label from consuming memory without limit, but it also means that data beyond the cap is lumped together and loses its detail. We will return to this safety net in the chapter on cardinality.

Gauges, Sums, and the Meaning of “Current”

The defaults reflect what each kind of instrument means. A counter measures how many things have happened, so adding is natural. A gauge measures a level at a moment, such as the temperature, so adding two readings would be nonsense, and the most recent reading is the sensible summary. An up-down counter measures changes in a level, such as items added to or removed from a queue, so adding all changes yields the current size.

When you later choose a different aggregation in a view, keep these meanings in mind. A view should refine how the quantity is reported, not contradict what the quantity is. If you find yourself wanting to sum a gauge, the better question is usually whether the right kind of instrument was created in the first place.

An aggregation is a recipe for boiling many numbers into few. A view lets you pick the recipe.

flowchart LR
    A["Application code calls an instrument"] --> B["Measurement with attributes"]
    B --> C{"Meter provider checks its views"}
    C -->|"Matching view found"| D["Metric stream shaped by the view"]
    C -->|"No view matches"| E["Default stream for that instrument kind"]
    D --> F["Aggregation boils measurements down"]
    E --> F
    F --> G["Reader collects on a schedule"]
    G --> H["Exporter sends the result onward"]

Explaining Figure 1

Read the diagram from left to right. Your code calls an instrument, which creates a measurement with its labels. The meter provider then asks one question: does any registered view match this instrument? If yes, a stream is shaped by that view. If no, a default stream is created. Either way, the stream’s aggregation boils the many measurements into a few numbers. A reader collects the results on a timer, and an exporter ships them out. The view acts at a single point only, the moment the stream is defined, which explains why it is so cheap to apply.

The aggregations you can choose

Explicit versus exponential histograms

An explicit histogram uses boundaries that you write down in advance. It is easy to understand and works everywhere, but you must guess the right boundaries. If your latencies change over time, the boundaries may stop fitting. An exponential histogram generates its boxes by a formula, making each one a fixed percentage wider than the previous one. It covers a huge range with only a limited number of boxes, resizes itself as values appear, and usually gives better accuracy at low cost. The catch is that not every backend understands exponential histograms yet, so you should check your destination before switching.

Drop: the quiet hero

The Drop aggregation deserves special praise. A library might create twenty metrics when you only care about three. With a view that matches the unwanted ones and applies Drop, those seventeen metrics produce no data, no network traffic, and no storage cost. The measurements still arrive at the instruments, but they are discarded at once, which is nearly free.

Choosing an Aggregation in Practice

A simple decision path works for most cases. If the instrument counts events, use Sum. If it reports a level, use Last value. If it records durations or sizes and you know the typical range, use an explicit histogram with boundaries that fit. If you do not know the range, or it varies a great deal, consider an exponential histogram, after confirming that your backend can read it. If you do not need the metric at all, use Drop. When unsure, leave the default and look at real output before changing anything.

Remember that each choice has a cost. Histograms are the most expensive aggregation, because each series holds a count for every bucket plus extra totals. Applying a histogram to something that only needed a count wastes memory and storage, so choose the lightest aggregation that still answers your question.

A Note on Memory and Speed

Each aggregation keeps a small amount of state for every combination of labels. A sum keeps one number, a last value keeps one number, and a histogram keeps a number for every bucket, plus a total and a count. Because this state lives in the application’s memory, a careless choice can make a busy program heavier. Choosing lightweight aggregations for simple questions and limiting label combinations keeps the monitoring cost of a program far smaller than the work it does for customers.

The single most valuable thing a view does is decide which labels are worth their cost.

Every metric can carry labels, called attributes. A request counter might carry the route, the method, and the status code. Each different combination of label values becomes its own series, its own line on a chart, and its own row in storage. Cardinality is the count of those combinations. It is the number that decides how much a metric costs.

The arithmetic is multiplication, which grows frighteningly fast. Imagine a request counter with four labels: route with 20 values, method with 4, status code with 6, and customer identifier with 5,000. The number of possible series is 20 × 4 × 6 × 5,000 = 2,400,000. If you remove the customer identifier, the count falls to 20 × 4 × 6 = 480. One label was responsible for more than 99.9 percent of the series.

flowchart TD
    A["Raw measurements with route, method, status, and customer"] --> B["Millions of possible label combinations"]
    B --> C{"View keeps only route, method, and status"}
    C --> D["Customer label removed"]
    D --> E["Measurements that differ only by customer are merged"]
    E --> F["Only 480 series remain"]
    B -.->|"No view and no limit"| G["Memory and cost grow without bound"]

Explaining Figure 2

The diagram begins with raw measurements that carry four labels. Left alone, they produce millions of combinations, shown on the dotted path where memory and cost grow without bound. A view that keeps only three labels removes the customer label from each measurement. Measurements that used to differ only by customer now look identical, so they are merged: counts are added together, and histogram buckets are added bucket by bucket. The result is a few hundred tidy series that still answer the questions people actually ask.

What happens to the numbers when labels are removed

Removing a label does not delete information about how much happened. It only removes the ability to split by that label. For a counter, the merged series simply holds the sum of the series that were combined, so the total count of requests is unchanged. For a histogram, the buckets are added together, so overall percentiles remain meaningful. For a gauge, however, merging is trickier: the last value from one of several merged sources wins, and the result may not mean what you expect. Be careful when filtering labels from gauges.

Allow-lists and block-lists

There are two ways to describe which labels survive. An allow-list names the labels to keep, and everything else is removed. A block-list names the labels to remove, and everything else stays. The allow-list is safer for protecting costs, because a new label added by a future library upgrade is removed automatically until you decide it is worth keeping. The block-list is friendlier when you just want to remove one troublesome label and keep the rest. Check which styles your language’s SDK supports, as the options differ.

The safety net: the cardinality limit

Even with careful views, a surprise can arrive. A bug might put a unique number into a label, and suddenly a metric produces a new series for every request. To prevent memory from exploding, the SDK enforces a limit on how many distinct label combinations one stream may hold, by default 2,000. When the limit is reached, new combinations are no longer tracked individually. Their measurements are added to a single overflow series, marked with a special label that says it is the overflow.

That overflow series is both a rescue and a warning. It rescues your memory and your bill. It warns you, because when it appears, your detailed data has begun to merge into a lump. A view can raise or lower the limit for a particular stream, which is useful when a legitimate metric genuinely needs more combinations, or when a fragile one needs a tighter cap.

Estimating Cardinality Before You Ship

You can predict cardinality with a pencil and paper. List the labels of a metric and, beside each, write the number of distinct values it can take. Multiply them. If the result is in the hundreds, you are safe. If it is in the thousands, think carefully. If it is in the hundreds of thousands or more, change the design before shipping. Remember to multiply again by the number of running copies of your program if the backend stores each copy separately.

It also helps to ask of every label: “Is the set of values bounded and small?” Status codes, HTTP methods, and route templates are bounded. User identifiers, timestamps, session codes, and raw URLs are not. Unbounded labels are the usual cause of cardinality disasters, and a quick check at review time catches most of them.

A histogram is only as good as its boxes. A view lets you build better ones.

Histograms answer questions such as “How slow are the slowest ten percent of requests?” They do this by counting how many measurements fall into each bucket. The backend then estimates percentiles by looking at those counts. If most measurements land in one bucket, the estimate is poor, because inside a bucket the backend can only guess.

Let us make this concrete. Suppose a service records request durations in seconds, and almost every request lasts between 0.02 and 0.8 seconds. With the default boundaries, which start at 0, 5, 10, and 25, every one of these measurements falls into the first bucket, “zero to five.” The histogram holds one big count and fifteen empty buckets. Any computed 99th percentile will be a meaningless number somewhere inside that first box.

Rules for good boundaries

• Put boundaries where decisions live. If your promise to customers is “under 0.5 seconds,” make sure 0.5 is a boundary, so you can count exactly how many met the promise.
• Use finer steps near the typical value. The busiest region of the range deserves the most boundaries.
• Leave room above the worst case. The last bucket collects everything beyond the final boundary, so make that boundary comfortably high.
• Do not use too many. Every boundary multiplies the data for every label combination. Ten to twenty boundaries are usually plenty.
• Keep them the same across services. If different services use different boundaries for the same kind of metric, combining them later becomes awkward.

sequenceDiagram
    participant S as Startup code
    participant P as Meter provider
    participant L as Library code
    participant R as Reader and exporter
    S->>P: Register views, then create the provider
    L->>P: Create an instrument named request duration
    P->>P: Match the instrument against the views
    Note over P: Matching view supplies better bucket boundaries
    L->>P: Record measurements all day
    R->>P: Collect on a timer
    P-->>R: Streams with the chosen buckets
    R->>R: Export onward

Explaining Figure 3

The diagram shows the lifetime of a view. At startup, your configuration code registers the views and creates the meter provider. Later, a library creates an instrument. At that exact moment, the provider matches the instrument against the views and fixes the stream’s settings, such as the bucket boundaries. From then on, every measurement flows into that stream. When the reader’s timer fires, the provider hands over the finished streams, and the exporter sends them out. Because the choice is made at creation, views must be registered before instruments appear.

Comparing Percentile Accuracy

Percentile accuracy depends on how narrow the bucket containing the percentile is. Suppose the true 95th percentile of your requests is 0.42 seconds. With boundaries at 0.25 and 0.5, the backend knows only that the answer lies somewhere between those two numbers, and it will usually report an estimate near the middle or edge. If you add a boundary at 0.4, the estimate improves, because the range is narrower. The more boundaries you place near the values you care about, the more precise your percentiles become.

This is why you should place boundaries at the numbers that matter to the business, such as a promised response time. A bucket edge exactly at the promise lets you count, without any estimation, how many requests met or missed it.

A view can change a metric’s name, but names carry promises, so change them with care.

A view can give the outgoing stream a new name and a new description. This is helpful when a library uses an unusual name and your company uses a standard one, or when two teams call the same idea by different names. But a metric’s name is also its identity: every dashboard, alert, and report that mentions it depends on that name staying put. Renaming a metric through a view will make old charts go blank, so plan the change together with the people who use the data.

Renaming rules to remember

• A name needs a single target. If you set a new name, the view should match exactly one instrument. A wildcard that matches many instruments, all renamed to the same thing, creates conflicts.
• Descriptions are safe. Changing a description affects only the human-readable help text and breaks no dashboards.
• Units are not changed. Renaming a duration metric from milliseconds to seconds in its name does not convert the numbers. That would be a lie in the name.
• Announce renames. Tell dashboard owners before you ship, and keep the old name for a short time if you can.

What a conflict is

A conflict happens when two streams end up with the same name but different meanings, for example one counter and one histogram both called “requests,” or two instruments with different units. Backends dislike this, because one name should describe one thing. The SDK usually detects such conflicts, writes a warning to its diagnostic output, and either keeps both streams or lets one take priority, depending on the language. Neither result is what you wanted.

flowchart TD
    A["A view renames or merges streams"] --> B{"Do two streams now share one name?"}
    B -- "No" --> C["Everything exports normally"]
    B -- "Yes" --> D{"Same kind, same unit, same description?"}
    D -- "Yes" --> E["Streams are treated as one and merged safely"]
    D -- "No" --> F["Conflict: the SDK logs a warning"]
    F --> G["Fix the view so each name has one meaning"]

Explaining Figure 4

After a view renames something, the first question is whether two streams now share a name. If not, all is well. If they do, the next question is whether they are really the same thing: same kind of instrument, same unit, same description. If so, the SDK may safely treat them as one. If not, a conflict is raised, a warning is logged, and you must fix the view so that every name has exactly one meaning.

Using Drop to remove a stream

When you apply the Drop aggregation to matching instruments, they produce no stream at all. This is the cleanest way to silence a chatty library without patching it. Be careful with broad wildcards. A view that drops “everything starting with http” may also drop metrics that your alerts need. A good habit is to drop by exact name for the specific metrics you reviewed, rather than by broad patterns.

A Naming Standard Helps Everyone

Renaming is easiest when a company has a naming standard that everybody follows. A common approach is to use lowercase words separated by dots, to put the thing being measured first and the unit near the end, and to avoid putting labels or versions into the name. When views are used to bring every service to the same standard, dashboards become portable: a chart built for one service works for any other with no changes.

Standards also reduce conflicts. If every service uses the same name for the same idea, the question of whether two streams share a meaning almost never arises. The effort of writing the standard is repaid every time a new service joins the company.

Testing a Rename Safely

A careful way to rename a metric is to send both names for a short period. Create one view that keeps the old stream, and another that produces the new name, and tell dashboard owners which date the old name will be removed. During the overlap, owners update their charts and alerts to the new name, and nothing breaks. When the date arrives, remove the view that keeps the old name. This approach costs a little extra data for a few weeks and avoids the far larger cost of broken alerts.

Both can rename, filter, and drop. They differ in where the work happens and how much it saves.

The OpenTelemetry Collector is a standalone program that receives telemetry, processes it, and forwards it. Its processors can rename metrics, remove labels, and filter streams, much like a view. So which should you use? The answer depends on where you want the savings and who owns the decision.

flowchart TD
    Q["You want to reshape a metric"] --> A{"Do you want to save memory and network at the source?"}
    A -- "Yes" --> V["Use a view in the SDK"]
    A -- "No" --> B{"Does the change need to apply to many applications at once?"}
    B -- "Yes" --> C["Use Collector processing"]
    B -- "No" --> D{"Do you need different histogram buckets?"}
    D -- "Yes" --> V
    D -- "No" --> E["Either works; prefer the simpler place to maintain"]

Explaining Figure 5

The first question is about savings. If you want to avoid paying for memory and network use, the work must happen before the data leaves the application, so a view is the answer. If the goal is simply central control over many applications, the Collector is attractive, since one change reaches everyone. If you need different histogram buckets, only a view can do it properly, because once measurements have been sorted into buckets, the original values cannot be recovered. Otherwise, either tool works, and you should choose the one that your team can maintain most easily.

A sensible partnership

Most mature setups use both. Views in each application handle the things only the source can do: right-sized histogram buckets, removing expensive labels early, and dropping metrics nobody needs. The Collector handles fleet-wide policy: adding environment details, standardising names, and masking sensitive values. This division gives you savings at the source and consistency in the middle.

A Practical Example of the Partnership

Suppose a company has two hundred services. The platform team wants every metric to carry the environment label, to follow company naming, and to hide an internal server label before sending data to an outside vendor. These are fleet-wide policies, so the Collector is the right home: one change reaches all two hundred services. Meanwhile, a single team wants better histogram buckets for its payment latency metric, and wants to drop twelve unused metrics from a library. These are application-specific, so views are the right home. Both tools are used, each for the job it suits.

Knowing the limits prevents long, confusing afternoons of debugging.

Views are powerful but narrow. They shape streams. They do not rewrite history, do not invent data, and do not control everything about delivery. A short list of limits will save you from surprise.

Temporality in plain words

Two words appear in the table that deserve an explanation. Temporality describes whether a metric reports the running total since the program began, called cumulative, or only the change since the last report, called delta. Some backends prefer one style and some prefer the other. This choice is made by the reader or exporter, not by the view. Remember this when a colleague asks “Can I use a view to switch to delta?” The answer is no; look at the reader settings instead.

Why These Limits Are Actually Helpful

The limits of views may feel frustrating, but they protect you. Because a view cannot change values, you can trust that a number leaving your program is a faithful summary of what the code recorded. Because it cannot change the instrument kind, the meaning of each metric stays stable across every program that uses the same library. Because it acts only at creation, behaviour is predictable. A tool that could do anything would be much harder to reason about, and mistakes would be harder to find.

A view can be a quiet guardian of sensitive information, if you use it that way.

Labels are attractive places for developers to put useful facts: a customer identifier, an email address, a session token, a file path. In a trace, such details may be justified, but in a metric they are risky. Metric labels are copied into every series, stored for a long time, and often visible to many people. A view can act as a final filter that ensures no unexpected label ever leaves your program.

Why user-controlled labels are dangerous

Imagine a web service that records the requested path as a label. Normal traffic produces perhaps fifty distinct paths. But a scanner, or a malicious visitor, can request thousands of random paths. Each one creates a new series. Memory climbs, bills rise, and in a serious case the service slows down. The fix is partly in code, by using the route template such as “/orders/{id}” instead of the raw path, and partly in views, by keeping the cardinality limit tight as a net.

A short privacy checklist

• Ask what each label reveals. Could it identify a person, a secret, or an internal system?
• Prefer allow-lists. Name the labels you want, so nothing unreviewed can leak.
• Never use unbounded values as labels. Identifiers, timestamps, and raw paths belong in traces or logs, not metrics.
• Review after upgrades. Compare the exported labels before and after updating instrumentation libraries.
• Do not rely on views alone. Combine them with Collector masking and with access controls in the backend.

Allow-Lists as a Habit

Security specialists often say that a rule which says what is allowed is safer than a rule which says what is not allowed. The reason is simple: the world keeps inventing new things to forbid. For metric labels, the same logic holds. A new library version may add a label that you never reviewed. With an allow-list, that label is quietly removed until you decide it deserves to be sent. With a block-list, it flows out immediately, and you learn about it only after the data has been stored and shared.

Shared Responsibility

Views are one layer of protection among several. Developers are responsible for not putting secrets or personal data into labels in the first place. The application owner is responsible for the allow-lists that guard the exit. The platform team is responsible for Collector masking and for access controls in the backend. When each layer does its part, a single mistake in one layer is caught by the next, and sensitive information rarely reaches a place where it should not be.

Views fail quietly. A wrong view does not crash anything; it just makes some numbers disappear or look strange.

If a view accidentally matches too much, a useful metric vanishes. If it matches too little, an expensive metric keeps flowing. Neither mistake raises an error. The only symptom is a chart that goes empty or a bill that does not shrink. Because the failure is silent, you must look for it on purpose.

Check after every change

Reading the Overflow Signal

The overflow label deserves a permanent place on your monitoring dashboard. When a stream reaches its limit, new label combinations are merged into a single series carrying a marker that identifies it as the overflow. If that series ever appears, treat it as an alert: some label has grown beyond expectation. Look at which metric produced it, list the labels, and ask which one has unbounded values. Fixing the cause is far better than raising the limit, which only postpones the cost.

Who Should Look at These Checks?

Give each check an owner. The platform team can watch overall series counts and overflow markers across the whole company, while each service team watches its own metrics and dashboards. When both sides know their role, problems are noticed while they are small, and a surprise bill or a flat chart becomes a small fix instead of a long investigation.

Every design has a price. An honest view helps you decide how much to reshape.

Common trade-offs in plain language

When views are not enough

Views shape how existing instruments are summarised, but they cannot create better measurements. If a library measures the wrong thing, such as total time when you need time split into waiting and working, no view can recover the missing split. In that case the right fix is better instrumentation, either by adding your own instruments or by upgrading the library. Think of views as the finishing touch, not the foundation.

Counting the Savings Honestly

When you report the benefit of views to management, count honestly. Measure series, storage, and network use before and after, over the same period and under similar traffic. Remember that some of the saving comes from deleted detail, and say so plainly. A good report states what was removed, why it was safe to remove it, and what questions can no longer be answered from metrics, with a pointer to where those questions can still be answered, such as traces or logs.

Patterns are tried-and-true recipes. Habits are the small routines that keep your metrics clean, cheap, and useful.

Habits that pay off

• Measure before you cut. Look at series counts per metric, and trim the biggest ones first.
• Prefer allow-lists for costly metrics. They protect you against future surprises.
• Set up views before instruments are created. Do it at the very start of the program.
• Keep views small and readable. One view, one purpose, with a clear comment of why it exists.
• Review after library upgrades. New versions can add metrics and labels you did not approve.
• Test the exported output. Print it and compare it with an approved list.
• Tell the dashboard owners. Any rename or dropped metric should be announced.
• Document the standard. A one-page guide with examples makes the right way the easy way.

A gentle path to adopting views

Keeping the Standard Alive

Writing a standard is easy. Keeping it alive through years of change is harder. Teams reorganise, languages are added, and libraries are upgraded, and each change is a chance for someone to invent a private rule. Give the standard an owner, publish it where engineers actually look, and include a worked example. When it changes, update the shared configuration first, so that new releases pick up the change in the ordinary course of work, not through a long manual campaign.

Most view problems come from the same few mistakes. Knowing them in advance saves a lot of confusion.

Myths worth clearing up

A Review Checklist Before You Ship a View

• Is the target narrow enough? Read the criteria aloud and confirm that they match only the instruments you intended.
• Is the label list reviewed? Every kept label should be bounded, useful, and safe to share.
• Are the names unique? No two streams should end up with one name and two meanings.
• Do the buckets fit? Boundaries should cover the real range of values and include any promised target.
• Is the backend ready? Confirm that the destination understands the chosen aggregation.
• Is the owner of every dashboard informed? Renames and drops should never be a surprise.

A team that walks through these six questions before every change will avoid nearly all of the mistakes described above. The checklist takes five minutes, and it is far cheaper than an incident that begins with the words “the chart went blank.”

Let us follow one imaginary service from a noisy, costly setup to a tidy, affordable one, using simple numbers.

The Orders service runs as 100 copies in the cloud. It uses a web framework library that creates 20 different metrics, each with about 50 series per copy. It also has its own request duration histogram, which records seconds, with the labels route (20 values), method (4), status (6), and customer identifier (up to 5,000).

Step 1: audit the cost

The library’s 20 metrics at 50 series each produce 20 × 50 = 1,000 series per copy. Across 100 copies that is 100,000 series. The team’s own histogram can in theory reach 20 × 4 × 6 × 5,000 = 2,400,000 series per copy, which is 240,000,000 across 100 copies. Real traffic reaches only a fraction of those combinations, but the trend is alarming, and the default cap of 2,000 combinations per stream is already being hit by some copies, producing overflow series.

Step 2: drop what nobody reads

After checking dashboards and alerts, the team finds that only 3 of the library’s 20 metrics are used. They write views that drop the other 17, naming each one exactly. The library series fall from 100,000 to 3 × 50 × 100 = 15,000, a drop of 85 percent, and the application code is untouched.

Step 3: trim the expensive label

The customer identifier is the culprit in the histogram. The team writes a view with an allow-list that keeps route, method, and status. The theoretical maximum per copy falls from 2,400,000 to 20 × 4 × 6 = 480, and across 100 copies to 48,000. The overflow series disappears, and the data is complete again. Customer-level questions move to traces, where one customer’s request is easy to find.

Step 4: fix the buckets

The histogram records seconds, but it uses the default boundaries that begin at 0, 5, 10, and 25. Nearly every request falls in the first bucket, and the computed 99th percentile is meaningless. The team adds a view that sets the boundaries to 0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1, 2.5, 5, 7.5, and 10. Immediately the dashboard shows a believable curve, with most requests around 0.1 to 0.25 seconds and a thin tail reaching one second.

Step 5: verify

The team starts one copy in a test environment with a console exporter, and compares the printed metrics with the baseline list. Three library metrics remain, the histogram has three labels and the new buckets, and no warnings about conflicts appear. Only then do they roll out to all 100 copies. A day later, series counts match the plan and the overflow label is gone.

What the Orders Team Learned Afterwards

Looking back, the team noticed that their most valuable decisions were also their simplest. They dropped what nobody read, removed the one label that caused most of the cost, and fixed the buckets so the data told the truth. They also learned to treat the first day after any change as a checking day, comparing the exported metrics with a saved baseline and watching for the overflow marker.

Finally, they wrote a one-page guide for new teams. It listed the approved labels, gave the standard bucket boundaries for latency, explained how to estimate cardinality with multiplication, and named a contact for questions. New services now begin with sensible views by default, which is the best sign that a standard is working.

Three short stories show how views turn confusion into clarity.

Choosing Where to Begin

If your organisation is only starting out, you do not need to solve everything at once. Begin with the single most valuable step: find your most expensive metric and look at its labels. Remove the unbounded one. Next, find a histogram with default buckets and fit it to its real range. After that, drop metrics that nobody reads, and finally publish a shared starter set so that new services inherit the results. Each step is small, brings a clear benefit, and can be checked on its own.

This gradual path also builds goodwill. Teams see the savings and the clearer charts early, and they become willing partners in later, more demanding steps. Views are a humble feature, but used with care they give every future metric a sensible name, a fitting shape, and a fair price.

A view is a small rule with a large effect: it lets you decide how your measurements are reported.

We began with a cook who records everything and hands over a four-hundred-page notebook, and we ended with a tidy single sheet. We saw how a view selects instruments, reshapes their streams, and sometimes drops them completely. We looked at the defaults, the menu of aggregations, the arithmetic of cardinality, and the importance of histogram buckets that fit. We compared views with the Collector, learned what views cannot do, and examined their role in privacy and monitoring. The cure for nearly every metric problem is the same: measure what matters, label with care, and shape the output at the source.

Keep one last idea in mind as you put this guide to work. Views are not about collecting less for its own sake. They are about collecting what you will actually use, in a shape that tells the truth, at a cost you can afford. Start small, measure the result, and let each view earn its place by solving a problem you can name.