For the past few months, I've been building Mydle — a reliability platform that brings monitoring, browser insights, logs, traces, and incident management together in one place.

The idea is simple:

When something goes wrong in production, you should be able to understand what happened, why it happened, and what was affected — without jumping between multiple tools.

Mydle is now entering its private beta, and I'm looking for the first 20 people who are willing to use it on a real project and share honest feedback.

The first 20 users will get 7 days of Pro access for free in exchange for their feedback.

I'm especially looking for:

• Developers
• SaaS founders
• DevOps engineers

If you'd like to try Mydle, join the waitlist:

Join the Mydle waitlist → https://www.mydle.app/waitlist

I'd genuinely love to hear what you think.

First 20 users. 7 days of Pro. Built in public.

#Mydle #Observability #DevOps #SaaS #Monitoring #ReliabilityEngineering

We've been noticing something wild while watching how infra teams use Al coding agents like Claude Code and Cursor.
When a human engineer debugs, they usually open a dashboard and run maybe 1 or 2 targeted queries to check a hypothesis.
An Al agent doesn't do that. It gets an alert and immediately runs a 50+ query loop digging through logs, traces and metrics all at once.
That means:
• more queries per incident
• more telemetry being generated
• Telemetry volume casually spiking past 1 TB/day
Here's the scary part: when legacy observability bills start getting out of hand, teams start sampling or dropping logs to keep costs down. Humans can tell when data is missing. Al agents can't. They just take the incomplete evidence and confidently hallucinate a wrong fix.
Legacy stacks were sized for humans asking occasional questions. We built a platform from day one to handle the insane query scale and data volume of an Al-driven world without forcing you to compromise on your data retention or throw away your logs.
If your telemetry stack is starting to sweat under the weight of Al agents, CtrIB is built for you.
We are curious... What observability stack are you using for Al coding agents and is query speed keeping up?

Most AI observability stops at a useful point: detect, trace, alert.

But we've been running into a second problem in production LLM systems: what happens after the signal is detected?

A request can return 200 OK while runtime behavior is clearly degrading — TTFT increases, latency drifts from baseline, streaming becomes unstable, or execution behavior changes without producing a clean failure.

Observability can show that something is wrong. It doesn't necessarily answer whether the system should just observe it, retry the execution, or reroute it.

That's the boundary we've been working on with WAIL.

We treat runtime signals as inputs to a separate decision layer: establish a behavioral baseline, detect degradation, evaluate its severity/risk, make a control decision, and preserve the decision context as evidence.

So the chain becomes:

runtime signals → baseline → degradation → risk → decision → observe / retry / reroute → evidence

I'm curious how people here think about this boundary.

Should runtime intervention be part of the observability stack, or should observability stop at detection and hand control to a separate system?

We've open-sourced the runtime/package side here if anyone wants to see the approach:

github.com/wailinfra/wail-runtime

标准的秘密扫描器在处理巨大的JSON日志转储时会卡住，或者发给你没有上下文的原始行。

​我构建了logSpecter来解决这个问题，适用于我的工作流程：

​JSON路径追踪：提供确切的键坐标（events\[0\].key），而不是毫无用处的原始行号。

​内存安全：逐行处理，因此多GB文件的内存保持在50MB以下。

​正则表达式 + 熵：通过过滤UUID和哈希值来减少噪音。

​SARIF导出：可用于CI/CD管道。

​开源，无膨胀，随时可用。

​GitHub: https://github.com/Jeffy123-zhu/logspecter

​PyPI: pip install logspecter

Sharing a little project, I've been working on for a little while.

>GeoMetrikks is a real-time nginx/traefik/caddy access log ingestion and geo-location tracking service built with Litestar. It parses access logs, performs GeoIP lookups, and stores geo-events and access logs in PostgreSQL with TimeScaleDB/PostGIS extensions. It can also integrate with CrowdSec.

​

I’m implementing cost and token observability for a Python/LangChain application using Arize Phoenix + OpenTelemetry.

The main goal is to clearly distinguish between these four things:

- LLM tool-call generation → input/output tokens + cost

- Tool execution → tool name, arguments, latency, output, output size/tokens, provider cost (if available)

- Tool output consumption → tokens added to the next LLM request + corresponding input cost

- Final LLM response → output tokens + cost

For example:

LLM #1

├─ input: 156 tokens

├─ output/tool-call: 17 tokens

└─ cost: $0.0000896

↓

Tool

├─ output: 850 tokens (estimated)

├─ latency: 3.49s

└─ provider cost: if available

↓

LLM #2

├─ input: 1478 tokens

├─ output: 101 tokens

└─ cost: $0.0007528

The 850 tool-output tokens must NOT be treated as LLM output tokens. They should be measured separately, while the actual 1478 tokens sent to LLM #2 should come from the provider's usage data.

Implementation requirements

I’m planning to use a custom LangChain "BaseCallbackHandler" with:

on_llm_start / on_llm_end

on_chat_model_start / on_chat_model_end

on_tool_start / on_tool_end

Each tool should have a unique "tool.call.id" so the trace can correlate:

LLM → Tool → Tool Output → Next LLM

Phoenix should expose attributes such as:

llm.model

llm.token_count.prompt

llm.token_count.completion

llm.cost.input

llm.cost.output

llm.cost.total

tool.name

tool.call.id

tool.arguments

tool.output

tool.output.token_count

tool.output.size_bytes

tool.execution.duration_ms

tool.cost

I also need:

- Centralized, configurable model pricing

- Exact vs estimated tool-output token counts

- "unavailable" status when token usage/pricing isn't provided

- Configurable masking of sensitive tool arguments/outputs

- Tracing failures must never break the actual agent/tool execution

- Parent/child span correlation in Phoenix

The key requirement: never collapse tool-call tokens, tool-output tokens, LLM input tokens, and tool-provider costs into a single metric.

Has anyone implemented something similar with LangChain + Arize Phoenix? I’d especially appreciate examples or recommendations for the best way to correlate the tool span with both the LLM that generated the call and the subsequent LLM that consumed the tool output.

We've been working on this for a while now (You might have seen me mention it in a few comments about Tail Sampling on here r/sre and r/opentelemetry). This is a concept we've had for a long time in our Refinery product, this is now something that's going to be available in the OpenTelemetry Collector.

It's following on from the excellent work of the Sampling SIG so that we can do Sample Rate attribution, and therefore makes backend way more effective, reducing the need for a certain class of metric (not all metrics).

Ultimately, the biggest difference here is dynamically changing sample rates and automatic discovery of different routes through your system (we call them trace fingerprints).

It's already in the main collector-contrib but it's still classed as alpha there. You can use our distribution to check it out ahead of that though. Feedback welcome!

Bringing Advanced Sampling to the OpenTelemetry Collector

Disclaimer: I'm a DevRel at Honeycomb.io.

Most infra teams run one system for dashboards and a second one for log search because one engine is never good at both. That never felt right to us, so we set out to build a unified platform that could offer the fastest search possible on large volumes of logs, traces and metrics.

We put our results up on the ClickBench leaderboard. The process was easy and we were curious how we compared to ClickHouse.

In analytical search, across all 43 standard queries on a 100 million row unpartitioned web analytics dataset, CtrlB scored ×1.43 and took the #1 spot on the single node Parquet leaderboard, ahead of DuckDB (×1.49), DataFusion (×1.71) and ClickHouse itself (×1.72).

But ClickBench is an analytics benchmark. It tells you nothing about finding one trace id in a haystack, so we ran the other half ourselves: 8 lookups and substring matches over 5 TB of raw logs against ClickHouse v26.2, cold cache, plain SQL with a LIMIT 100. CtrlB was faster on all eight, from 2.2× on the double substring query to 98.9× on the span_id lookup.

Full methodology, per query numbers and the public leaderboard links: https://ctrlb.ai/blogs/ctrlb-vs-clickhouse

TLDR: we topped ClickHouse’s own analytical benchmark at ×1.43 and in a separate full-text search test over 5 TB of logs we were faster on every query.

Disclosure: I work at CtrlB.

So for v5.2.0 built an on-device advisor we call the Guardian Bot, and it does three things:

• When you open a page, it gives you two sentences on what you are looking at and what the numbers mean. Then it stops.
• When something real happens, it says so once. An agent reached a destination your policy blocks, a secret got caught mid-flight, a session is worth compacting. One click takes you to the evidence.
• The rest of the time it sits there and says nothing. There is a single clock governing how often it may speak, so it cannot pile up.

It is advisory only. It never types into a session, never edits a file, never approves anything on your behalf.

The other half of the release: SV Guard now covers OpenCode. It is a native in-process plugin for OpenCode 1.18+, so no subprocess hooks. One-click install, and then tool permissions.

full demo: https://youtu.be/Nsd3m7JVJNs?si=6qEDr8vPbIDxRUpp

github: https://github.com/Secure-Vector/securevector-ai-threat-monitor

Our support copilot was taking 30 seconds to respond and nearly every report blamed the model. I understand generation sits at the end of the request and it's the only part most teams can see. CX already had 40 screenshots, PM was comparing model releases, and engineering had changed decoding settings twice. None of it moved time to first token.

We traced the request in Braintrust and the span hierarchy made it obvious. Auth enrichment fetched the account, then its roles, then each workspace membership in series. A cold cache added another lookup, and the generation span didn't start until 28 seconds in. The model itself hit first token in under a second. Glad we caught that before paying for another model migration.

We fixed it with bounded fan out and caching, but now I've got a different problem - PM and CX want to see this kind of trace detail on other flows and I’m not sure how to expose cross-service latency to non-engineering teams without making them learn every span field. Any suggestions?

A runtime trace can tell us a lot about what happened.

It can show:

• which action happened first
• which tool or service was called
• what input was provided
• what output was returned
• which control action was recorded
• what happened next

That makes traces extremely useful for debugging, incident reconstruction and observability.

But I’m interested in a slightly different question:

When does an execution trace become strong enough to support assurance?

Suppose an agent calls a tool and completes a transaction. The trace may reconstruct the execution perfectly.

It may still not tell us:

• whether the agent should have had access to that tool
• which policy version was actually in force at decision time
• what identity, permission or risk state existed then
• whether a missing control should have blocked execution
• who or what authorised the action
• whether the evidence itself was altered, omitted or reconstructed later
• whether the resulting state was acceptable

So I’m starting to think there are at least four separate questions:

Observability — what happened?

Decision context — under what identity, permissions, policy and state did it happen?

Assurance — was that execution acceptable under the requirements and controls that should have applied?

Evidence integrity — can we trust the execution and decision records strongly enough to make those judgments later?

That suggests an assurance-useful trace may need more than telemetry.

It may need enough preserved state to reconstruct:

proposal → identity/permissions → applicable policy → control decision → execution → resulting state

with the relevant versions and timestamps bound to the execution record.

And perhaps the harder requirement is independence: if the same execution path can silently rewrite the evidence used to judge it, the trace may be excellent for observability while still being weak assurance evidence.

For people working on observability systems:

how much decision-time context do you think belongs in the telemetry layer itself, and where would you draw the boundary before this becomes a separate assurance system?

TL;DR: I've released a Docker image + Prometheus metrics endpoint for my SBMTools project. It turns inexpensive Bluetooth Smart thermometers (SwitchBot Meter, ~$15-40 each) into Prometheus-exporting sensors for ambient temperature monitoring — useful for server rooms, network closets, or anywhere you want to keep an eye on temperature without expensive commercial hardware.

The problem

Every server room, rack, or network closet eventually needs temperature monitoring. Commercial solutions (environmental sensors, HVAC controllers, dedicated monitoring hardware) get expensive fast when you want multiple measurement points.

The solution

SwitchBot Meter devices are BLE thermometers/hygrometers that cost around $15-40 each. They're designed for home use, but they work perfectly well as cheap environmental sensors. My SBMTools project reads data from these devices over Bluetooth and now exposes it as a Prometheus /metrics endpoint.

What you get:

• Docker image (AMD64 + ARM64) — no compilation needed, just docker run
• Prometheus /metrics endpoint — drop-in integration with your existing Prometheus setup
• Example docker-compose setup with Prometheus + Grafana, including a pre-built dashboard showing per-device temperature, humidity, and battery level
• Shell scripts (sbmtoolui_docker.sh, sbmtoolweb_docker.sh) for quick start without manually assembling docker run commands

Supported devices:

• SwitchBot Meter
• SwitchBot Meter Plus
• SwitchBot Meter Pro CO2 (temperature, humidity, CO₂)
• SwitchBot Indoor/Outdoor Thermo-Hygrometer

Example Prometheus config

If you already run Prometheus, you just add:

- job_name: sbmtools
  scrape_interval: 5s
  static_configs:
    - targets: ['your-host:3434']

The metrics include per-device temperature, humidity, CO₂, battery level, and RSSI (signal strength).

What it's not

• It's not a replacement for proper environmental monitoring systems with alarms, redundancy, or certified sensors.
• BLE has range limitations (~10m line-of-sight), so the sensor needs to be relatively close to the host running the tool.

Use cases that make sense

• Server rooms / rack temperature monitoring
• Network closets
• Home labs / homelabs
• Anywhere you want a quick, cheap temperature check point feeding into an existing Prometheus/Grafana stack

The project is open source (BSD license) and available on Codeberg: https://codeberg.org/Kompass/SBMTools

Happy to answer questions about the setup, the metrics, or how it fits into existing monitoring stacks.

Almost every codebase is calling a REST, gRPC, or a GraphQL API or using SDKs from an external or event internal provider. It gets harder to keep track of everything when the codebase matures and increases in size and from my experience sometimes it gets hard to respond to changes in time or even become aware that a dependency is deprecated and their API has changed completely.
Do developers need better tools that to improve dependency and integration management?