# Prometheus
All Prometheus notes →1 — Prometheus Components
The functional pieces inside a Prometheus server — scrape manager, TSDB, rule engine, query engine — and the real commands used to install and run one on a VM, under systemd, or in Docker.
2 — Pull Model Deep Dive
Why Prometheus chose a pull-based scrape model over pushing metrics, what that trades away, and how the Pushgateway papers over the one workload — short-lived batch jobs — where pull genuinely doesn't fit.
3 — Data Flow
A short connective walk through Prometheus end to end — from an instrumented app exposing a metric, through scraping and storage, to a PromQL query surfaced as an alert or a dashboard panel — with each stage pointing to the chapter that owns it.
# Projects
All Projects notes →Signal Forge ADR-008: Dead Letter Queue for poison message handling
Routes messages that exceed retry limits or are NACKed without requeue to a RabbitMQ DLQ, preventing infinite retry loops from starving the consumer.
Signal Forge ADR-006: Fail-fast on missing secrets
Services throw at startup when required connection strings are absent, instead of silently falling back to defaults that mask misconfiguration.
Signal Forge ADR-010: gRPC server-streaming via AsAsyncEnumerable (not ToListAsync)
Streams order rows to the gRPC client directly from the PostgreSQL cursor via AsAsyncEnumerable, keeping memory usage O(1) regardless of result set size.
Signal Forge ADR-004: Helm-managed Alloy stack (grafana/k8s-monitoring)
Standardizes on the grafana/k8s-monitoring Helm chart's five-role Alloy topology, keeping the hand-rolled DaemonSet only as a non-deployed reference.
Signal Forge ADR-009: K8s attribute enrichment at collector (not in SDK)
Adds Kubernetes pod/namespace/deployment attributes via Alloy's k8sattributes processor at the collector, keeping application SDKs Kubernetes-agnostic.
Signal Forge ADR-001: Log tailing instead of OTLP log export
Ships logs via node-level Alloy tailing of stdout instead of OTLP SDK log export, to keep log delivery decoupled from application health.
Signal Forge ADR-007: secretKeyRef for all credentials (no plaintext env vars)
Stores all database, RabbitMQ, and API credentials in Kubernetes Secrets referenced via secretKeyRef so manifests stay safe to commit.
Signal Forge ADR-005: Separate collector configmaps per deployment mode
Keeps cloud and local Alloy collector configs in separate files rather than one conditional configmap, so each mode's exporters stay explicit and uncoupled.
Signal Forge ADR-003: Span metrics generated before tail sampling
Places the spanmetrics connector ahead of tail_sampling so RED metrics reflect all traffic instead of only the ~25% of traces that survive sampling.
Signal Forge ADR-002: SpanLink for async RabbitMQ propagation (not parent-child)
Uses a SpanLink, not a parent-child span relationship, to connect RabbitMQ consumer spans back to the producer span across async, retry-prone delivery.
Architecture Overview
Signal Forge's topology, service communication, trace propagation, and per-signal pipeline flow across local and Grafana Cloud deployment modes.
SignalForge: OTel Microservices Validation Lab
The architecture spec for SignalForge, a multi-service .NET/Python/Angular lab validating every OpenTelemetry instrumentation pattern end-to-end.
ADR-008: Adopt Grafana Cloud + OpenTelemetry + Alloy as the ShipSolid Observability Standard
- **Status**: Accepted - **Date**: 2026-06-09
ADR-006: Pin OpenTelemetry Semantic Conventions to v1.26 as Platform Baseline
- **Status**: Proposed - **Date**: 2026-05-07
ADR-007: Adopt Two-Tier Grafana Alloy Collector Topology
- **Status**: Proposed - **Date**: 2026-05-07
Dependency Map
Map of platform dependencies — what the platform relies on, and what relies on it.
Control Plane Architecture
How the platform is configured, governed, and changed — the control plane.
Data Plane Architecture
How telemetry flows from source to storage — the data plane.
Technical Design Documents
Index of **ShipSolid platform** Technical Design Documents.
01 — Platform Architecture
How the platform is built — views, planes, signals, and the decision record indexes.
Platform Overview (C4 L1-L2)
The platform at a glance — C4 Level 1 (System Context) and Level 2 (Containers).
Signal Catalog
Canonical catalog of the signals the platform supports and the golden signals every service should
Telemetry Schema Design — Azure Container Apps on Grafana Cloud
This schema is optimised for: - 50+ Azure Container Apps
ADR-002: Adopt Grafana Cloud for Unified Observability
Accepted 2024-02-01 The Architect Learning Lab runs heterogeneous services across multiple technology stacks (.
ADR-005: Adopt AIOps Pillar for Intelligent Operations
Accepted 2026-03-26 The Architect Learning Lab has mature observability (f-observability), tooling (i-tooling/srekit),
ADR-001: Adopt Eight-Pillar Monorepo Structure
Accepted — pillar table amended (see [Amendments](#amendments) below).
Architecture Overview
The ShipSolid Platform Engineering Lab demonstrates enterprise-grade cloud-native patterns through a
Architectural Design
This document outlines the architectural design of a scalable, modular observability framework
Data Source Strategy
To ensure comprehensive observability across infrastructure, applications, and business workflows,
Collector Deployment Strategy
A key pillar of the observability framework is the standardized and automated deployment of
Faro / RUM Technical Design
**Applies to:** Angular 17+ SPAs **SDK versions:** `@grafana/faro-web-sdk ^2.
Observability Overview
The observability pillar combines Alloy collector examples with a Terraform-managed Grafana Cloud
The Pillar Model
The monorepo is organized into nine alphabetically-prefixed pillars, each representing a distinct
Platform Overview
The platform pillar is currently centered on Terraform workload roots under
RFC-001: Adopt Grafana Cloud for Centralized Observability
- **RFC ID**: rfc-001-adopt-grafana-cloud-for-centralized-observability
Observability Architecture: Questions to Ask
A chronological sequence of 216 questions an architect asks when designing a production-grade observability platform — from business context through multi-tenancy, SLOs, onboarding, and validation.
# Patterns
All Patterns notes →01 — Monolith — Modular and Majestic
A single deployable unit with well-defined internal module boundaries. Underrated at MAANG interviews — the right answer when decomposition cost exceeds the benefit.
02 — Strangler Fig
Incrementally replace a legacy system by routing new functionality to a new implementation while the old system continues to run. Named after the fig tree that grows around and eventually replaces its host.
# Internal Developer Platforms
All Internal Developer Platforms notes →1 — IDP Reference Architecture
A reference architecture for an IDP spanning logical layers, physical deployment topology, and the interfaces between them.
2 — Platform Building Blocks
Enumerates the building blocks, portal, catalog, templates, APIs, automation engine, identity, and observability, that recur across every IDP implementation, each expanded in its own later Part.
3 — Control Plane vs Data Plane
Separates what the platform's control plane decides from what actually executes on the runtime plane, and why conflating the two is a common architecture mistake.
4 — Platform Domains
Maps the platform's scope across infrastructure, application, security, networking, data, and observability domains.
# Observability
All Observability notes →1 — Designing An Observability Platform
Frames a platform-level design exercise: ingestion scale, tenancy, storage tiering, and query latency as first-class requirements.
2 — Data Plane vs Control Plane
Separates the high-throughput telemetry data path from the low-throughput configuration/policy path, and why conflating them causes outages.
4 — Agent Based vs Agentless Collection
Weighs sidecar/DaemonSet agents against agentless eBPF or vendor-API scraping for coverage, overhead, and maintenance cost.
5 — Edge Aggregation
Covers pre-aggregating and filtering telemetry at the collection edge to cut cardinality and egress cost before it reaches the backend.
6 — Centralized vs Federated Observability
Contrasts a single global observability backend against per-region or per-BU federated backends with cross-federation query.