You might even know the basic definition, but knowing what OpenTelemetry is vs how it actually works are two different things.

By the end of this guide, you'll understand how OpenTelemetry works end-to-end, from the moment a request enters your application to the moment you can see it in your observability backend. You'll learn how traces, spans, context propagation, and exporters all fit together into one pipeline.

If you're completely new to OpenTelemetry, don't worry: the next section will get you up to speed before we go any further.

Table of Contents

• What is OpenTelemetry?

• How OpenTelemetry Works

  • Step 1: Instrument Your Application

  • Step 2: OpenTelemetry Creates Telemetry Signals

  • Step 3: Traces Follow Requests Through Your Application

  • Step 4: Context Propagation Connects Work Across Services

  • Step 5: The OpenTelemetry SDK Processes the Telemetry

  • Step 6: Exporters Send the Telemetry

  • Step 7: The OpenTelemetry Collector Receives and Processes the Data

  • Step 8: An Observability Backend Stores and Analyzes the Telemetry

• Putting the OpenTelemetry Flow Together

• Do You Need Every OpenTelemetry Component?

• Why Use OpenTelemetry?

• Conclusion

What is OpenTelemetry?

OpenTelemetry is an open-source, vendor-neutral observability framework. It gives you a standard way to instrument your application, generate telemetry data, and export that data to any observability backend of your choice.

Before OpenTelemetry, every monitoring tool had its own way of collecting data. If you used Datadog, you’ll have to instrument your app the Datadog way. If you switched to Jaeger, you started over. OpenTelemetry changed that by giving you one standard way to instrument your application, regardless of which backend you use

[!NOTE] OpenTelemetry is not a monitoring platform, dashboard, or data store. It provides the tools and standards for collecting and exporting telemetry from your application to an observability backend, where the data can be stored, queried, and analyzed.

The data OpenTelemetry collects is called telemetry. It's the information your application produces about itself as it runs, and it comes in three forms:

• Traces tell you how a request traveled through your system.

• Metrics give you numbers, like how many requests per second your app is handling, or how much memory it's using.

• Logs are timestamped records of specific events that happened inside your application.

How OpenTelemetry Works

When a request hits your application, a lot happens behind the scenes. OpenTelemetry's job is to capture all of that activity (the traces, metrics, and logs) and send them to the right place.

Here’s what it looks like:

Each stage has a specific job. Let's walk through them one by one.

Step 1: Instrument Your Application

Before OpenTelemetry can capture anything, your application needs to be instrumented. Instrumentation is simply the process of adding code that tells OpenTelemetry what to watch and what to record.

There are two ways to instrument your application: automatically or manually.

1. Automatic instrumentation

This is the easiest one to start with. You add a library to your project, and it instruments your application for you with no changes to your existing code.

For example, if you're running a Node.js Express app, you can add the OpenTelemetry auto-instrumentation package, and it will automatically start capturing incoming HTTP requests, outgoing calls, database queries, and more.

Here's what that setup looks like:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const sdk = new NodeSDK({
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Once this runs before your app starts, OpenTelemetry begins capturing telemetry automatically. For a complete setup guide, see Getting started with OpenTelemetry in Node.js.

2. Manual instrumentation

Automatic instrumentation covers a lot, but it can't capture everything that happens inside your own code. If you want to track what happens inside a specific function, like how long it takes to process a payment or validate a user, you need to add that yourself.

Here's a simple example. Let’s say you have a function that processes an order:

function processOrder(orderId) {
  // processing logic
}

With manual instrumentation, you wrap it like this:

const { trace } = require('@opentelemetry/api');

const tracer = trace.getTracer('order-service');

function processOrder(orderId) {
  return tracer.startActiveSpan('processOrder', (span) => {
    // processing logic

    span.end();
  });
}

What happens is that you created a span. That span now records when processOrder started, when it ended, and how long it took. You'll learn more about spans in Step 3.

For the full manual instrumentation reference, see OpenTelemetry JavaScript instrumentation.

Step 2: OpenTelemetry Creates Telemetry Signals

Once your application is instrumented, OpenTelemetry starts producing telemetry data about what your application is doing. That data comes in three forms, called signals, which we've already briefly talked about: traces, metrics, and logs. Each signal answers a different kind of observability question.

Traces show you how a request moved through your system, which services it touched, and how long each step took. Metrics give you numbers over time, things like request rate, error rate, and memory usage. Logs are timestamped records of specific events that happened inside your application.

Here's a quick comparison:

You don't have to choose between them. In practice, you'll use all three together. A metric tells you something is wrong, a trace shows you where, and a log tells you exactly what happened.

Step 3: Traces Follow Requests Through Your Application

When a user sends a request to your application, that request usually touches multiple services before a response comes back. A trace is the complete record of that journey, from the moment the request enters your system to the moment it finishes.

A trace is actually made up of smaller units called spans. Each span represents one operation, like an API call, a database query, or a function execution, and together they give you the full picture of what happened.

Every trace gets a unique trace ID, and every span gets its own span ID. The trace ID is what links all the spans together. No matter how many services a request passes through, they all share the same trace ID, so you can follow the request from start to finish in your observability backend.

Here's a simple example. A user places an order, and the request flows through four services:

Each span has a start time and an end time, so you can see how long each operation took. If something slowed down or failed, you can pinpoint exactly where it happened just by looking at the spans.

Step 4: Context Propagation Connects Work Across Services

In Step 3, you saw how a single trace is made up of spans from multiple services. But here's a question you need to ask: how does OpenTelemetry know that a span in your payment service belongs to the same trace as a span in your order service?

Without something connecting them, each service would record its own spans independently. Your API gateway would see one operation, your order service would see another, and your payment service would see a third. They'd look like completely separate requests with no relationship to each other, which makes debugging across services nearly impossible.

That's where context propagation comes in. As a request moves from one service to another, OpenTelemetry attaches the trace context to it, typically as HTTP headers. That context carries the trace ID and the parent span ID, so every service that handles the request knows which trace it belongs to and where it sits in the chain.

Here's what that looks like in practice:

All three services share the same trace ID. That's what lets your observability backend connect the spans together into one complete trace.

OpenTelemetry doesn't invent its own rules for this. It follows the W3C Trace Context standard, a widely adopted specification that defines how trace context should be formatted and passed between services, so it works consistently across different languages, frameworks, and vendors.

The good news is that if you're using automatic instrumentation, context propagation happens automatically. OpenTelemetry handles the headers for you, so you don't have to think about it unless you're working with a custom transport or a non-standard setup.

Step 5: The OpenTelemetry SDK Processes the Telemetry

At this point, OpenTelemetry is capturing telemetry and keeping traces connected across services. But between the moment a span is created and the moment it leaves your application, something has to process it. That's the SDK's job.

When your instrumented code creates a span, it does that through the OpenTelemetry API. The API is what you interact with as a developer, things like trace.getTracer() and tracer.startActiveSpan(). But the API alone doesn't process or send anything. It needs the SDK behind it to actually do the work.

Once the SDK receives the telemetry, it runs it through a processor. The processor is responsible for things like batching spans together before sending them, adding extra attributes, or filtering out data you don't need. The most common one you'll see is the BatchSpanProcessor, which groups spans and exports them in batches rather than one at a time, making it more efficient in production.

Before the processor even runs, the SDK also handles sampling. Sampling lets you control how much telemetry you actually collect. In high-traffic applications, recording every single span would generate an enormous amount of data. With sampling, you can tell the SDK to only capture a percentage of traces, which keeps your costs and data volume manageable without losing visibility.

Once the processor is done, it hands the data to the exporter, which is what actually sends it to its destination. You'll see how that works in the next step.

Step 6: Exporters Send the Telemetry

The exporter's job is simple: take the telemetry the SDK prepared and send it to whatever destination you've configured.

OpenTelemetry uses OTLP, the OpenTelemetry Protocol, to transport telemetry data. It's a standard wire protocol designed specifically for transmitting traces, metrics, and logs, and it runs over either HTTP or gRPC.

[!NOTE] OTLP and OpenTelemetry are not the same thing. OpenTelemetry is the full framework, covering instrumentation, the SDK, the Collector, and more. OTLP is just the protocol it uses to transport data.

Although OTLP is the default, not every exporter uses it. Some exporters send data directly to specific backends in their own format, like Jaeger or Prometheus. So depending on your setup, you might use an OTLP exporter to send data to a Collector or backend, or a vendor-specific exporter to send it directly."

Step 7: The OpenTelemetry Collector Receives and Processes the Data

The OpenTelemetry Collector is a standalone service that sits between your application and your observability backend. It receives telemetry data, processes it, and forwards it to one or more destinations.

Using the Collector is common but not mandatory. You can configure your exporter to send data directly to your backend and skip the Collector entirely. But in most production setups, teams add a Collector because it gives them a central place to manage telemetry, without touching application code.

The Collector has three stages:

• Receivers accept incoming telemetry from your applications, typically over OTLP.

• Processors transform the data at the Collector level, things like batching spans, filtering out noise, or adding attributes before forwarding.

• Exporters send the processed data to your backend, or multiple backends if needed.

Here's a minimal Collector configuration:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:

exporters:
  otlphttp:
    endpoint: https://your-backend.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

This config accepts traces over gRPC, batches them for efficiency, and forwards them to an observability backend over HTTP.

The Collector can also receive data from multiple applications simultaneously and route it to one or more destinations. So instead of each application shipping telemetry directly to your backend, they all send it to the Collector, and the Collector handles the rest.

For the full configuration, see the OpenTelemetry Collector configuration docs.

Step 8: An Observability Backend Stores and Analyzes the Telemetry

This is where OpenTelemetry's job ends. Once your telemetry leaves the Collector, it arrives at your observability backend.

The backend is what stores your data, lets you query it, and gives you the dashboards and alerts you actually interact with day to day. OpenTelemetry doesn't provide any of that. It gets the data there, and the backend does the rest.

A few popular backends that support OpenTelemetry natively:

• Open-source: Jaeger, Prometheus, Grafana Tempo

• Commercial: Datadog, New Relic, Honeycomb, Dynatrace, Elastic, Lightstep, Grafana Cloud, Middleware.

Once your data is in the backend, you can search through traces to debug a slow request, build dashboards to monitor your application's health, and set up alerts when something goes wrong.

Putting the OpenTelemetry Flow Together

Let’s assume a user initiates a bank transfer on a mobile banking app. The request hits your API gateway, and because your application is instrumented, OpenTelemetry immediately starts capturing what’s happening. It creates a span for the incoming request and assigns it a trace ID.

As the request moves to the authentication service, context propagation carries that trace ID along in the request headers. The authentication service creates its own span and attaches it to the same trace. The same thing happens when the authentication service calls the transaction service, and when the transaction service hits the database to process the transfer. Four services and four spans, with one trace ID connecting them all.

Meanwhile, the SDK processes the telemetry in the background, runs the spans through the batch processor, and hands them to the exporter. The exporter packages everything into OTLP and sends it to the Collector, which applies your processing rules and forwards it to your observability backend.

Here’s a summary of every component involved in that flow:

From that single transfer request, you now have a complete trace in your backend. When you open your dashboard and search the trace ID, you'll see every service, every span, and every millisecond of that transaction laid out in front of you.

Do You Need Every OpenTelemetry Component?

To be honest, you don’t need every component to get started with OpenTelemetry. The pipeline you’ve seen throughout this article is the full setup, but not every team uses all of that.

1. Without the Collector: Your exporter sends telemetry directly to your backend with nothing in between. Works well for smaller projects or when you're just getting started.

2. With the Collector: The more common production setup. Teams add the Collector when they need more control, like routing telemetry to multiple backends, filtering sensitive data, or managing telemetry from dozens of services in one place.

The Collector is powerful, but it’s not mandatory. Start without it if your setup is simple, and add it when you actually need it.

Why Use OpenTelemetry?

You've now seen how every piece of OpenTelemetry fits together. Here's why it's worth using:

• Vendor-neutral instrumentation: Before OpenTelemetry, switching observability tools meant you had to re-instrument your entire application from scratch. With OpenTelemetry, you instrument once and switch backends freely.

• Consistent telemetry across services and languages: Your backend might be in Go, your microservices in Python, and your data pipeline in Java. OpenTelemetry has SDKs for all of them, and they all produce telemetry in the same format, so your whole stack speaks the same language.

• Correlated observability signals: Traces, metrics, and logs all flow through the same pipeline. So when something goes wrong, a spike in your metrics leads you to a trace, and that trace points you to the exact log entry where things broke down.

• It's becoming the industry standard: Most observability backends already support OpenTelemetry natively. Instead of learning a vendor-specific instrumentation approach every time you adopt a new tool, you learn OpenTelemetry once and it works everywhere.

Conclusion

OpenTelemetry gives you a standard way to instrument your application, collect telemetry, and ship it to any backend you choose, without locking you into a specific vendor or tool.

If you remember nothing else from this article, remember this: you instrument your application, generate telemetry, process it, export it, and analyze it. Every step has a component behind it, and now you know what each one does.

If you're just getting started, you don't need to set everything up at once. Start with instrumentation, get your telemetry flowing to a backend, and add the Collector when you need it. You can always add more as your needs grow.

If you found this helpful, I'd love to connect. You can find me on LinkedIn or X. Feel free to reach out if you have questions or just want to talk about observability and developer tooling.

Every request emits logs. Every service exports metrics. Every dependency introduces another layer of signals.

In theory, this should make systems easier to understand. In practice, it does the opposite.

Dashboards become dense, alerts become noisy, and when something breaks, the same questions still come up: What's actually wrong? Who's affected? Where do you even start?

The problem isn't observability. It's interpretation.

Most teams aren't short on metrics. They're short on meaning.

And that gap exists because developers are often forced to reason about infrastructure when they should be focused on application behaviour.

Metrics exist to describe systems, but without the right level of abstraction, they become another layer of complexity.

This is where modern PaaS platforms change the equation. They don't remove metrics. Instead, they turn them into signals that developers can actually use.

This article breaks down five metrics that consistently matter in production systems. More importantly, it shows how a PaaS helps translate these metrics into something actionable, without requiring developers to act as infrastructure operators.

I’ll be using the Sevalla dashboard to explain these metrics, but other platforms like Railway and Render will have similar metrics.

What We'll Cover:

• What a PaaS Actually Does

• Latency Becomes a Clear Performance Signal

• Error Rate Becomes a Reliable Indicator of Failure

• Throughput Becomes Context Instead of a Problem

• Resource Utilisation Moves Out of the Critical Path

• Instance Health Becomes Invisible by Design

• From Metrics to Meaning

• Why This Matters for Developers

• The Real Advantage Is Clarity

What a PaaS Actually Does

A Platform as a Service (PaaS) is an abstraction layer over infrastructure that handles deployment, scaling, networking, and runtime management for you.

Instead of provisioning servers, configuring load balancers, and setting up autoscaling rules, you deploy your application and the platform takes care of how it runs in production.

Platforms like Sevalla, Railway, and Render operate on this model. The key shift is responsibility.

In a traditional setup, developers are responsible for both application behaviour and infrastructure behaviour. If latency spikes or errors increase, you have to determine whether the issue is in your code, your scaling rules, or the underlying system.

A PaaS moves most of that infrastructure responsibility into the platform.

You still get access to metrics, but many of the variables behind those metrics –instance lifecycle, scaling decisions, resource allocation – are handled automatically.

This changes how you interpret what you see.

Metrics stop being signals that require cross-layer investigation, and start becoming signals that map more directly to application behaviour.

Now let's see what can happen if your team switches to using a PaaS.

Latency Becomes a Clear Performance Signal

Latency is the most direct representation of user experience. It tells you how long your system takes to respond.

When latency increases, users feel it immediately. Pages slow down. APIs become unreliable. Even small delays impact engagement.

Most developers know to look at percentiles like p95 or p99 instead of averages. The slowest requests are what define perceived performance.

But in many environments, understanding latency isn't straightforward.

A spike could come from inefficient code. Or from cold starts. Or from scaling delays. Or from network routing issues. Developers are forced to investigate layers they didn't build.

This is where a PaaS changes the role of latency.

Instead of being a starting point for infrastructure debugging, latency becomes a clean signal of application performance. Scaling, routing, and resource allocation are handled by the platform. What remains is a clearer relationship between code and outcome.

When latency increases, developers can focus on what they actually control: queries, logic, and dependencies.

The metric stays the same. The meaning becomes clearer.

Error Rate Becomes a Reliable Indicator of Failure

Error rate answers a simple question. Is the system working or not?

It's usually measured as the percentage of requests that fail due to server-side issues. These are failures users can't recover from. A broken checkout flow or a failed API call directly impacts trust.

In theory, error rate should be one of the easiest metrics to act on. In practice, it rarely is.

Errors can come from application bugs, but also from timeouts, resource limits, failed deployments, or unstable instances. Developers end up correlating errors with infrastructure events just to understand what happened.

This slows everything down.

A PaaS reduces this ambiguity.

Failures caused by scaling, instance crashes, or transient infrastructure issues are handled at the platform level. Retries, isolation, and recovery mechanisms are built in.

What remains is a tighter link between error rate and application correctness.

When the error rate increases, it's far more likely to be something in the code or a dependency, not an invisible infrastructure issue.

This shifts the error rate from a noisy metric into a reliable signal.

Throughput Becomes Context Instead of a Problem

Throughput measures how many requests your system handles over time.

It provides context for everything else. Latency and error rate only make sense when you know how much traffic the system is handling.

A spike in latency during high traffic is expected. The same spike during low traffic is a warning sign.

But in many systems, throughput introduces operational complexity. Traffic changes require scaling decisions. Teams define autoscaling rules, tune thresholds, and try to predict demand. When things go wrong, they revisit those decisions.

Developers end up thinking about capacity instead of behaviour.

A PaaS shifts this responsibility. Scaling is automatic. Traffic spikes are absorbed by the platform. Developers don't need to decide how many instances should be running or when to scale.

Throughput becomes what it should be: context.

It helps explain what's happening, without forcing developers to manage how the system adapts.

Resource Utilisation Moves Out of the Critical Path

Resource utilization measures how much CPU, memory, and I/O your system consumes.

Traditionally, this has been central to operating systems. High CPU or memory usage signals potential issues. Teams monitor these metrics to avoid failures and plan scaling.

But for most developers, resource utilization isn't where value is created.

Yet in many environments, developers are still responsible for interpreting these signals. They tune memory limits, investigate CPU spikes, and try to optimise resource usage to keep systems stable.

This is operational work.

A PaaS changes the role of these metrics.

Resource management is handled by the platform. Allocation, scaling, and isolation happen automatically. Developers don't need to constantly watch CPU graphs or memory charts to keep the system running.

These metrics still exist, but they move into the background.

They become diagnostic tools rather than primary signals.

Developers can focus on performance at the application level, instead of managing how infrastructure behaves under load.

Instance Health Becomes Invisible by Design

Instance health tracks restarts, crashes, and lifecycle events.

In many systems, this is a critical metric. Frequent restarts indicate instability. Memory leaks, crashes, or resource exhaustion often show up here first.

Teams monitor instance health to catch issues early and prevent cascading failures.

But this also reveals something important: developers are aware of, and responsible for, the lifecycle of infrastructure. They track restarts, investigate crashes, and try to stabilise the system manually.

A PaaS removes this responsibility.

Unhealthy instances are restarted automatically. Load is redistributed. Capacity is maintained without manual intervention.

Instance health doesn't disappear, but it no longer requires constant attention. It becomes part of the platform’s internal behaviour, not something developers need to actively manage.

From Metrics to Meaning

These five metrics haven't changed.

Latency still reflects performance. Error rate still reflects correctness. Throughput still reflects demand. Resource utilization still reflects efficiency. Instance health still reflects stability.

What changes is how much work it takes to interpret them.

In lower-level environments, developers have to connect these signals themselves. A latency spike leads to checking throughput, then resource usage, then instance behaviour. Each step requires context, assumptions, and time.

This is where complexity accumulates.

A PaaS reduces that gap.

It handles scaling, recovery, and resource management so that metrics map more directly to application behaviour. The signals become easier to interpret because fewer variables are exposed.

Instead of asking multiple questions across layers, developers can move more directly from symptom to cause.

Why This Matters for Developers

Most developers don't want to manage infrastructure. They want to build features, ship improvements, and respond to user needs.

But as systems grow, operational responsibility expands. Monitoring becomes more complex. Debugging requires more context. A significant portion of time shifts from building to maintaining.

Metrics are part of this shift.

They're necessary, but they also reflect how much of the system you're responsible for understanding.

A PaaS doesn't eliminate metrics. It reduces the effort required to make sense of them.

It ensures that when something changes in production, the signals developers see are closer to the reality they care about: application behaviour. User experience. System correctness.

The Real Advantage Is Clarity

The goal is not to have fewer metrics.

It's to have metrics that mean something without requiring deep infrastructure reasoning.

These five metrics form a complete picture of system health. But their real value depends on how directly they map to what developers control.

The more layers you have to think about, the harder mapping becomes.

A good PaaS removes those layers. It turns metrics from raw data into usable signals.

And that shift from metrics to meaning is what allows developers to understand production systems without being buried under them.

Join my Applied AI newsletter to learn how to build and ship real AI systems. Practical projects, production-ready code, and direct Q&A. You can also connect with me on LinkedIn.

I have seen too many founders who are smart, legit, and ambitious get ghosted by investors simply because they couldn't walk through their unit economics.

It's not personal. It's math.

So here it is: Numbers that will either carry your pitch or quietly kill it, explained by someone who has sat through them time and time again, with examples, and no fluff.

Here’s what we’ll cover:

• 1. Burn Rate: How Fast Are You Lighting Your Cash on Fire?

• 2. Cash Runway: How Long Before You Run Out of Cash?

• 3. CAC (Customer Acquisition Cost): How Much Does it Cost to Convince Someone to Pay You?

• 4. Customer Lifetime Value (LTV): How Much is One Customer Worth Over Time?

• 5. Gross Profit Margin: What Do You Actually Keep After Delivering Your Service or Product?

• 6. Monthly / Annual Recurring Revenue (MRR / ARR)

• 7. Churn Rate: How Fast Are Your Users Leaving

• 8. Payback Period: How Long Before You Recover Your CAC?

• 9. Earnings Before Interest, Taxes, Depreciation, and Amortization (EBITDA)

• 10. Valuation: What’s Your Company Worth – and What Supports that Number?

• Real Talk Before You Close That Tab

  • Real Experience

  • Why This Matters

• Conclusion and Final Thoughts

1. Burn Rate: How Fast Are You Lighting Your Cash on Fire?

Burn rate is the speed at which a startup is spending its cash. Basically, how fast are you consuming your venture capital to cover over overhead until you generate positive cash flow from operations? It’s a measure of negative cash flow.

If you’re spending $80K a month to keep the lights on (payroll, AWS, your workspace snacks, and so on), that’s how much cash you’re burning each month. But many startups calculate two different burn rates: gross burn (how much cash you’re spending, ignoring any revenue), and net burn (monthly operating experiences minus any cash you take in each month). Net burn basically measures how fast your cash is shrinking, and it’s often what investors care more about.

Real talk: investors want to know when the plane runs out of fuel before they board. Thats what this metric helps them understand – how fast you’re going through the money you have.

At some point, if a company has a high burn rate, it has to reduce structural costs by cutting expenditures on labor, rent, marketing, and/or capital equipment. The burn rate is an important metric for any company, but it's particularly important for startups that aren't yet generating revenue. It tells managers and investors how fast the company is spending its capital

Watch this video to understand more about Burn Rate.

2. Cash Runway: How Long Before You Run Out of Cash?

Cash runway tells how long a startup can continue to operate at a certain burn rate until they are out of cash. For startups without revenue, you can calculate this by dividing available cash by total monthly expenses. Available cash is defined as the funds that are accessible now or can be accessed at a later time relatively quickly to pay for expenses.

When you’re making this calculation, it’s important to not include any anticipated fundraising and other uncertain sources of capital.

Actively managing cash runway is crucial for startup survival and growth. With a significant percentage of startups failing due to cash shortages, founders need to closely monitor their cash burn rate and runway.

The length of runway needed varies based on factors including the startup’s stage, industry, and milestones. In tighter venture capital markets, startups should plan for longer runways and consider strategies such as increasing revenue, reducing expenses, or raising additional capital. Regularly updating financial models and understanding metrics like the burn multiple can help you make informed decisions to extend your runway and align your growth ambitions with financial stability.

While it’s a simple calculation at face value, a cash runway analysis is nuanced and unique to every startup and can be impacted by a multitude of circumstances.

To calculate this, you just divide your total cash reserves by the amount you’re spending each month. Say you’ve got $250K in the bank and you’re spending $50K/month: 250/50 = 5. So you’ve got 5 months. Not 6. Not “it depends” – 5. That’s your runway.

Investors ask “If we don’t fund you, how long do you survive?” If you don’t know that answer, you're not fundraising – you’re freelancing with hope.

Here is a video that explains cash runway with real world examples and the thought process behind it.

And here’s an article from JP Morgan breaking down cash runway, its importance, and what can you to to maximize it.

Burn Rate vs Runway

So, let’s just make this super clear: burn rate is simply how much you spend each month to run your operation – that is, your negative cash flow. Runway is how many months there are left before your bank balance reaches zero.

So again, why do these numbers matter?

Because burn rate tells you how quickly you need to find more revenue or funding. Runway tells investors whether you are going to still be around by the time they finish their due diligence.

They are not just numbers. They are your survival clock.

Smart founders utilize these metrics to:

• Trim the fat without cutting muscle – know what to focus on and what to let go

• Forecast hiring/fundraising deadlines – know the process and prep for it. Numbers don’t line but they sure can get you ghosted.

• Assure investors you’re not going to come knocking again in 90 days – establishing credibility is key, make an investor realize its not just a hobby, you mean business.

The goal: Extend runway without stalling momentum. Keep the plane in the air, while building a bigger engine.

3. CAC (Customer Acquisition Cost): How Much Does it Cost to Convince Someone to Pay You?

Cost of acquisition refers to the entire cost that a business incurs to obtain a new client or asset. This includes the purchase price, shipping, installation, and marketing costs for the asset acquired. CAC takes into account the total expenditure on all marketing, advertising, and sales for the period, which you then divide by the number of new customers for the period.

In this case, all the upfront costs incurred to purchase a business asset, including equipment or inventory, are part of the cost of acquisition. Cost of acquisition includes:

• Purchase price of the item

• Costs to ship it to its point of use

• Costs to install the item

• Costs to get it up and running (in the case of equipment) or ready for sale (in the case of inventory) condition

• Marketing sales teams salaries

• All sales and consulting marketing expenses geared to get new consumers should all be included

Formula:
CAC = (Total Marketing + Sales Expenses) / Number of New Customers Acquired

Say you spent $10K last month across paid ads, content creation, outbound campaigns, and sales team costs. You onboarded 100 new customers, so your CAC = $100.

But is that good?

It depends on:

• Your pricing model (one-time vs. subscription)

• Your margin (how much of that sale do you actually keep?)

• Your customer retention (how long do they stick around?)

If you’re selling a $20 product once, a $100 CAC is a non-starter. But if that customer brings in $50/month for 12 months, you’ve got a solid return.

Watch for red flags:

• CAC is rising but revenue isn’t

• You’re overly reliant on paid ads (especially if organic/referral is flat)

• You don’t know CAC by channel (averages hide leaks)

A healthy CAC is one that pays itself back quickly and can be improved over time as you optimize funnels and messaging

Here is a video that breaks down CAC for you.

4. Customer Lifetime Value (LTV): How Much is One Customer Worth Over Time?

Customer Lifetime Value is the average monetary value of each customer to your business. LTV takes into account how much a unique customer is expected to spend with your business. It’s an important metric so you know how much new customers are worth to your business over their lifespan as a customer.

Let’s say you charge $25/month. The average customer sticks around 12 months.
LTV = $300.

In this case, if your CAC is $80? You’re in the green. But if it’s $350? You’re basically paying people to hang out (and losing money on them).

Now, let’s connect this to CAC.

Say your CAC is $80. You’re doing fine – your LTV is ~4x CAC. That’s what investors want to see.

Rule of thumb: you want your LTV to be at least 3x your CAC. A 1:1 ratio means you’re barely breaking even, before operational costs and the math stops working at scale. So if you can hit a 3:1 ratio, great – and based off my experience, your business will be much more appealing if it’s closer to 5:1.

And keep in mind that different models can have different thresholds. For example, a SaaS company with low churn can afford higher CACs, while an e-commerce platform might need faster payback. And marketplaces and freemium models may have lower LTV per user, but they can often more easily offset it with volume.

If you don’t know your LTV or can’t defend it with data, it becomes hard to justify spend – and easy for investors to walk.

If you want to know more, this video walks you through the basics.

And here’s a video that beautifully explains the CAC and LTV relationship.

5. Gross Profit Margin: What Do You Actually Keep After Delivering Your Service or Product?

Gross profit margin shows the amount of money a business collects after it pays for all its expenses. It’s usually calculated as a percentage of sales. This specific metric is also referred to as the gross margin ratio.

Companies use gross margin as a measure of how production costs relate to revenue. If a company's gross margin falls because it is making less revenue, it may try to cut labor costs, find cheaper suppliers of materials, or increase prices to increase revenue.

Gross profit margins can also allow a business to measure how efficient a company is, or compare two very differently sized companies that share a common revenue stream or product

If you sell a subscription for $50/month and it costs you $10/month to host, maintain, and support it, your gross margin is 80%.

• Good: SaaS companies often hit 70–90%.

• Bad: If you're below 30%, your "scalable" business will collapse under weight.

Want to know the conceptual math behind this metric and how it differs from Profit Margin? Here is a fantastic video that easily breaks it down.

6. Monthly / Annual Recurring Revenue (MRR / ARR)

Annual recurring revenue (ARR) is revenue a company expects to see from its product and service offerings, calculated over the course of a year. Companies that sell annual subscriptions like using ARR as a sales metric to track what they anticipate making in a year.

ARR tends to be used if companies sell a product or service in the software as a service (SaaS) space, but it can also be useful in terms of streaming services, cell phone bills, and (almost) anything else with a predictable, recurring charge.

ARR is calculated annually, whereas monthly recurring revenue (MRR) is calculated monthly. MRR is useful in that it shows what’s happening on a month-to-month basis. For example, if you change your price in April, you can see the immediate effects of that change in May. MRR also helps track fluctuations in revenue based on outside factors like holiday shopping seasons and economic conditions.

In a nutshell, Monthly / Annual Recurring Revenue = predictable income.

If you’re pulling $20K/month in subscriptions, that’s $240K ARR. Simple.

What investors care about:

• • Is it growing?

    • How fast?

    • And how stable is it?

Here is a founder breaking down the metric and explaining the relationship between MRR/ARR.

7. Churn Rate: How Fast Are Your Users Leaving

The churn rate, also known as attrition rate, represents the rate at which a customer stops doing business with a company. Customer churn is typically expressed as the percentage of service subscribers that discontinue their service subscriptions within a time frame. Churn can also be expressed as the rate at which employees leave their jobs in a given time.

In order for a business to grow its number of clients, its growth rate (which takes into account new customers) must be higher than its churn rate.

The benefit of calculating a churn rate is that it can clarify how well a business is retaining its customers, which is a measure of the quality of service the business is providing and the usefulness of that service.

When a business can see its churn rate increasing from period to period, this suggests that a critical aspect of how it is running the business might be problematic or flawed.

It could be the result of:

• A faulty product(s)

• Bad customer service

• Costs exceed utility to customers

And so on.

The churn rate will indicate to a business that it needs to learn why its customers are leaving, and where it needs to adjust its business. It’s more expensive to attract new customers than it is to retain them, so reducing the churn rate can save a business resources in the future.

Real talk: Say you had 500 users at the start of the month, and you lost 50 by the end of the month. That’s 10% churn – which is high! Annualize that and…ouch. You're not growing. You're replacing.

Make sure you fix this before you fundraise. Or at least explain why churn’s high and what you’re doing to plug the holes.

Here is a video that beautifully explains Churn Rate.

8. Payback Period: How Long Before You Recover Your CAC?

The payback period is a popular tool for determining investment return. People invest money for the purpose of getting it back and generating a positive return on the money they invested. The shorter the payback period, the more beneficial the investment will be.

The payback period does not factor in the time value of money. You can determine it simply by counting the number of years until the principal paid in is returned.

This metric measures how quickly your customer pays you back for the cost of acquiring them. The payback period doesn’t take into account the total profitability of an investment. It’s just concerned with paying the investment back.

There are two common interpretations:

1. Customer-Level Payback: If your CAC is $250 and your customer pays $50/month, it’ll take 5 months to recover the acquisition cost.

2. Investment-Level Payback: You spend $100,000 on a new sales hire, tool stack, or feature. You want to know how long it takes for that investment to generate $100,000 in profit.

Both use the same principle: the shorter the payback period, the less cash you need to float your growth.

If you want a target, aim for 6 months for customer-level payback. Closer to 3-6 is ideal. Long payback periods mean you need deep pockets – or exceptional retention – to stay afloat.

Here’s a video where you can learn more.

9. Earnings Before Interest, Taxes, Depreciation, and Amortization (EBITDA)

EBITDA stands for Earning Before Interest, Taxes, Depreciation, and Amortization. You can think of this as just your company's operating profit if you wanted a very rudimentary way of referring to it.

It’s not flashy. It’s not fun. But it tells investors: “Here’s what we really make once the accounting fog clears.” and “Are we generating real profits from our actual operations?”

EBITDA is what investors look at because it is the best way of comparing apples to apples when considering startups. EBITDA can provide investors a measure of your operational health.

A negative EBITDA for an early stage company isn't going to raise any eyebrows. Just don’t act surprised when someone brings it up. You need to do that math before the pitch. But, if you have a growing early stage company that's moving from negative EBITDA to positive? Now your getting into grown folks business.

Here’s a video that explains the basics of EBITDA.

And here’s another video that explains how investors look at EBITDA and its value in determining your business’s worth.

10. Valuation: What’s Your Company Worth – and What Supports that Number?

Valuation is a focused exercise that determines the value of an asset, investment, or company. So, how much your company’s worth. And the goal is typically to determine whether that value is a fair value.

Valuations can be conducted in one of two ways:

• an absolute valuation, which evaluates a company on its own merits and entirely independently of other factors/companies, or

• a relative valuation, which evaluates the company relative to other similar firms, or assets, in the same sector or industry. This determines if the company, or asset, is worth that much relative to others.

Depending on how the analysis and conclusions are reached, there are a variety of methods and techniques used to develop valuations. And as you’d expect, there’s often significant variability between outputs (or valuations) based on the inputs and context.

While valuations are predominantly quantitatively driven, there’s often a significant subjective influence that come from the assumptions and estimates made along the way. Valuations are also subject to developing situations and events outside of the analysis or the control of the analyst – for example, earnings reports or material news, or economic news – that can result in a change to a valuation stance.

If you’re pre-revenue and you’re saying $30M because a friend raised at that, please stop. Their experience likely has nothing to do with yours.

Valuation = traction + market comps + revenue + momentum + team.

Valuation isn’t just about what you want – it’s about what you can defend.

Startups are typically valued using:

• Comparable Analysis (Comps): What similar companies are worth

• Discounted Cash Flow (DCF): Projecting future cash and discounting it back

• Revenue Multiples: Often 5x–10x for SaaS, but varies wildly

• Precedent Transactions: What investors paid in past rounds for similar startups

But that’s the math.

Here’s the messy truth: Valuation = Traction + Team + TAM (total addressable market) + Timing + Storytelling.

Hard factors:

• MRR/ARR

• Growth rate

• Churn

• CAC:LTV

• Gross margins

Soft factors:

• Founding team’s track record

• Market momentum

• Hype or scarcity

Don’t inflate. Don’t anchor to your friend’s raise. Know your comps. And show why your model is defensible, not just desirable. Inflated numbers make investors run. They don’t correct you – they just ghost you.

There are numerous books written on valuation and each technique could be its own PhD. But my role here is to give you a sneak peak into the metrics.

Here’s a basic video on valuation if you’re interested in a deeper dive.

And here’s a more detailed video course outlining different forms of valuation. Professor Damodaran from New York University is considered to be one of the aces and thought leaders when it comes to valuation. In this video course he explains stepwise and beautifully so you can understand and explore the fascinating world of valuations.

Real Talk Before You Close That Tab

Real Experience

I met a founder once – early days, rough product, but you could tell he actually cared. He wasn't trying to look good. No buzzwords. No "disrupt" talk. Just someone trying to solve something annoying and important.

He walked into the room with a twinkle. Not swagger – just that gentle intensity. We were leaning in.

Then, in the middle of the pitch, someone asked, "So what's your monthly burn?" And I swear to you, he said, "Umm... I think my co-founder has that. I haven't looked in a while."

That was it.

No freak out. No awkward pause. Just... a cluck. Like a window closing in the background.

The product? Still smart. But the moment? Gone.

Nobody was mad. Nobody laughed. We even said thank you. But nobody followed up.

Why? Because it didn't feel like a business. It felt like a maybe.

Why This Matters

I’ve seen so many versions of that same scene play out. It’s never about charisma. It’s not even about the idea, half the time.

It’s about whether the person asking for money actually knows what they’re building. Not the dream, the mechanics. The guts, nuts and bolds of the business. The ugly Excel math nobody brags about on Twitter.

Unfortunately, no simple pitch deck will do that part for you. No co-founder can answer those questions on your behalf.

If it’s your vision, own the math. If it’s your company, learn the cost of keeping it alive.

The rest? The logos, the taglines, the “go-to-market” plans?.... All of that’s just packaging.

And you don’t have to be perfect either. You just have to be in it. Eyes open. Numbers in your head.
Because if you’re asking people to believe in what you’re building, you’d better believe in the scaffolding holding it up.

So yeah, know your CAC. Your LTV. Your margins. Your churn. Not to check some box on an investor’s sheet, but to prove to yourself and the investor that the thing you’re spending your life on…has legs. That it can stand. And run.

And maybe, someday, outlast you. Maybe!

Conclusion and Final Thoughts

I hope this was helpful to you, especially if you’re a founder or aspiring founder trying to build the next big thing. While there a many more ratios and concepts, these are the crux of them.

A lot of other complex ratios and valuations are either built using these metrics or refer them in some way. And each of these metrics could be an article of its own. But I wanted to give you my top 10 run down so that you could get a head start. Numbers are very much a part of the ideation stage itself, and omitting them from your strategy could prove to be a fatal mistake.

I’ll leave you with one last video on How to Start a Start Up with Michael Seibel (Reddit, YC, Twitch) that I hope you find valuable. It lays out, in a crash course format, the mindset of a founder who has been there and done that. The fun fact is that a lot of the themes he speaks of tie in to the metrics here, directly or indirectly.

I hope this gives you a perspective of being on the other side, evaluating your hard work and passion, and I hope it sets you up for success in your next Investor Review.

I look forward to your thoughts, comments, and feedback. If this was helpful, engaging, and informative, do share it – you never know who may need it, or could benefit from it. I wish you all the very best in your funding rounds.

Until then, keep learning, unlearning, and relearning, folks.

But to be sure that your model is doing well in its predictions, you need to evaluate the model.

There are some evaluation metrics that can help you determine whether the model’s predictions are accurate to a certain level of performance.

In this tutorial, you will learn the top evaluation metrics for regression problems, as well as when to use each of them. Without further ado let’s get started.

What are Residuals?

Before we get into the top evaluation metrics, you need to understand what "residual" means when you're evaluating a regression model.

It is not ideal or possible for a model to accurately predict the value of a continuous variable in a regression problem. A regression model can only predict values that are lower or higher than the actual value. As a result, the only way to determine the model’s accuracy is through residuals.

Residuals are the difference between the actual and predicted values. You can think of residuals as being a distance. So, the closer the residual is to zero, the better our model performs in making its predictions.

Here's the formula for calculating residuals:

In the above formula:

ei -- stands for the residual value.
yi -- stands for the actual value.
y^i -- stands for the predicted value.

So say, for instance, that the actual value in the dataset is 5 and the predicted value is 8. The residual value will be -3.

Top Evaluation Metrics for Regression Problems

The top evaluation metrics you need to know for regression problems include:

R2 Score

The R2 score (pronounced R-Squared Score) is a statistical measure that tells us how well our model is making all its predictions on a scale of zero to one.

As mentioned above, it's not ideal for a model to predict the actual values in a regression problem (as opposed to a classification problem that has discrete levels of value).

But we can use the R2 score to determine the accuracy of our model in terms of distance or residual. You can calculate the R2 score using the formula below:

When to Use the R2 Score

You can use the R2 score to get the accuracy of your model on a percentage scale, that is 0–100, just like in a classification model.

Let’s go over how to implement the R2 score in Python. So we have a small dataset that contains the actual values and the predictions.

To implement the R2 score in Python we'll leverage the Scikit-Learn evaluation metrics library.

from sklearn.metrics import r2_score
score = r2_score(data["Actual Value"], data["Preds"])
print("The accuracy of our model is {}%".format(round(score, 2) *100))

The r2_score requires two parameters – the actual value and the predicted values in which we have passed to it above. The result from the metrics is this:

So we can say that our model predicted those values with 82% accuracy.

Mean Absolute Error (MAE)

The MAE is simply defined as the sum of all the distances/residual s(the difference between the actual and predicted value) divided by the total number of points in the dataset.

It is the absolute average distance of our model prediction.

You can calculate the MAE using the following formula:

We can see that the above formula has two pipelines represented by the absolute symbol. The absolute symbol makes sure that the negative residual (which may be a result where the predicted value is greater than the actual value) is converted to positive so that it doesn’t cancel out other positive residuals.

When to Use MAE

If you want to know the model’s average absolute distance when making a prediction, you can use MAE. In other words, you want to know how close the predictions are to the actual model on average.

Just keep in mind that low MAE values indicate that the model is correctly predicting. Larger MAE values indicate that the model is poor at prediction.

Let’s now see how to implement MAE in Python. We will be working with the previous dataset we used to find the r2_score.

To implement the MAE in Python we'll leverage the Scikit-Learn evaluation metrics library.

from sklearn.metrics import mean_absolute_error
score = mean_absolute_error(data["Actual Value"], data["Preds"])
print("The Mean Absolute Error of our Model is {}".format(round(score, 2)))

MAE also requires two parameters, the actual value and the predicted value.

Root Mean Squared Error (RMSE)

Another commonly used metric is the root mean squared error, which is the square root of the average squared distance (difference between actual and predicted value).

RMSE is defined as the square root of all the squares of the distance divided by the total number of points.

RMSE functions similarly to MAE (that is, you use it to determine how close the prediction is to the actual value on average), but with a minor difference.

You use the RMSE to determine whether there are any large errors or distances that could be caused if the model overestimated the prediction (that is the model predicted values that were significantly higher than the actual value) or underestimated the predictions (that is, predicted values less than actual prediction).

When to Use RMSE

If you are concerned about large errors, RMSE is a good metric to use. If the model overestimated or underestimated some points in the prediction (because the residual will be square, resulting in a large error), you should use RMSE.

RMSE is a popular evaluation metric for regression problems because it not only calculates how close the prediction is to the actual value on average, but it also indicates the effect of large errors. Large errors will have an impact on the RMSE result.

Let’s take a look at how you can implement RMSE in Python.

The Scikit-learn evaluation metric library has no RMSE metric, but it does include the mean squared error method. The square root of the mean squared error is referred to as RMSE.

To get the RMSE, we can use the Numpy square root method to find the square root of mean squared error, and the result obtained is our RMSE.

from sklearn.metrics import mean_squared_error
import numpy as np
score = np.sqrt(mean_absolute_error(data["Actual Value"], data["Preds"]))
print("The Mean Absolute Error of our Model is {}".format(round(score, 2)))

We can see that the RMSE value is larger than the MAE. This is a result of some large errors in the dataset.

Conclusion and Learning More

In this tutorial you’ve learned some of the top evaluation metrics for regression problems that you will use on a daily basis.

Thank you for reading. Here are some helpful resources I also included below.

MAE and RMSE — Which Metric is Better? | by JJ | Human in a Machine World | Medium

Google Search Console is a web service by Google that lets you see the indexing and performance of your websites and webpages on Google search.

At a high level, the search console is a powerful tool to confirm that your website is ranking and that Google can access your website.

You can check and set the crawl rate and view statistics about where your traffic is landing and where you are acquiring traffic from.

The console, like many other web dev tools, is robust and powerful. If you are building your first website you should take time to understand it, play around with it, and learn to leverage it.

This tutorial walks you through the basics of this tool, and can be a useful guide to help you save time when learning which metrics matter for your site’s performance and how you can leverage this data to build better products.

I have lived in the search console for the past six months because I built a website and I care deeply about how people find the content that I write.

Prior to my experience building this site, I was not a regular user of the Search Console. I had to learn about this tool, including what it could do to help me better understand my users and their intent when landing on my website.

I have learned three important lessons about the Search Console’s Performance section and want to pass those lessons on to you.

Lesson #1: Know the source of your traffic: Search vs Discover

Google gives you two ways to see how people are reaching your website through Search: via Search results or via Discover.

“Discover” (previously known as Google Feed) is a personalized content feed created by Google that proactively serves relevant content to users. You can’t nominate your content for Discover. If Google thinks that your website is relevant to users, Google will show it to people.

The other type of performance metric, and one that is seemingly far larger, is “Search results”. Search results shows a webmaster four vital pieces of information:

1. Total clicks
2. Total impressions
3. Average CTR (Click Thru Rate)
4. Average Position

Discover provides the same information with the exception of Average Position because there are no relative ranking positions within this metric.

When learning to use the Search Console, spend time looking at traffic through the lens of Search and Discover. If you do not see Discover traffic, that means your content has not yet been shown via Discover to users.

When starting a website or blog, you will want users to find your content. Search and discover are the two organic ways that people will do so. Know how many people find you via each.

Lesson #2: Study your average position

When I first started using the Search Console I was amazed (and happy) that I was getting any traffic at all! Over time, your clicks will increase if you are publishing relevant and useful content.

As more people find your website and the site gets more impressions, clicks will go up.

You might be tempted to pat yourself on the back and call it a day. Not so fast!

Each page that you publish on your website is eligible to appear on Google search if you want that page to be crawled and indexed.

Some of your pages will perform very well (that is, they'll land on the first page of Google) and others will land further down (like on the 12th page where nobody will see them).

Over time you will want to monitor and track your average position and find ways to increase your average position by producing higher quality and more relevant content that benefits readers.

Here is a simple strategy to see your average position over time: create articles of similar length, quality, and usefulness to readers.

Then, come back over the ensuing weeks and months and see which ones are starting to rank and what their relative positions are. This strategy is deployed by review sites, thought leadership posts, and even online coding schools.

When I started my first website my average position was around 60. That means that 59 other websites showed up before mine.

Today, that average position is 26.8. Clearly I have a long way to go but it's a step in the right direction. Be aware of this metric and spend time tracking it.

Source: https://wfhadviser.com/

Lesson #3: Impressions are the top of the funnel

Regardless of the type of website you have - blog, educational, e-commerce, recreational - you will want traffic.

Traffic is just another way of saying unique visitors. Depending on what your website has to offer, you might value certain types of traffic more than others: by region, country, age of users, device operating system, and so on.

But as you focus in on clicks and performance, it all starts with impressions. An impression is counted each time your webpage is shown on a search result page.

In other words, impressions are the top of the funnel. You will need to grow impressions first in order to grow all other metrics.

A word of caution that I have discovered the hard way. If your website is on the lower part of the search results, an impression might count even if the user doesn’t scroll all the way down.

In other words, the way Google counts an impression is seemingly slightly different from how a person might count it. In layperson's terms (that is, not technology) an impression is when you actually see something.

In Google’s terms, an impression is when your website is on a results page and the user sees the results page. In short, scrolling doesn’t seem to impact impression counts.

Bringing It All Together: Know How Your Users Reach Your Website To Build Better Products

If you want to build a product, you always need to know how your users learned about your product and what they value most. Builders start with the customer and work backwards.

Google’s Search Console is a terrific tool to understand one aspect of the user journey to better align your product, your messaging, and your value-prop with the needs of your clients.

You can use the Performance section of the Search Console to obsess over customers and how they reach you.

Google makes it easy to test this in real time so that your feedback loop is minimal: you can review the crawled page automatically or promagically.

Growing SaaS, a company that notes that SEO is one of the core user acquisition strategies for companies, also convincingly argues that if you don't know where, what, how, or why to measure traffic, you will be missing guidance as to what to build and for whom.

If you build any product - a website, a mobile app, or a tool for Enterprises - you need to know how people hear about your product and reach you.

Imagine if you built a newsletter but had no idea how your email list grew over time or what your subscribers valued most? Sounds crazy, right? That is akin to building a site and not mastering the Search Console.

Certainly this would be a suboptimal situation for any coder or creator.

Builders are never done learning.

The Search Console gives you data and visual guidance on ways to improve your website and customer acquisition. By being curious about new possibilities and acting to explore them, you can do a better job building.

And Google reinforces this by helping guide you along the way. These green circles and checks confirm that the site has live pages and that are properly indexed. It's always a nice plus when the visual design helps the builders :)

Builders not only index on what is going well - and how to improve these trends - but what is not working so that they can course correct. Google’s search console, like other online tools, helps users see broken links and error pages, pages that need improvements, and site speed.

If you were looking at hundreds of pieces of paper in a book - or bulk emails - or thousands of indexed web pages, you need to leverage a tool to understand the data in front of you.

The Search Console is just that.

It is free to use and fast to deploy. It is important to use and critical to master - your product and users will be better served if you leverage it.

In my previous article, I wrote about metrics and how they help you gain visibility into the operational health of your hardware and software systems.

Wavefront is a high-performance streaming analytics platform that supports 3D observability (metrics, histograms, traces/spans).

It can scale to very high data ingestion rates and query loads. You can collect data from many services and sources across your entire application stack, and can look at details for earlier data collected by Wavefront.

Terraform is an open-source “Infrastructure as Code” tool, created by HashiCorp.

It is a declarative coding tool and enables developers to use a high-level configuration language called HCL (HashiCorp Configuration Language) to describe the desired “end-state” for the infrastructure.

This infrastructure can be on the cloud or on-premises. It then generates a plan for reaching that end-state and executes the plan to create the infrastructure.

In this article, we will take a look at how we can use Terraform to write code that will automatically build dashboards and alarms in Wavefront. This is really helpful in maintaining a DevOps culture in your team, where all the monitoring infrastructure is maintained as code and checked into your version control system such as GitHub.

How to Install Terraform

Depending on your OS, the installation instructions for Terraform will vary. This article covers the instructions for installing it on macOS.

The recommended approach for installing it on macOS is to use the Homebrew package manager.

Install Terraform

Verify that you have Homebrew installed, like this:

$ brew --version

Homebrew/homebrew-core (git revision fe68a; last commit 2020-10-15)
Homebrew/homebrew-cask (git revision 4a2c25; last commit 2020-10-15)

If not, you can install Homebrew using the following command:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Next, install Terraform using the following commands:

$ brew tap hashicorp/tap
$ brew install hashicorp/tap/terraform

Verify Terraform Installation

To verify that Terraform is properly installed, open another terminal session, and try a Terraform command.

$ terraform --help

Usage: terraform [global options] <subcommand> [args]

The available commands for execution are listed below.The primary workflow commands are given first, followed byless common or more advanced commands.

How to Get an API Token

To allow Terraform to access your Wavefront installation, you will need to provide it an access token. This token can be found in the API tokens section of your account.

Go to Gear Icon > Account Name > API Access

Getting your Wavefront API Token

How to Setup a Terraform Project

First, create a new folder for your Terraform project:

$ mkdir wavefront-terraform

A usual Terraform project contains 3 major files:

1. versions.tf — this contains the Terraform provider declaration that specifies the plugin version to be used
2. variables.tf — this contains the variables that you can refer to in your main Terraform code
3. main.tf — as the name suggests, this contains the actual code required to build the resources

Create a versions.tf file in the project folder and add the following code:

Next, run the terraform init command to initialize the Wavefront provider:

$ terraform init

This downloads the terraform-wavefront-provider-<version> file and puts it inside a.terraform folder in the current project folder.

Next, create a main.tf file in the project folder and add the following code:

With the setup completed, we are now ready to create some dashboards and alerts.

How to Create Wavefront Dashboards

Before we jump into creating dashboards, let us first understand the anatomy of a Wavefront dashboard.

Anatomy of a Wavefront Dashboard

A dashboard in Wavefront consists of 5 types of entities:

• Dashboard — This is the main dashboard and contains all other entities.
• Section — A dashboard can contain one or more sections. A section is a logical group of charts. For example you can have one section for displaying charts related to hardware utilization, and another section for displaying charts related to API calls.
• Row — A row is a collection of charts. You can define the number of charts you want to be present in a row. My personal recommendation is to have 3 charts in a row. Anything more than that clutters the dashboard.
• Chart — This is the final chart that displays the metrics on the dashboard. There are various options for creating charts like line charts, bar charts, pie charts, and so on.
• Source — A chart can contain one or more sources. Each source has a query that works on an underlying metric to create a visual representation on the chart.

Now we are ready to write some code to create a dashboard. Add the following code to the main.tf file:

This creates a dashboard with one section for EC2 Metrics. There is one row in this section with two charts. One chart displays CPU Utilization and the other displays Memory Utilization. Both of them are line charts and show the percentage of usage.

How to Create Alerts

The dashboard we created is great to look at the CPU and Memory utilization of our EC2 instances. But if we want to be notified when the CPU or memory utilization increases beyond a certain threshold, we need to set up some alerts.

To create an alert on CPU Utilization, add the following code to the main.tf file:

This creates two resources:

1. An alert target that sends an email to the specified address whenever an alert is opened or resolved.
2. An alert on CPU Utilization that fires when the CPU utilization crosses the given threshold (a WARN alert when it goes over 60% and a SEVERE alert when it goes over 80%).

Wavefront continuously monitors the CPU utilization and sends a notification to the email address when the threshold is breached. Similarly, when the utilization becomes normal, it sends another notification indicating that things have recovered.

How to Generate Resources in Wavefront

The code for creating our resources is ready. Now we need to apply them so that the actual resources are created on Wavefront.

To view what changes will be made to Wavefront by our code, run the following command:

$ terraform plan

This will verify our code and show the difference between the current setup in Wavefront, and the changes that will happen due to your code.

Finally, to create the resources on Wavefront, run the following command:

$ terraform apply -auto-approve

This will upload the configuration to Wavefront and create the actual dashboard and alert. You can now go to Wavefront and verify these resources.

Conclusion

Congratulations! You just created a new Wavefront dashboard and alert through code.

You can now go ahead and make any modifications to your code, and run terraform apply -auto-approve to apply your changes to Wavefront.

Terraform is a great way to maintain your resources in the form of code that can be checked into your version control system. This allows multiple developers to work on your resources while also keeping track of the changes.

The full source code for this tutorial can be found here.

Thank you for staying with me so far. Hope you liked the article. You can connect with me on LinkedIn where I regularly discuss technology and life. Also take a look at some of my other articles. Happy reading. 🙂

In my previous article, I talked about the importance of logs and the differences between structured and unstructured logging.

Logs are easy to integrate into your application, and they give you the ability to represent any type of data in the form of strings.

Metrics, on the other hand, are numerical representations of data. These are often used to count or measure a value and are aggregated over a period of time.

Metrics give us insights into the historical and current state of a system. Since they are just numbers, we can also use them to perform statistical analysis and predictions about the system’s future behaviour.

You can also use metrics to trigger alerts and notify you about issues in the system’s behaviour.

Logs vs. Metrics

How Logs and Metrics are Formatted

Logs are represented as strings. They can be simple text, JSON payloads, or key-value pairs (like we discussed in structured logging).

A typical log entry looks like this:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in fetching product information - Product Not Available

Metrics are represented as numbers. They measure something (like CPU usage, number of errors, and so on) and are numeric in nature.

A typical metric looks like this:

{class=InventoryValidator, exception=Product Not Available, timestamp=1609306200}

The Resolution of Logs and Metrics

Logs contain high-resolution data. This includes complete information about an event and can be used to correlate the flow (or path) that the event took through the system.

In case of errors, logs contain the entire stack trace of the exception, which allows us to view and debug issues originating from downstream systems as well.

A log entry showing the stacktrace of an error

In short, logs can tell you what happened in the system at a certain time.

Metrics contain low-resolution data. This may include a count of parameters (such as requests, errors, and so on) and measures of resources (such as CPU and memory utilization).

A Metric showing number of hits to a service

In short, metrics can give you a count of something that happened in the system at a certain time.

The Cost of Logs and Metrics

Logs are expensive to store. The storage overhead of logs also increases over time and is directly proportional to the increase in traffic.

Metrics have a constant storage overhead. The cost of storage and retrieval of metrics does not increase too much with the increase in traffic. It is, however, dependent on the number of variables we emit with each metric.

Cardinality of Metrics

Metrics are identified by two key pieces of information:

• A metric name
• A set of key-value pairs called tags or labels

A permutation of these values provides the metric its cardinality. For example, if we are measuring the CPU utilization of a system with three hosts, the metric has a cardinality value of 3 and can have the following three values:

(name=pod.cpu.utilization, host=A)
(name=pod.cpu.utilization, host=B)
(name=pod.cpu.utilization, host=C)

Similarly, if we introduced another tag in the metric that determined the AWS region of the hosts (say, us-west-1 and us-west-2), we would now have a metric with a cardinality value of 6.

Types of Metrics

Golden signals

Golden signals are an effective way of monitoring the overall state of the system and identifying problems.

• Availability: State of your system measured from the perspective of clients (for example, the percentage of errors on total requests).
• Health: State of your system measured using periodic pings.
• Request Rate: Rate of incoming requests to the system.
• Saturation: How free or loaded the system is (foe example, the queue depth or available memory).
• Utilization: How busy the system is (for example, CPU load or memory usage). This is represented as a percentage.
• Error Rate: Rate of errors being produced in the system.
• Latency: Response time of the system, usually measured in the 95th or 99th percentile.

Resource metrics

Resource metrics are almost always made available by default from the infrastructure provider (AWS CloudWatch or Kubernetes metrics) and are used to monitor infrastructure health.

• CPU/Memory Utilization: Usage of the system’s core resources.
• Host Count: Number of hosts/pods that are running your system (used to detect availability issues due to pod crashes).
• Live Threads: Threads spawned in your service (used to detect issues in multi-threading).
• Heap Usage: Heap memory usage statistics (can help debug memory leaks).

Business metrics

Business metrics can be used to monitor granular interaction with core APIs or functionality in your services.

• Request Rate: Rate of requests to the APIs.
• Error Rate: Rate of errors being thrown by the APIs.
• Latency: Time taken to process requests by the APIs.

Dashboards and Alerts for Metrics

Since metrics are stored in a time-series database, it’s more efficient and reliable to run queries against them for measuring the state of the system.

You can use these queries to build dashboards for representing the historical state of the system.

A Wavefront dashboard with some important metrics

They can also be used to trigger alerts when there is an issue with the system (like an increase in the number of errors observed or a sudden spike in CPU utilization).

Due to their numeric nature, we can also create complex mathematical queries (such as X% of errors in last Y minutes) to monitor system health.

The biggest challenge, however, in handling metrics is deciding the right amount of cardinality that makes the metric useful while also keeping its costs under control.

Emitting too many metrics, or metrics with too many dimensions, can lead to an increase in storage and processing costs. You need to choose the minimum cardinality that is just enough to give a high level picture about the system.

How to Use Logs and Metrics

Both logs and metrics have their own pros and cons. However, in any production system, we need to use both logs and metrics together to effectively monitor the system and debug any issues.

Metrics are often the first line of sight into the health of a system. Let's take the example of an e-commerce application like Amazon. The most important metric for such a use-case is the total number of successful and failed orders.

On a normal day, the metric for number of failed orders would remain at zero or some very small number. If there is an issue in the system that causes orders to suddenly start failing, this metric will show an increase in count.

You can create an alert on a combination of two metrics - total orders and failed orders. This will allow you to send a notification when the percentage of failed orders increases beyond a certain threshold (say 5%).

Once you are notified about the failing orders, you can then refer to the logs to find the cause of the failures. The logs would contain the error messages leading to the failure, as well as the detailed stacktrace that can identify the root cause of the failure.

Conclusion

In this article, we saw the differences between metrics and logs, and how metrics can help us monitor the health of our system more efficiently. Metrics can also be used to create dashboards and alerts using monitoring software like Wavefront and Grafana.

It is also necessary to use both metrics and logs in coordination to accurately detect and debug issues.

Thank you for staying with me so far. Hope you liked the article. You can connect with me on LinkedIn where I regularly discuss technology and life. Also take a look at some of my other articles on Medium. Happy reading 🙂

The story began while I was optimizing a landing page on my Bootstrap IT website for my new book, Keeping Up: Backgrounders to all the big technology trends you can't afford to miss.

I wanted to provide access to the PDF file of a sample chapter from the book. But I also wanted some way to know how many people actually downloaded it.

Now let's take a step back. Google Analytics is a free service that uses code snippets inserted into your HTML files to collect and display data on how often your files were accessed.

The magic - and problem - of Google Analytics is in just how much information about your users can be revealed. I discussed some of the privacy concerns involved with the service in the Keeping Up book. I also mentioned how I feel at least a bit guilty for using the service myself on my own sites.

At any rate, all by itself, Google Analytics isn't able to tell you much about how your web-based PDFs are being used. Of course, there are tricks for getting around the problem.

Traditional approaches include setting up the Google Tag Manager, customizing the syntax of the request URLs you use or, if your site uses WordPress software, working with the Monster Insights plugin. Each of those can work, but will require a fairly steep learning curve.

But I'm a Linux sysadmin. And, as I never fail to remind the people around me, the best sysadmins are lazy. Learning curve? That sounds suspiciously like work. Not gonna happen on my watch.

So here's the deal. My web server, obviously, runs Linux. And, under the hood, HTTP traffic is handled by Apache. That means that everything happening to and on my websites is going to be logged by Apache.

Everything. All it'll take to give me what I need to know about what my PDF sample chapter has been up to, is a single line of Bash run from my local workstation:

echo "cd /var/log/apache2 && grep -nr KeepingUpSampleChapter" \
   | ssh -i PrivateKey.pem LoginName@bootstrap-it.com

Let's break that down. The first of the two commands in quotation marks (cd /var/log/apache2) will move us to the /var/log/apache2/ directory on the Linux server where Apache writes its logs. That's not rocket science.

There are going to be multiple files of interest in that directory. That's because messages relevant to regular access and errors are saved to different files, and because file rotation policies mean that there could be more than one version of either of those files, too. So I'll use grep to search all the uncompressed files for the KeepingUpSampleChapter string. KeepingUpSampleChapter is, of course, part of the filename of the PDF.

I then pipe that command to SSH, which will connect to my remote server and execute the command. Here's what a single entry would look like from a successful run (I've removed the requester's IP address out of privacy concerns):

other_vhosts_access.log.1:12200:bootstrap-it.com:443 <requester's IP Address> - - [01/Dec/2020:16:39:36 -0500] "GET /davidclinton/KeepingUpSampleChapter.pdf?pdf=SamplePDF HTTP/1.1" 200 65146 "https://bootstrap-it.com/davidclinton/keeping-up/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36"

We can see:

• The log file where the entry appeared (other_vhosts_access.log.1)
• The requester's IP address (redacted)
• The timestamp telling us exactly when the file was accessed
• The relative location of the file on the server file system (/davidclinton/KeepingUpSampleChapter.pdf)
• The URL from which the request was made (https://bootstrap-it.com/davidclinton/keeping-up/)
• And the browser the user was running

That's a lot of information. If we're just curious about how many times the file was downloaded, we can simply pipe the output to the wc command that will tell us three things about the output: the number of lines, words, and characters it contained. That command would look like this:

echo "cd /var/log/apache2 && grep -nr KeepingUpSampleChapter | wc" \
   | ssh -i PrivateKey.pem LoginName@bootstrap-it.com

There is one possible limitation with this method. If your website is busy, the log files will roll over frequently, often more than once a day. By default, after the first rollover, the files are compressed using the gz algorithm, which can't be read by grep.

The zgrep command won't have any trouble handling such files, but the process could end up taking a very long time. You might consider writing a simple custom script to decompress each gz file and then run regular grep against its contents. That'll be your project.

There's much more administration goodness in the form of books, courses, and articles available at my bootstrap-it.com.

One of the coolest things I have learned in the last year is how to constantly deliver value into production without causing too much chaos.

In this post, I’ll explain the metrics-driven development approach and how it helped me to achieve that. By the end of the post, you’ll be able to answer the following questions:

• What are metrics and why should I use them
• What are the different types of metrics
• What tools could I use to store and display metrics
• What is a real-world example of metrics-driven development

What are metrics and why should I use them?

Metrics give you the ability to collect information on an actively running system without changing its code.

It allows you to gain valuable data on the behavior of your application while it runs so you can make data-driven decisions based on real customer feedback and usage in production.

What are the types of metrics available to me?

These are the most common metrics used today:

• Counter — Represents a monotonically increasing value.

Counters are really useful for measuring rates!

In this example, a counter metric is used to calculate the rate of events over time, by counting events per second

• Gauge — Represents a single value that can go up or down.

Gauges are really useful for measuring CPU usage!

In this example, a gauge metric is used to monitor the user CPU in percentages

• Histogram — A counting of observations (like request durations or sizes) in configurable buckets.

Histograms are really useful for measuring request duration!

In this example, a histogram metric is used to calculate the 75th and 90th percentiles of an HTTP request duration.

The bits and bytes of the types: counter, histogram, and gauge can be quite confusing. Try reading about it further here.

What tools can I use to store and display metrics?

Most monitoring systems consist of a few parts:

1. Time-series database — A database software that optimizes storing and serving time-series data. Two examples of this kind of database are Whisper and Prometheus.
2. Querying engine (with a querying language) — Two examples of common query engines are: Graphite and PromQL
3. Alerting system — The mechanism that allows you to configure alerts based on graphs created by the querying language. The system can send these alerts to Mail, Slack, PagerDuty. Two examples of common alerting systems are: Grafana and Prometheus.
4. UI — Allows you to view the graphs generated by the incoming data and configure queries and alerts. Two examples of common UI systems are: Graphite and Grafana

The setup we are using today in BigPanda Engineering is

• Telegraf — used as a StatsD server.
• Prometheus — used as our scrapping engine, Time-series database and querying engine.
• Grafana — used for Alerting, and UI

And the constraints we had in mind while choosing this stack were:

• We want scalable and elastic metrics scraping
• We want a performant query engine
• We want the ability to query our metrics using custom tags(such as service names, hosts, etc.)

A real-world example of Metrics-driven development of a Sentiment Analysis service

Let’s develop a new pipeline service that calculates sentiments based on textual inputs and does it in a Metrics Driven Development way!

Let’s say I need to develop this pipeline service:

Sentiment analysis pipeline architecture

And this is my usual development process:

Usual development process - Test, code and deploy. Oh my!

So I write the following implementation:

let senService: SentimentAnalysisService = new SentimentAnalysisService();
while (true) {
    let tweetInformation = kafkaConsumer.consume()
    let deserializedTweet: { msg: string } = deSerialize(tweetInformation)
    let sentimentResult = senService.calculateSentiment(deserializedTweet.msg)
    let serializedSentimentResult = serialize(sentimentResult)
    sentimentStore.store(sentimentResult);
    kafkaProducer.produce(serializedSentimentResult, 'sentiment_topic', 0);
}

The full gist can be found here.

And this method works perfectly fine**.

But what happens when it doesn’t?

The reality is that while working (in an agile development process) we make mistakes. That’s a fact of life.

I believe that the real challenge with making mistakes is not to avoid them, but rather to optimize how fast we detect and repair them. So, we need to gain the ability to quickly discover our mistakes.

It's time for the MDD-way.

The Metrics Driven Development (MDD) way

Behold! The Three Commandments of Production!

The MDD approach is heavily inspired by the Three Commandments of Production (which I had learned about the hard way).

The Three Commandments of Production are:

1. There are mistakes and bugs in the code you write and deploy.
2. The data flowing in production is unpredictable and unique!
3. Perfect your code from real customer feedback and usage in production.

And since we now know the Commandments, it's time to go over the 4 step plan of the Metrics-Driven development process.

The 4-step plan for a successful MDD

Metrics-driven development ?Oh wow!

Develop code 

I write the code, and whenever possible, wrap it with a feature flag that allows me to gradually open it for users.

Metrics

This consists of two parts:

Add metrics on relevant parts

In this part, I ask myself what are the success or failure metrics I can define to make sure my feature works? In this case, does my new pipeline application perform its logic correctly?

Add alerts on top of them so that I’ll be alerted when a bug occurs

In this part, I ask myself What metric could alert me if I forgot something or did not implement it correctly?

Deployment

I deploy the code and immediately monitor it to verify that it’s behaving as I have anticipated.

Iterate this process to perfection

And that's it! Now that we have learned the process, let's tackle an important task inside it.

Metrics to Report — what should we monitor?

One of the toughest questions for me, when I’m doing MDD, is: “what should I monitor”?

That’s a lovely gif. but un-realistic in most cases.

In order to answer the question, lets try to zoom out and look at the big picture.
All the possible information available to monitor can be divided into two parts:

1. Applicative information — Information that has an applicative context and meaning. An example of this will be — “How many tweets did we classify as positive in the last hour”?
2. Operational information — Information that is related to the infrastructure that surrounds our application — Cloud data, CPU and disk utilization, network usage, etc.

Now, since we cannot monitor everything, we need to choose what applicative and operational information we want to monitor.

• The operational part really depends on your ops stack and has built-in solutions for (almost) all your monitoring needs.
• The applicative part is more unique to your needs, and I'll try to explain how I think about it later in this post.

After we do that, we can ask ourselves the question: what alerts do we want to set up on top of the metrics we just defined?

The diagram (of information, metrics, alerts) can be drawn like this:

The world of information, metrics, and alerts.

Applicative metrics

I usually add applicative metrics out of two needs:

To answer questions

A question is something like, “When my service misbehaves, what information would be helpful to know about?”

Some answers to that question can be — latencies of all IO calls, processing rate, throughput, etc…

Most of these questions will be helpful while you are searching for the answer. But once you found it, chances are you will not look at it again (since you already know the answer).

These questions are usually driven by RND and are (usually) used to gather information internally.

To add Alerts

This may sound backward, but I usually add applicative metrics in order to define alerts on top of them. Meaning, we define the list of alerts and then deduce from them what are the applicative metrics to report.

These alerts are derived from the SLA of the product and are usually treated with mission-critical importance.

Common types of alerts

Alerts can be broken down into three parts:

Alerts types to Metrics list

SLA Alerts

SLA alerts in reality

SLA alerts surround the places in our system where an SLA is specified to meet explicit customer or internal requirements (i.e availability, throughput, latency, etc.). SLA breaches involve paging RND and waking people up, so try to keep the alerts in this list to a minimum.

Also, we can define Degradation Alerts in addition to SLA Alerts.
Degradation alerts are defined with lower thresholds then SLA alerts, and are therefore useful in reducing the amount of SLA breaches — by giving you a proper heads-up before they happen.

An example of an SLA alert would be, “All sentiment requests must finish in under 500ms.”

An example of a Degradation Alert will be: “All sentiment requests must finish in under 400ms”.

These are the alerts I defined:

1. Latency — I expect the 90th percentile of a single request duration not to exceed 300ms.
2. Success/Failure ratio of requests — I expect the number of failures per second, success per second, to remain under 0.01.
3. Throughput — I expect that the number of operations per second (ops) that the application handles will be > 200
4. Data Size — I expect the amount of data that we store in a single day should not exceed 2GB.

200 ops 60 bytes(Size of Sentiment Result) 86400 sec in a day = 1GB < 2GB

Baseline Breaching Alerts

These alerts usually involve measuring and defining a baseline and making sure it doesn’t (dramatically) change over time with alerts.

For example, the 99th processing latency for an event must stay relatively the same across time unless we have made dramatic changes to the logic.

These are the alerts I defined:

1. Amount of Positive or Neutral or Negative Sentiment tweets — If for whatever reason, the sum of Positive tweets has increased or decreased dramatically, I might have a bug somewhere in my application.
2. All latency \ Success ratio of requests \ Throughput \ Data size must not increase\decrease dramatically over time.

Runtime Properties Alerts

I’ve given a talk about Property-Based Tests and their insane strength. As it turns out, collecting metrics allows us to run property-based tests on our system in production!

Some properties of our system:

1. Since we consume messages from a Kafka topic, the handled offset must monotonically increase over time.
2. 1 ≥ sentiment score ≥ 0
3. A tweet should classify as either Negative \ Positive \ Neutral.
4. A tweet classification must be unique.

These alerts helped me validate that:

1. We are reading with the same group-id. Changing consumer group ids by mistake in deployment is a common mistake when using Kafka. It causes a lot of mayhem in production.
2. The sentiment score is consistently between 0 and 1.
3. Tweet category length should always be 1.

In order to define these alerts, you need to submit metrics from your application. Go here for the complete metrics list.

Using these metrics, I can create alerts that will “page” me whenever one of these properties do not hold anymore in production.

Processing latency breached configured SLA! Oh my! ?

Let’s take a look at a possible implementation of all these metrics

import SDC = require("statsd-client");
let sdc = new SDC({ host: 'localhost' });
let senService: SentimentAnalysisService; //...
while (true) {
    let tweetInformation = kafkaConsumer.consume()
    sdc.increment('incoming_requests_count')
    let deserializedTweet: { msg: string } = deSerialize(tweetInformation)
    sdc.histogram('request_size_chars', deserializedTweet.msg.length);
    let sentimentResult = senService.calculateSentiment(deserializedTweet.msg)
    if (sentimentResult !== undefined) {
        let serializedSentimentResult = serialize(sentimentResult)
        sdc.histogram('outgoing_event_size_chars', serializedSentimentResult.length);
        sentimentStore.store(sentimentResult)
        kafkaProducer.produce(serializedSentimentResult, 'sentiment_topic', 0);
    }

}

The full code can be found here

A few thoughts on the code example above:

1. There has been a staggering amount of metrics added to this codebase.
2. Metrics add complexity to the codebase, so, like all good things, add them responsibly and in moderation.
3. Choosing correct metric names is hard. Take your time selecting proper names. Here’s an excellent post about this.
4. You still need to collect these metrics and display them in a monitoring system (like Grafana), plus add alerts on top of them, but that’s a topic for a different post.

Did we reach the initial goal of identifying issues and resolving them faster?

YESSSS, it was!

We can now make sure the application latency and throughput do not degrade over time. Also, adding alerts on these metrics allows for a much faster issue discovery and resolution.

Conclusion

Metrics-driven development goes hand in hand with CI\CD, DevOps, and agile development process. If you are using any of the above keywords, then you are in the right place.

When done right, metrics make you feel more confident in your deployment in the same way that seeing passing unit-tests in your build makes you feel confident in the code you write.

Adding metrics allows you to deploy code and feel confident that your production environment is stable and that your application is behaving as expected over time. So I encourage you to try it out!

Some references

1. Here is a link to the code shown in this post, and here is the full metrics list described.
2. If you are eager to try writing some metrics and to connect them to a monitoring system, check out Prometheus, Grafana and possibly this post
3. This guy wrote a delightful post about metrics-driven development. GO read it.