We go in lessons. Each lesson explains one idea in text, and a small diagram beside it shows the same idea.

Lesson 1. Three signals, three questions

Telemetry is the data your systems send out about themselves. OpenTelemetry calls each kind a signal, and there are three main ones:

• Traces record the path of one request through your services. Each step in that path is a span.

• Metrics are numbers measured over time, such as requests per second.

• Logs are event messages, such as an error message.

Each signal answers a different question. A metric tells you that something is wrong. A trace tells you where. A log tells you what happened. In this guide, all three get the same care, because they all take the same trip.

Figure 1. The three signals, and the question each one helps you answer.

Lesson 2. The four stops on the journey

Every piece of telemetry makes the same trip, whatever its signal.

1. Create. Inside your app, an OpenTelemetry SDK or instrumentation library creates spans, metrics and logs. Each one carries a resource: a set of attributes that describe who produced it. The most important resource attribute is service.name. For our sample service it is checkout-demo, and it is how you will later find this service's data among everything else.

2. Carry. The data is sent over the network using OTLP (the OpenTelemetry Protocol), OpenTelemetry's own way of sending telemetry from one place to another. An OTLP receiver usually listens on port 4317 for gRPC and port 4318 for HTTP.

3. Process. The OpenTelemetry Collector receives the data, can change it on the way through, and sends it on.

4. Store. A backend stores the data and lets you search and chart it.

The Collector is optional in theory, but in practice it is the central stop: it lets you change where data goes without changing every app.

Figure 2. Create, carry, process, store: the same four stops for traces, metrics and logs.

Lesson 3. Inside the Collector: one receiver, three pipelines

Think of the Collector as a small post office for checkout-demo's data. Its config file tells it four things (configuration docs):

• Receivers: the front door. This is where checkout-demo's data comes in. Our front door is the otlp receiver, because the data arrives as OTLP.

• Processors: the sorting table. Here the data can be changed before it leaves. We use batch, which packs many small items together so they travel in groups.

• Exporters: the way out. This is where the data goes next. In real life that is a backend. For learning, we use debug, which simply prints the data on the Collector's screen.

• The service section: the route plan. It links a door, a table and a way out into a pipeline. Each pipeline is for one signal only: traces, metrics or logs.

One receiver can feed several pipelines. That is the key idea of this lesson: the same otlp receiver takes in all three signals, and the Collector then sends each signal down its own pipeline. Processors in a pipeline run in the order you list them. Defining a part at the top of the file is not enough: you also need to put it in a pipeline.

Figure 3. One receiver, three pipelines. Each signal travels its own line through the Collector.

Here is a minimal learning config that matches Figure 3:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: localhost:4317  # gRPC, only this computer can send
      http:
        endpoint: localhost:4318  # HTTP, only this computer can send

processors:
  batch: {}

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

The otlp receiver now has two doors: gRPC on port 4317 and HTTP on port 4318. Our test tool below uses the gRPC door.

Read it from the bottom up. The service.pipelines block names three lines. Each line says: take data from otlp, pass it through batch, and print it with debug. The blocks above it simply define those parts.

Lesson 4. Walk-through: watch checkout-demo's data arrive

Now we watch the flow happen. We do not need a real app: telemetrygen, a tool from the OpenTelemetry project, can play the part of checkout-demo and send all three signals. If you have Go on your computer, one command installs it:

go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest

Start the Collector with the config from Lesson 3. Then, in a second terminal, send one item of each signal, naming the sample service with the --service flag:

# 1) one trace
telemetrygen traces  --otlp-insecure --traces 1  --service checkout-demo
# 2) one metric
telemetrygen metrics --otlp-insecure --metrics 1 --service checkout-demo
# 3) one log
telemetrygen logs    --otlp-insecure --logs 1    --service checkout-demo

Now switch to the Collector's terminal. Your job is simple: find service.name: checkout-demo three times. Look for it once in the trace output, once in the metric output and once in the log output. It sits with the resource attributes. If you find all three, then all three signals reached the Collector and came out of their own pipelines.

Figure 4. The walk-through: find checkout-demo once in each signal's output.

Lesson 5. Who is allowed to send data in?

The receiver's endpoint decides who can send data to it. With localhost, only your own computer can send data. With 0.0.0.0, the Collector listens on every network interface. Then any computer that can reach yours can send data too. The OpenTelemetry security best practices advise binding to a specific interface, such as localhost or a pod's IP, instead of 0.0.0.0. Since Collector v0.110.0, if you don't set an endpoint, the Collector uses localhost. In Docker or Kubernetes, localhost may not behave as you expect, so deployed configs often use a different, specific address.

Figure 5. The endpoint address decides who can send data in. Pick the narrowest address that works.

Where to go next

In a real setup you replace the debug exporter with an exporter for your backend, and you may add processors to shape the data. Because one Collector config carries all three signals, a small mistake can affect everything you collect, so changes deserve testing before they reach production. A CloudSkill Consulting LLC guide on testing Collector config changes safely is coming soon on our Dev.to.

Key terms

• Signal: one kind of telemetry: traces, metrics or logs.

• Span: one step in a trace.

• Resource / service.name: attributes describing who produced the data; service.name names the service.

• OTLP: the OpenTelemetry Protocol that carries telemetry (4317 gRPC, 4318 HTTP).

• Pipeline: one line in service.pipelines that carries one signal from receivers through processors to exporters.

Written by the CloudSkill Consulting LLC team, a multi-cloud architecture, FinOps and observability consultancy (cloudskillconsulting.com). Questions: info@cloudskillconsulting.com

Two clouds do not have to cost twice as much to manage. The trick is simple: share the rules, not the tools.

In this guide, CloudSkill Consulting LLC walks you through the plan one step at a time. First, you write down why you use each cloud. Next, you set five shared rules that work the same way on AWS and Azure. Then you use each cloud's own cost tools to follow those rules. Finally, you look at the common mistakes and a simple plan for your first month.

First, write down why you are multi-cloud

This sounds too simple. It is the step most people skip.

Write one line for each cloud:

• "We use AWS for ___."
• "We use Azure for ___."

Good reasons are clear and specific. For example: a product already runs there, a tool you need lives there, or a customer requires it.

If you can't fill in the blank, that cloud may not need new workloads. Every extra place you run things adds cost: more skills, more monitoring, more data moving around.

The five shared rules

These rules are the same on both clouds. Only the tool you use to follow each rule is different. Figure 2 shows each rule in the middle, with the AWS tool on the left and the Azure tool on the right.

Rule 1: One tag scheme

Pick a few tag keys and use them everywhere. For example: owner, env, project, cost-center.

Same spelling. Same lowercase. On AWS, activate them as cost allocation tags so they show up in billing. On Azure, use Azure Policy to require them.

Now you can ask one question on both clouds and get a matching answer:

# AWS: find resources tagged project=billing-api (current region)
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=project,Values=billing-api \
  --query "ResourceTagMappingList[].ResourceARN"

# Azure: find resources tagged project=billing-api (current subscription)
az resource list --tag project=billing-api \
  --query "[].{Name:name,Type:type,RG:resourceGroup}" -o table

The two commands do the same job. The first one asks AWS for every resource with the tag project=billing-api in the current region. The second one asks Azure the same question for the current subscription. Because the tag key and value are spelled the same way on both sides, the answers match.

Rule 2: One budget per project, on each cloud

If a project runs on both clouds, give it a budget on both. Use AWS Budgets on one side and Cost Management budgets on the other. Filter each budget by the same project tag.

Then the project owner sees two numbers that add up to one total.

Rule 3: One owner per account or subscription

Every AWS account and every Azure subscription needs one named person. Not a group email. A person.

Group them in a clear way:

• AWS Organizations puts accounts under one structure with one bill for all accounts (consolidated billing).
• Azure management groups put subscriptions under one structure for policy and access.

Try to mirror the layout. For example, "prod" and "non-prod" on both sides. When both clouds look the same, people can find things quickly, and every bill line has a person to ask.

Rule 4: Same alert levels

Decide your alert levels once. Use them on both clouds. Choose levels that fit your budget, such as a warning when forecast spend is getting close and a louder alert when actual spend goes over. Set the alert levels in AWS Budgets on AWS and in Cost Management budget alerts on Azure.

When the rules match, people learn them once. They stop ignoring alerts from "the other cloud."

Rule 5: One monthly cost review

One meeting. Both clouds. Use Cost Explorer on AWS and Cost analysis on Azure. Same agenda each time:

1. Top changes on AWS.
2. Top changes on Azure.
3. Untagged resources on either side.
4. Data moving between the clouds.

Use each cloud's own cost tools

You don't need a big new platform on day one. Both clouds already give you good tools.

Start here. Add more only when these stop being enough.

Mistakes that quietly raise the bill

Copying everything to both clouds "just in case." Running the same full stack twice doubles cost. Decide which workloads truly need to be on both. For most, one cloud is enough.

Forgetting data transfer. Moving data out of a cloud costs money on both AWS and Azure. Apps that send data between clouds all day can cost a lot. Keep data and the apps that use it close together.

Two tag schemes. Owner on one side and owner on the other breaks your reports. Fix the spelling early.

Buying commitments too soon. Savings Plans and Reservations are great for steady, right-sized workloads. They are a bad fit for something you might move next quarter.

No one reads the alerts. An alert sent to a shared inbox that nobody checks is the same as no alert.

A simple first-month plan

• Week 1: Write the "why" line for each cloud. Agree on tag keys.
• Week 2: Turn on tag rules (cost allocation tags on AWS, Azure Policy on Azure).
• Week 3: Create one budget per project on each cloud, with the same alert levels.
• Week 4: Hold the first monthly review. Write down three fixes.

Each week builds on the one before. The tag keys from week 1 are used by the tag rules in week 2. The budgets in week 3 filter on those tags. The review in week 4 uses the same agenda as Rule 5.

One question to ask this week

If someone asked, "What did project X cost last month, on both clouds?", could you answer in five minutes?

If not, start with Rule 1. Everything else gets easier after that.

Have a multi-cloud cost question? CloudSkill Consulting LLC shares more practical AWS, Azure and Google Cloud notes at cloudskillconsulting.com.