Log or metric: how much observability a single-server system needs

Grafana released Workflows and expanded Adaptive Telemetry, Sentry explained the difference between a log and a metric, OpenTelemetry changed its versioning rules for the sake of security, and the CNCF blog showed how to trim the telemetry of an AI coding assistant. All of it is written for teams with dozens of services. The question of what to write to the log and what to count comes up for a single-server system too, and a business owner should know what they are paying for in monitoring.

What came out

On October 21, Grafana Labs introduced Grafana Workflows in public preview: a team's process turns into automated steps. The major incident kickoff template creates a Slack channel, finds the on-call incident commander from the schedule, pins the runbook and writes to the incident timeline. The ask Assistant step has their model put together an incident summary and separate observations from hypotheses. The on-call handoff report template builds a report on the week's incidents when the shift changes.

A day earlier, on October 20, Grafana described how Adaptive Telemetry separates the bill from the data volume. For traces: volumetric sampling splits the sampling budget between services and, by their tests, gives about 25% more useful information than random sampling of the same volume, and discarded traces stay available by ID for 24 hours. For logs: drop rules are applied right on the collectors, and anything you can't bear to lose goes to your cheap object storage, from where it can be brought back.

Sentry on October 22 answered the question of when you need a log and when you need a metric. Their version is short: logs are for debugging, metrics are for analysis. A log records what was true at the moment of the event, so you can reconstruct the picture later; a metric is for a number you watch over time, even when everything is fine. Traces are sampled, logs and metrics are not.

OpenTelemetry on October 22 updated its versioning policy: stable SDKs and Contrib components may now change behavior for security reasons in minor and patch releases, the public API stays untouched, and the release notes must explain what to change in the configuration.

The most practical text of the week: on October 22 the CNCF showed how to filter the telemetry of an AI coding assistant through the OpenTelemetry Collector. One small task for Claude Code produced 181 records and 289 KB of JSON. The author wrote out six questions: cost per model, tokens, which tools fail, where the latency is, what broke. Counters and short attributes answer all of them, while file bodies and prompts only take up space. Then the collector configuration: drop the api_request event, about a quarter of the records, remove six attributes, hash the identifiers and trim the hash to 16 characters, because a full SHA256 is longer than a UUID and after the first run the log volume grew.

Why this matters to a business

Take a greenhouse where controllers run the pumps and the irrigation. You could write every reading from every sensor to the log as text. Six months later the log weighs gigabytes, and the answer to why the pump didn't start at three in the morning yesterday isn't in it: the line about the pump drowned among temperature readings. It should be the other way around: water level and temperature are metrics, you build a chart and an alert threshold from them, and the moment the pump got a command and didn't respond is a log entry with a reason.

Observability is measured by the number of questions you can answer. If no chart and no alert reads a field, you are paying to store it for nothing.

How I do it

I have worked with a PDR company in the US since 2021 and monitor the infrastructure myself: a server on Debian in Google Cloud, VPN, network equipment and telephony. Grafana Workflows aren't needed there; there is one person on call, and it is me. What I did do, in 2025, was put a TV board on 4 televisions in the company, each with its own dashboard: for the owner, for production by orders, for the front desk and for the salespeople. For the business these are the same metrics an engineer looks at in a dashboard. The leaderboard scores employees on 15 indicators. And the recording of every call plus the AI breakdown of who called and why is a log in Sentry's terms: it is used to reconstruct what happened with a specific customer.

At the hydroponic farm, where I have been responsible for the server, the network and the link to the controllers since 2023, data from 25 controllers at two sites comes into one MariaDB database on the server. What to keep as history and what to count as a summary is decided by another team, which builds the automation logic and the interface. My part is making sure the data gets there.

I have an AI assistant in my code work too; it takes on routine, tests and debugging. I haven't fed its telemetry into a collector, but the order from the CNCF article is right: questions first, then fields.

What I would do

Write out five questions the system has to answer. For example: how many requests came in today, when a controller last responded, what the AI breakdown costs per day.

For each question, decide: is it a number over time or an event with context. A number becomes a metric with a threshold. An event becomes a log entry with the fields it will be found by: request ID, customer, reason.

Don't collect the rest: document bodies and full model responses aren't needed in logs, their length and status are enough.

Once a quarter, look at which fields nobody read, and remove them or move them to cheap storage, as Grafana suggests.

I wrote about background jobs and retries, which need logs more than anything else, in the article Workers: background jobs and retries. Services: infrastructure you can ship and restore and equipment monitoring and alerts. Cases: technical partner to a PDR company and hydroponic farm with 25 controllers. On the same topic: what I would trust an AI on-call engineer with on a single server and which metrics teach a team bad decisions. Earlier I wrote that observability starts with a decision the team has to make. If you don't understand what you're paying for in monitoring, show me what is being collected now: Discuss your task.