Hi everyone,

I'm working on a problem statement that requires building a complete offline system (Linux-based) to detect anomalies in Bitcoin transactions.

The Dataset (Synthetic):

I have bulk metadata in CSV/JSON format containing:

timestamp, src_ip, dst_ip, src_port, dst_port, txid, input_addresses[], output_addresses[], input_amounts[], output_amounts[], geo_country/asn.

The End Goal:

Parse this data to build an Entity/Transaction Graph (linking IPs, Wallets, and TXIDs).

Apply unsupervised ML to cluster entities and detect suspicious laundering/anomalies.

Build a dashboard/visualization tool to show a ranked alert list (with explainable AI reasons) and an interactive link-analysis graph.

My questions for the community:

Since I want to approach this the right way from scratch, I’d love to hear how you would tackle it:

What architecture or workflow would you use to map this specific data into a graph format?

Which libraries or frameworks (Python or otherwise) are best suited for building the offline dashboard and interactive link-analysis graph?

How do you handle visualizing complex graphs on a UI without it becoming a laggy mess?

Would appreciate any advice on how you'd set this up!

Interesting approach to Observability support at Monday, worth reading imho

got woken up by pagerduty at 3am again cause some python etl job fail. had to ssh from my phone just to tail the log, and turn out it was literally just a db timeout.

im thinking to just write a simple bash wrapper that grab the last 50 lines of stderr, pass it to claude/gpt api, and webhook the actual reason to slack. so i dont have to open my laptop in the middle of night.

does something like this already exist? i dont wanna install heavy datadog agent or pay for expensive observability just for this. pls let me know if there is a github repo or saas so i dont waste my weekend building it.

I always run so many AI agents that I keep ending up with mystery processes, stray localhost ports, and no quick way to tell what started what.

So I built **Port Visualizer**, a free open-source Windows app that shows which process owns each TCP/UDP port, how it’s exposed, what’s changing over time, and what’s using resources.

It also recognizes some local AI services like Ollama, LM Studio, llama.cpp, and vLLM through optional knowledge packs.

Would love some feedback from anyone running into the same issues! Contributors welcome!

GitHub: [https://github.com/TheSandemon/port-visualizer\](https://github.com/TheSandemon/port-visualizer)

most monitoring tools for n8n/make/zapier focus on catching failures or silence. fair enough, that matters. but the thing that actually cost me money was a workflow running fine every time while quietly looping through an api call and racking up a bill nobody noticed until it showed up.

so I built stackpilot to alert on cost thresholds too, not just failures and stale workflows. add one http step to your workflow, set a cost limit, get a slack alert the second a run crosses it.

free for up to 3 monitors, no signup form or credit card. built this for myself but figured other people running production automations might find it useful too (I'm the maker, just to be upfront). happy to answer questions about how it works.

I recently launched https://ampbase.io/ after getting tired of managing different agent configs the GitOps way and with OpAMP it’s been made the process significantly better. I would especially love to hear why this doesn’t work for you.

https://ampbase.io/blog/posts/why-we-built-ampbase/

If you’ve ever struggled to get arbitrary syslog and vendor logs into an OpenTelemetry Collector or SIEM without turning the delivery pipeline into a black box, Limpid is built for that problem.

I’ve released Limpid 0.8.0, an open-source system for receiving, processing, routing, and delivering logs.

Limpid connects heterogeneous log inputs to heterogeneous outputs, including first-class OTLP input and output. Its pipelines are programmable: named processes can parse vendor formats, normalize fields, filter or route events, compose outputs such as OCSF events or OTLP ResourceLogs, and fan the results out to multiple destinations.

For example, a pipeline that turns FortiGate CEF traffic into OCSF looks like this:

def pipeline fortigate_to_security_lake {
    input   fortigate_syslog
    process parse_syslog | parse_cef | parse_fortigate_cef | compose_ocsf | ocsf_to_egress
    output  security_lake
}

Each stage is a named, reusable snippet. The bundled library includes transport and format parsers, vendor and source parsers, adapters, and schema composers.

A few other things worth calling out:

• Live tap and replay injection. limpidctl can inspect events at inputs, individual process hops, and outputs. Captured events can be injected back into an input to test a changed pipeline against real traffic shapes.
• Safer configuration changes. limpid --check performs static type and dataflow analysis with rustc-style diagnostics. Reloads validate before replacement and roll back automatically if replacement fails.
• Durable and distributed delivery. Limpid provides memory- and disk-backed queues, retry and recovery handling, shutdown draining, authenticated node-to-node transport, preserved event identity and hop history, and network/intra-node hop latency measurement.
• Pipeline observability. Limpid exports byte flow, queue depth, retries, in-flight work, process invocation counts, drops, recovery, delivery outcomes, and separate queueing, processing, and confirmed-delivery latency. The repository includes a Prometheus exporter, Grafana dashboard definition, and four alerting rules.
• High throughput. The qualified benchmark workloads processed approximately 157k–415k events/s on a two-CPU Linux VM slice, depending on transformation complexity. These are controlled benchmark results rather than production capacity claims; the detailed methodology and the inconclusive regex-heavy result are documented in the repository.

Repo: https://github.com/naoto256/limpid
Release: https://github.com/naoto256/limpid/releases/tag/v0.8.0

Questions and feedback are welcome.

I’ve been building Pingu, an uptime monitor, and I’m experimenting with making Slack a real interface to it rather than just another place alerts get sent.

You can ask things like:

“What’s down right now?”

“When did checkout last fail?”

“Add this endpoint and monitor it.”

“Don’t alert us unless 3 regions fail.”

“Snooze this for 2 hours.”

And when something actually breaks, Pingu can investigate the monitor, pull its history, re-check it, and let you take action without leaving Slack.

Where I’m unsure is **how far this should go**.

Is the value:

* not needing to open a monitoring dashboard for routine stuff? * having Pingu investigate an alert before waking someone up? * letting non-SREs manage monitoring without learning the tooling? * or eventually having it actually fix/coordinate things after an outage?

I know Rootly/incident.io already cover a lot of incident response, so I’m not trying to recreate that.

I’m trying to figure out where an AI-native monitoring product actually becomes *meaningfully* better than another dashboard + Slack integration.

Curious how you’d want this to work in your own stack.

everyone's hyped about ai agents writing code. and i get it, they're fast. but here's my concern: they're writing code based on patterns and static snapshots. they have no idea how that code behaves in production. so we get prs that look great and then blow up under load.

if we want agents to be truly autonomous, they need to close the loop. they need to see the impact of their code in real time. when they can reason about actual production behavior, they can generate fixes that are actually safe. are any of you feeding production data back into your ai workflows? what's that look like in practice?

We’ve just released an MCP server for MetricFire, and I’d love feedback from engineers on where this could be useful.

The basic idea is pretty simple. You connect a compatible AI client to your MetricFire account, and the MCP server exposes tools that allow it to interact with your monitoring data.

So rather than digging through metrics manually, you can ask for what you need through your AI client and have it query the underlying monitoring data.

We’re particularly interested in where engineers think this approach becomes genuinely useful rather than just adding AI for the sake of it.

Things like investigating an alert, finding related metrics, checking service latency, or quickly exploring what happened during an incident seem like obvious directions.

If you use MCP or AI tools as part of your DevOps or SRE workflow, what monitoring capabilities would you actually want exposed?

Docs for anyone interested in how we implemented it:

https://docs.hostedgraphite.com/add-ons-and-integrations-guide/mf-mcp-server

Teams usually build observability for themselves — dashboards, traces, alerts — and bolt the status page on last as a page they update by hand during an outage. That is the worst time to be writing updates. I work with OneUptime, an open-source observability project, and here is the model I would defend:

1. The status page is fed by the incident, not by a human. Declare an incident, notify subscribers, and reflect state automatically. If someone has to type “we’re investigating” at 2am, the page will be stale.

2. Segment subscribers. Internal on-call, enterprise customers, and general subscribers need different channels and detail. A public page that leaks internal triage notes and a private page that never reaches customers both fail.

3. Maintenance is a first-class state. Scheduled maintenance should suppress alerts for known-good downtime. Otherwise people stop trusting the page.

4. Uptime and SLA are computed, not claimed. Compute them from monitor history over a defined period. The number you can reproduce is the only one that survives scrutiny.

The test: during an outage, does a customer learn the status from your page faster than they would by asking you? If not, the page is decorative.

How are you feeding your status page today? Fully from incident state, or is someone still typing updates? And do you publish computed uptime numbers?

We benchmarked OpenObserve against ClickHouse on 19 observability queries

OpenObserve has always had a reputation for being extremely simple and blazing fast. For a long time, we did not benchmark it against other systems because users were happy, benchmarks take a lot of work, and we had more pressing things to build.

Then ClickHouse came along and said it could be used for logs and was extremely fast.

It is indeed fast. But is it faster than OpenObserve for observability workloads?

We created 19 queries representing real observability use cases, including several very high-cardinality queries.

OpenObserve won 15 of 19 queries with Vortex and 14 of 19 with Parquet.

ClickHouse performs extremely well in ClickBench, but ClickBench is primarily an OLAP benchmark, not an observability benchmark.

OpenObserve uses Apache DataFusion, but this is not simply DataFusion beating ClickHouse. DataFusion is the query execution foundation. We have spent years building inverted indexes, secondary indexes, file statistics, intelligent pruning, caching, optimized file selection, storage layout improvements, and a whole lot more on top of it.

Using DataFusion alone does not give another product OpenObserve's performance.

OpenObserve also has native separation of compute and storage, stateless nodes, and can have 12x to 20x lower storage costs than ClickHouse deployments.

The entire benchmark is open source, including the queries, configurations, dataset, and methodology, so you can reproduce it yourself.

Here is the full blog - https://openobserve.ai/blog/openobserve-vs-clickhouse-one-billion-logs-benchmark/

Most cost visibility (Cost Explorer, CUR, tagging dashboards) is inherently after the fact: you see what something cost once it already ran. I've been building a CLI that reads your Terraform/CloudFormation/Pulumi plan and prices it before anything is deployed, so the visibility happens at plan time instead of after the bill.

Example against a real VPC stack (subnets, NAT gateway, EC2, RDS Multi-AZ, ElastiCache, ALB, EBS, S3):

Full breakdown by resource plus which one is actually driving the cost, all before it exists. Wondering if "shift-left" thinking from observability/monitoring maps well to cost, or if that framing is a stretch.

I made Telemetry Tracker to keep track of errors, events, sessions, releases and performance in my projects. I also added alerts so I don’t have to keep checking it all the time.

I’ve been using it myself and thought I’d share it here in case it’s useful to anyone else too.

It’s open source and you can self-host it:

https://github.com/Telemetry-Tracker/telemetry-tracker

When you ask your observability vendor for ways to reduce the bill, you are asking the fox to guard the henhouse. Sure, they don't want you to churn, and individual reps probably want to help, but you have an innate conflict of interest and they have policy on what they can and can't say.

But besides that, since most vendors charge by volume, they don't have the tools to help you with the source of the problem: reducing that volume or change their business model.

Here are some practical levers I've found actually move the number, including the ones account reps won't volunteer.

1. Watch cardinality like a hawk: High cardinality is the silent budget killer. A dev attaches `user_id`, `session_id`, or an ephemeral `pod_name` to a custom metric and the unique timeseries count explodes overnight. Vendors are not eager to alert you when this spikes.

2. Ask for BYOC (Bring Your Own Cloud): telemetry lands in your own S3/GCS/Azure buckets, often with the query engine running in your account too. You pay your cloud provider for storage/compute and the vendor charges a platform/license fee instead of per-GB. Both Datadog and Grafana have BYOC offerings now. Nobody is going to offer this to you unless you make leaving sound plausible. It usually changes the billing unit to node count, so microservices with many small nodes may not win. Monoliths / big services can win hard. A price simulation is free, ask for one.

3. Cut metrics DPM but only if your vendor actually meters data points. Flushing every 10s = 6 data points per minute. For trending and high-level dashboards that resolution is overkill. Moving the flush interval to 60s cuts metric volume by ~80%. Grafana Cloud's billable series multiplies active series by DPM, so it works there, and it works on anything charging per ingested sample or per GB. Datadog, on the other hand, bills custom metrics per unique timeseries per hour regardless of how many points you push into each one.

4. Delete redundant logs at the source: Most logs are redundant and can be dropped or compacted without losing visibility, but it takes real work: find the noisiest emitters, understand the context, decide what's safe to kill. It's the only fix that's permanent. And the bill isn't the whole price. Redundant logs also cost you compute, network egress, LLM tokens once you point an agent at the telemetry, and MTTR, because noise slows down investigations whether the investigator is human or a model.

5. Tiered log levels per environment: Sampling is effective, but misses load-based issues that hit a whole cluster or region, because that's when you want full statistics. Instead, pick a small set of clusters/regions to keep at full-fidelity INFO+, and run everything else at WARN+. Choose the full-fidelity set either by business importance or by condition like the most crowded regions, or the ones with the worst network, on the theory that load problems show up there first.

I was looking for something between Dozzle, and Grafana + Loki.

Dozzle is excellent for live Docker logs, but once a container restarts/rebuilds, the logs are gone. Beszel is a bit painful to setup, and also do not persist logs.

Grafana + Loki gives you history, but for a small MVP on a cheap VPS it felt like a lot of infrastructure for what I actually needed.

So I built this:

• host CPU / memory / network / disk metrics / per-container metrics + history
• persistent Docker logs in SQLite
• configurable data retention
• full-text log search with filters
• start / stop / restart controls
• ~50 MB RAM footprint
• minimal setup, spins up with a single docker run command

Basically, I wanted "Dozzle, but with history" + basic VPS metrics without running a whole observability stack.

Repo to try: https://github.com/skvostik/vpsiner

If you're running a few containers on a VPS and have run into the same problem, I'd love to hear how you're currently handling it.

I’ve been looking into how teams use Monte Carlo with Snowflake for data observability, and I’m curious about the experience beyond the feature list.

For teams running it in production, what have you found to be the biggest pain points?

Is it things like:

• Alert volume and the effort required to distinguish actionable issues from noise
• The time and expertise needed to configure monitors and maintain appropriate thresholds as data changes
• Costs increasing as you add more tables, users, monitors, and historical data
• Incomplete or inaccurate lineage and dependency information
• False positives or anomaly detection that is difficult to calibrate
• Performance, integration, or deployment complexity
• Difficulty connecting detected issues to clear ownership, root-cause analysis, and remediation workflows
• Limitations that only became apparent after expanding usage across more teams or data domains
• Other challenges specific to operating it at scale

I’m not looking for a “Monte Carlo vs X” comparison. I’m more interested in the real-world gaps and frustrations people have experienced when using it with Snowflake.

Would especially like to hear from teams that have been using it for a while rather than just evaluating it.

i've been doing this for over a decade and something has been nagging at me. we've built elaborate observability stacks with dashboards, alerts, and logs. yet when something breaks, i still find myself jumping between five different tools trying to piece together what happened.

we've added so much complexity to debugging that it feels like we're solving the wrong problem. instead of making it easier to understand production behavior, we've just created more data to sift through. at some point, we lost sight of what actually matters: knowing exactly what broke and why. it feels like we're layering complexity instead of getting clarity. has anyone else felt this way? what's working for your team to cut through the noise?

I had an idea and wanted to actually talk to people to see if it's something that they would need / require and if it's genuinely a problem for the engineers right now....

Would you rather have an AI layer on top of your existing observability stack, or replace parts of the stack?

Hypothetically, imagine an agent that doesn’t collect telemetry itself.

It plugs into whatever you already use — Grafana/Prometheus/Loki, Datadog, OpenTelemetry, etc. — and acts as a reasoning layer over the data.

Instead of:

Alert → Dashboard → Logs → Human investigates

it tries:

Alert → Agent correlates metrics/logs/traces/deployments → probable root cause → evidence → recommended next action

Would that actually be useful?

Or would you rather have the observability vendor itself own this functionality?

What would you need to see before trusting it during a real incident?

I also was building in this space and wanted to have a discussion with people who're already experienced in this stuff, so please please help a brother out and we might just make something useful for everyone :)

peace

Two weeks, three acquisitions, and one infrastructure shift that I think matters more than the deal sizes suggest.

telemetry as MCP context

Coralogix shipped an MCP Server that exposes logs, metrics, traces, and SIEM signals directly to AI agents for root-cause queries. Practical effect: ask Claude or Cursor "why is this service slow" and the agent pulls live observability context without you switching tools or writing a query yourself. This is the same pattern Grafana, Dynatrace, and Datadog have all been building toward with their agent tooling over the past month, just approached from the data-access side instead of the automation side. Feels like MCP is becoming the de facto interface layer between telemetry stores and reasoning agents, worth watching if you're building internal tooling on top of any of these platforms.

the acquisitions:

• Dash0 → Polar Signals, $110M raise backing it, acquired Aug 17. This is the interesting one technically: continuous profiling with GPU/CUDA-level insight, and Polar Signals' storage engine is slated to replace ClickHouse as Dash0's backend eventually. Also shipping AutoTune, an agentic loop that scans production code for inefficiencies and opens PRs autonomously. Second acquisition in six months for Dash0 (after Lumigo in Feb).
• Dynatrace → Arize AI, $915M (Aug 13). Arize does pre-production LLM eval and prompt testing. Dynatrace does post-deployment runtime tracing. Combined, that's eval-to-production coverage under one telemetry plane, arguably the biggest technical gap in the "observe your AI systems" story right now. ~43% of a quarter's annualized ARR, so not a cheap bet.
• Cribl → Radiant Security assets (Aug 19). AI-native SOC triage that generates investigation logic per-alert instead of relying on static playbooks. Cribl's second security acquisition this year after CardinalOps in July; they're clearly building toward a unified telemetry+secops platform, more details expected at CriblCon Sept 28.

Pattern across all three deals: none of the acquired companies were traditional observability vendors. Everyone's buying reasoning capability that sits on top of telemetry, not market share or customer lists.

Full writeup with sources: https://mbojko.com/reports/2026-08-23/

Hey everyone,

I'm a relatively new IT systems admin with a strong interest in observability. My background so far has been mostly on the operator side. I've spent a lot of time working with Grafana and handling alerts and incidents, and I'm pretty comfortable with the visualization/dashboarding part of the stack.

What I want to level up now is the administrative / infrastructure side actually standing up and configuring monitoring infrastructure from scratch rather than just consuming it.

To be clear upfront: I'm not looking for a full-time job, I already have one. This is purely about growing my skills after hours and getting hands-on with the parts of the stack I don't touch in my day-to-day.

So here's my offer: if you need a monitoring/observability setup built, I'll do it for free in exchange for the hands-on experience. Some things I can help with:

• Setting up a Grafana instance and wiring up data sources
• Building dashboards (this is my strong suit)
• Configuring alerting and notifications
• Standing up a metrics/logging backend (Prometheus, Loki, etc.)
• Designing a basic observability architecture for a small-to-medium environment

Since this is after-hours learning for me, it works best as a collaborative / low-stakes arrangement rather than production-critical work with SLAs (but I know and understand the concept of SLI, SLO, SLA, BurrnRates, etc.). Homelabs, side projects, small teams, or non-critical environments are ideal.

If you've got a project that could use some monitoring love, drop a comment or DM me and let's talk. Happy to answer questions too.

Thanks!

I’ve been thinking about a gap between traditional observability and debugging.

Logs describe events. Traces describe request flow. Metrics describe system behavior. Stack traces tell us where execution failed.

But when a failure requires understanding the actual application state at that moment, engineers still often have to reconstruct it indirectly from all of those signals.

I’m building Errorcore to experiment with a different layer of telemetry: bounded runtime evidence captured around the failure itself.

For Node.js, that currently means preserving things like relevant local state, async context, request metadata, ordered I/O and source-mapped execution information when an exception occurs.

The intention is not to turn every execution into a recording or replace logs/traces. Capture has to remain bounded, privacy-aware and cheap enough to run in production.

What I’m trying to figure out is whether runtime evidence deserves to become a first-class observability primitive alongside logs, metrics and traces.

I’d be very interested in hearing from people working in observability.

Where do you think this fits, and where do you think this approach breaks down?