Tenant-scoped telemetry and alerting

Limnopulse

An API and evaluation runtime for authorized telemetry reads, alert rules, durable incidents, and notification delivery.

  • Python
  • FastAPI
  • Go
  • DynamoDB
  • InfluxDB
  • SQS
  • OpenTofu
Limnopulse public repository ↗Alert evaluator operations ↗

01 / Context

Context & contribution

Problem

Telemetry becomes operationally useful only when access, alert evaluation, incident state, and notification delivery remain attributable to the correct tenant and device context.

Context

Limnopulse is a software implementation with local integration scaffolding and a separately documented cloud-infrastructure path. Its device and broker examples are development contracts, not evidence of a deployed sensor fleet.

Contribution

  • Implemented tenant membership checks and pond ownership checks around telemetry reads.
  • Built versioned rule configuration, durable alert events, and role-aware incident transitions.
  • Developed a one-shot Go evaluator with explicit replay and work-ownership behavior.
  • Separated email and Telegram notification queues, workers, bindings, and delivery state.
  • Documented cloud resources and operational prerequisites with OpenTofu modules.

02 / System boundaries

System View

Conceptual operational map, not live telemetry. It traces observation, telemetry, and event responsibilities across local and external boundaries without representing a real environment.

Operational map

Observations move through telemetry and event bands, with operational boundaries framing the flow.

Observations

Telemetry

Events

Component details

FastAPI authorizes membership and resource ownership before querying time-series readings.

Receives from
  • Makes local readings available through InfluxDB for authorized API queries

Versioned rules guide evaluation; DynamoDB stores durable alert events and outboxes for opening, acknowledgement, resolution, and recovery workflows.

Receives from
  • Persists durable alert events and outboxes in DynamoDB
Sends to
  • Defines versioned rules for one-shot evaluation
  • An outbox relay publishes per-channel notification work to SQS

A Go runtime queries reading windows in InfluxDB, evaluates owned work once per call, and persists events and outboxes in DynamoDB before exiting. Scheduling remains external.

Receives from
  • Defines versioned rules for one-shot evaluation
  • Maps managed resources and external scheduling prerequisites
Sends to
  • Queries reading windows in InfluxDB populated by the local ingestion scaffold
  • Persists durable alert events and outboxes in DynamoDB

An outbox relay publishes per-channel work to SQS. Separate email and Telegram queues and workers preserve authoritative delivery, attempt, and idempotency state.

Receives from
  • An outbox relay publishes per-channel notification work to SQS

MQTT, Telegraf, and sample publishers write readings to InfluxDB in a loopback-only local ingestion scaffold.

Receives from
  • Queries reading windows in InfluxDB populated by the local ingestion scaffold
  • Marks the production-device boundary beyond the local scaffold
Sends to
  • Makes local readings available through InfluxDB for authorized API queries

OpenTofu describes the intended managed resources and their operational prerequisites.

Sends to
  • Maps managed resources and external scheduling prerequisites

A hardened broker, device credentials, fleet operations, and production sensor hardware remain outside the verified implementation.

Sends to
  • Marks the production-device boundary beyond the local scaffold

03 / Technical choices

Engineering

Decisions

  • Authorize telemetry through the API so clients never receive direct time-series database access.
  • Keep the evaluator one-shot so retries, backfill, and scheduling remain observable operational concerns.
  • Use durable domain state as the authority while treating queues as at-least-once transports.
  • Separate Telegram and email delivery contracts to avoid leaking channel-specific identity into shared jobs.

Reliability

  • Optimistic versions and idempotency keys make conflicting rule changes and replacement replays explicit.
  • Durable outboxes connect alert transitions to notification work without treating queue delivery as authoritative state.
  • Local fakes and emulators exercise integration boundaries without being represented as hosted services.

04 / Outcomes

Results

Outcomes

  • The implementation connects authorized readings, configurable rules, durable incidents, and delivery workers through explicit tenant boundaries.
  • Channel isolation and replay-oriented operations make failure modes inspectable in code and documentation.

05 / Public record

Evidence & limitations

Limitations

  • No production sensor fleet or hardware deployment is verified.
  • MQTT ingestion is demonstrated only as a local scaffold; production broker TLS, device credentials, and access controls remain planned.
  • Cloud infrastructure is documented as code, but this page does not claim a live hosted environment or notification volume.

Public evidence

Implemented

Limnopulse public repository

Public API, evaluator, notification workers, local integration scaffolding, and tests.

Open public evidence ↗
Documented

Alert evaluator operations

Public replay, sharding, scheduling, and failure-handling contract.

Open public evidence ↗
Documented

Notification operations

Public delivery-state, retry, rollout, and recovery documentation.

Open public evidence ↗
Documented

Limnopulse architecture

Public boundaries for authorized telemetry, one-shot evaluation, durable events, outbox relays, and channel-specific notification work.

Open public evidence ↗
Documented

Telegram notification operations

Public Telegram binding, worker, delivery-state, and retry contracts, separated from email delivery.

Open public evidence ↗