Posts

Es werden Posts vom Januar, 2010 angezeigt.

Pinned Post

NodePulse: so your Lightning node speaks up before it gets expensive

Bild
  A Lightning node is an odd kind of device. It sits on a shelf somewhere, a Raspberry Pi with an SSD, and as long as everything works you don’t look at it for weeks. That is exactly the problem. When LND hangs, the SSD fills up or a peer has been offline for days, nobody tells you. You only notice when a payment fails. Or worse: when an HTLC is about to expire and nobody reacts. RaspiBlitz comes with a lot, but not with alerting that actively nudges me. The ready-made solutions I looked at were either too big (Prometheus, Grafana and Alertmanager on a Pi that is supposed to run a Bitcoin node) or they ran as a service somewhere else, with access to my node data. I didn’t want either. So I built NodePulse. A small program that runs directly on the node, checks every minute whether everything is fine, and sends me a Telegram message when it isn’t. And another one once the problem is gone. On top of that there is a dashboard in the browser. In this article I explain what NodePulse...
Kommentar veröffentlichen
Read more »

Erlang Code Loading

Um geänderte Module neu zu laden, kann man entweder die VM neu starten oder aber nur die Module neu laden, die sich geändert haben. Die erste Methode kennt bestimmt jeder, aber die zweite vielleicht nicht. Ich benutze diese zweite Methode in meinem Continuous Integration Prozess, indem ein Prozess die geänderten Sourcen aus SCM lädt, baut und dann die Nachricht an den sogenannten code_reloader schickt, damit dieser die geänderten Module neu laden soll. Wie funktioniert das im Detail? Zunächst einmal ermitteln wir alle Module, die z.Z. geladen sind. code:all_loaded() Diese Funktion gibt uns eine voll qualifizeirte Liste aller geladenen Module zurück. Wir könnten nun über die Liste iterieren und einfach alle Module neu laden, aber das wäre langweilig. Deswegen überprüfen wir zunächst, ob es sich bei der Datei um ein beam File handelt. Das ist für unsere späteren Schritte wichtig. Um das zu überprüfen schaun wir nach, ob die zu überprüfende Datei Metadaten besitzt. file:re...
Kommentar veröffentlichen
Read more »

Verteiltes Erlang

Bild
Systemarchitektur - IMac mit OSX - PS3 mit Yellow Dog Linux 6.2 - Erlang Vorbereitungen Die PS3 und der IMac müssen sich kennen. Das kann man sehr einfach mit einem ping Rechnernamen überprüfen. Sollte das nicht funktionieren, so fügt man die IP Addresse und den Hostnamen der jeweiligen /etc/hosts hinzu. Also, in die /etc/hosts des IMac fügt man die IP Addresse und den Hostnamen der PS3 hinzu und umgekehrt. Bespiel IMac:     192.168.2.34    ps3.localdomain.de Auf der PS3 und dem IMac muß Erlang installiert sein. Node Namen Damit wir eine Verbindung zwischen den beiden Erlang Instanzen herzustellen, starten wir die Erlang Nodes mit dem Parameter name (Langname des Rechners. Hier z.B. ps3.localdomain.de)     erl -name ps3.localdomain.de Den Namen der Node kann man in der Shell mit     node(). abfragen. Möchte man alle Nodes ermitteln, die mit einer Node verbunden sind, so kann man...
Kommentar veröffentlichen
Read more »

Beliebte Posts aus diesem Blog

Splitting an ML model and a web app across two BEAM nodes — the technical blueprint

Bild
The web app (Phoenix + Postgres) runs in production on a small Linux box with no GPU. The embedding model ( intfloat/multilingual-e5-base , ~278 MB, XLM-RoBERTa backbone, EXLA-compiled) wants compute that isn't there. That compute lives in a MacBook Pro. Goal: offload only the heavy inference to the Mac, keep everything else on the server — and the calling code shouldn't know where the math happens. The usual answer would be a second service with a gRPC/REST API, serialization, service discovery, timeouts, retries, and a second deployment artifact. On the BEAM, "another machine" is a platform primitive instead. What it takes isn't new infrastructure, but a clean split of one codebase into two releases and three node roles. The mental model: one codebase, two releases, three roles There is exactly one codebase (an umbrella project) and no second language. The only thing that varies is what a started node brings up . A single environment variable, FINANCE_ROLE ,...
Read more »

Jido in Practice: Agents in Elixir as Composable Actions

Bild
At Fiatbitcoin, around two dozen small agents run in the background. They fetch prices, read the mempool, score news, compute tax deadlines, send alerts. In the beginning these were all just GenServers and Oban jobs, each built a little differently. That works, but it gets messy fast: every job has its own input and output, its own way of reporting errors, its own idea of what “done” means. Jido is a framework for exactly this kind of work. It hands you a small set of clearly defined building blocks that let you assemble agents from small, testable units. I use it in version 2.1. This article is a tour through real code from the project, and the question behind it stays the same throughout: where does Jido pull its weight, and where does it not. If you don’t write Elixir, a few words up front. A module is a collection of functions. {:ok, value} and {:error, reason} are the usual way to return success or failure, a tagged pair. A GenServer is a lightweight, long-lived process wit...
Read more »

A Foundation Model in the BEAM: On-Chain Anomalies with Google TimesFM in Elixir

Bild
At Fiatbitcoin a worker collects metrics from our own Bitcoin node every ten minutes: mempool size, number of waiting transactions, fee rates, hashrate, difficulty. Over time that builds a decent time series, one row per measurement in a table. At some point the obvious question comes up: when is one of these values actually unusual? When is a note or a push worth it, and when is it simply Tuesday evening? The cheap answer is a fixed threshold. Mempool above 200,000 transactions, alarm. The problem with that shows after a week: the mempool breathes in a daily and weekly rhythm. Sunday evening is reliably fuller than Tuesday morning, fees pick up at certain times. A flat threshold flags every predictable peak as an anomaly and stays silent on an untypical spike that happens to stay under the line. What you actually want is a band that knows the normal rhythm, and an alarm only when a value breaks out of that band. First the simple way The honest entry point into something like thi...
Read more »