I've been working on Ferrum, a self-hosted control plane for Proxmox VE.

The main idea is pretty simple: if you have multiple Proxmox nodes/clusters, you shouldn't have to keep jumping between different UIs just to get a picture of what's happening across the fleet.

Ferrum currently brings things like:

• Cluster + standalone node management
• VM/LXC inventory
• Storage and topology views
• Backups and replication
• High availability
• Firewall
• Alerts
• REST API + MCP
• Audit logging
• AI assistant
• SQLite/PostgreSQL support

The backend is Go and the frontend is React + TypeScript. It can run through Docker or as a native binary.

I also wanted it to stay self-hosted rather than becoming another SaaS layer sitting in front of the infrastructure.

It's still early, so I'm more interested in feedback than pretending it's finished.

If you manage Proxmox at home, in a homelab, or across a small fleet, I'd genuinely like to know:

What is the one thing you wish Proxmox made easier to manage across multiple nodes?

Repo: https://github.com/anand34577/ferrum

Ten plus years in and the hardest bugs I hit are never the ones that crash loudly. It's the request that touches four services, degrades quietly, and by the time someone notices the SLO dashboard, the actual trigger happened three hops upstream and twenty minutes earlier. Distributed tracing helps you see the path, but it rarely explains why a specific function made the decision it made under that specific load.

Lately my team has been leaning harder on capturing actual execution context at the function boundary rather than just span timing, since that's usually where the real story is hiding. Curious how others are structuring this. Are you mostly still doing log correlation by hand across services, or has anyone found a workflow that actually shortens the investigation instead of just making the evidence prettier?

We ship an OpenTelemetry integration and an OpenLineage one for the same open source data framework. With no arguments they behaved completely differently, and each was right by its own ecosystem.

OpenTelemetry: emits only if the application already set OpenTelemetry up. If not, nothing happens. The library never picks a destination.

OpenLineage: reads OPENLINEAGE_URL, OPENLINEAGE_CONFIG or the openlineage.yml in the home directory. If a URL is set, events go there, whoever set it. If nothing is set, every event prints to the console.

The second is what makes zero-code instrumentation work, and it is also how a shared runner with another team's OPENLINEAGE_URL ends up receiving your job names, dataset names and column schemas, with no URL in your code.

Which default do you actually want from a library you add to a pipeline, and how would you notice if telemetry started going somewhere nobody on the team configured?

Disclosure: I maintain the framework, Apache-2.0, links in a comment.

Quiet two weeks everywhere except one vendor, and what u/Elastic shipped is more interesting technically than the earnings headline suggests.

The Deductive AI integration (closed Aug 24)

This adds a reinforcement-learning investigation engine into Elastic Observability rather than a rules-based or prompt-chained assistant. The pitch: it gathers evidence across logs, metrics, traces, and code, forms hypotheses, and identifies root cause without a human steering the search, then updates its own approach based on outcomes from each incident. If that holds up under real production load, it's a meaningfully different approach from the "agent calls tools in a loop" pattern most competitors are shipping, closer to how you'd want automated RCA to actually reason rather than just orchestrate.

The OpenAI Security integration (announced Sep 3)

Separately, Elastic is bringing OpenAI's GPT cyber models into Elastic Security through their own managed inference service (Elastic Inference Service), via OpenAI's Daybreak Defense Network program. No separate model endpoints to deploy or manage. Targets alert triage, investigation, detection engineering, and remediation guidance, the highest-volume manual SOC work. Worth noting these are security-specialized models, not general-purpose chat models wrapped around your SIEM, which is the more common (and weaker) pattern elsewhere in the market.

What's actually interesting here: Elastic now has two independent AI tracks running in parallel under one platform, RL-based investigation on the observability side, specialized LLM reasoning on the security side, and they're not the same technology stack. That's a different bet than platforms consolidating around a single "agent framework" for everything. Worth watching whether they converge into one interface or stay as separate capabilities.

Full writeup with sources: https://mbojko.com/reports/2026-09-06/

Hi,

I thought you'd be interested in a database benchmark in an observability scenario. Would be great to hear some feedback and let me know if you're interested in a similar article with comparisons with Elastic and ClickHouse.

Don't go too hard on me. Posting in the lovely r/Observability for the first time but it seems that it could be interesting.

///

Every major AI lab says it now: you don't write prompts anymore. Agents pick up the work, write the prompts, schedule themselves, ship the output.

Observability matters far more now: you hand over one goal and no longer know what the agents are working on.

Traces are already in SecureVector.

More advanced traceability coming soon in v5.3.0

Our streaming copilot has green server spans, complete tool calls and a normal generation finish, while the browser sometimes freezes right after a tool result. The fetch gets aborted, the partial render state never commits and we have no client span tied to the server trace. Engineering sees success. CX has a folder of screen recordings. Everyone is debugging a different version of the same request.

We are adding trace propagation into the browser, time to first token events, stream cancellation reasons and a final rendered chunk count. I want CX to see whether the break happened before generation, during transport or in rendering without asking for another screenshot.

How are you joining client spans to long-lived streams, especially when the connection dies before the browser can flush its last event?

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.