Huzaifa Muhammad

03 · Observability

Know What’s Happening Under the Hood.

AWS Observability Platform for Tabulae

A monitoring platform for the Tabulae application that brings together infrastructure metrics, centralized container logs, endpoint availability checks, and alert evaluation. The stack was tested locally with Docker Compose and then deployed to AWS on a separate EC2 instance.

Availability probes, alert rules, and log collection verified · Notifications not yet configured

  • Prometheus
  • Grafana
  • Loki
  • Grafana Alloy
  • Blackbox Exporter
  • Alertmanager
  • Node Exporter
  • cAdvisor
  • Caddy
  • Docker Compose
  • Terraform
  • AWS EC2
  • AWS Systems Manager
View repository

01Overview and objectives

Earlier projects focused on deploying applications. This project focused on understanding their behavior after deployment: whether endpoints are reachable, what application logs reveal, and when a failure should trigger an alert.

The challenge

A homepage loading successfully does not provide enough visibility into an application's health. The platform needed to check application endpoints, collect container logs in a searchable location, monitor infrastructure metrics, and evaluate availability alerts while protecting the monitoring interfaces.

02Architecture

AWS observability platformA Tabulae application host runs Docker containers, Node Exporter, cAdvisor and Alloy. A separate monitoring EC2 instance runs Prometheus, Blackbox probes, Alertmanager, Loki and Grafana behind Caddy HTTPS with authentication. Alloy ships logs to Loki, Prometheus scrapes metrics and probes the app, and a rule fires TabulaeEndpointDown to Alertmanager. Terraform provisions the EC2 and security group, and access is through Systems Manager.TABULAE APP HOST · EC2Tabulae containersfrontend + backendNode Exporterhost metricscAdvisorcontainer metricsAlGrafana Alloycollects container logsMONITORING HOST · EC2Prometheusscrape + alert rulesAmAlertmanagerTabulaeEndpointDownBbBlackboxHTTP probesLkLokiprivate log storeGrafanametrics + logsCCaddyHTTPS + authrule firesscrapeprobelogsPROVISIONING AND ACCESSTerraformEC2 + security groupSystems Managershell access, no open SSH
Metrics and logs flow from the Tabulae server to the monitoring server.

Application and Infrastructure

Tabulae runs on its application server, while the monitoring platform runs on a separate AWS EC2 instance.

Metrics and Availability

  • Blackbox Exporter probes the Tabulae backend health endpoint and frontend.
  • Node Exporter exposes host-level metrics.
  • Prometheus collects metrics and evaluates the TabulaeEndpointDown alert rule.
  • Grafana provides dashboards and an availability panel.

Logs

Tabulae containers → Grafana Alloy → Loki → Grafana Explore

Alloy collects the selected Tabulae container logs and forwards them to Loki for querying.

Alerting

Prometheus alert rule → Alertmanager

The availability rule is evaluated by Prometheus and passed to Alertmanager.

Email or chat notification delivery is not configured yet.

03How it was built

  1. Local development: Built and tested the monitoring stack using Docker Compose before deploying it to AWS.
  2. AWS deployment: Ran the monitoring platform on a separate EC2 instance from the Tabulae application server.
  3. Availability monitoring: Configured Prometheus scrape jobs and Blackbox Exporter probes for the backend health endpoint and frontend.
  4. Alert evaluation: Added the TabulaeEndpointDown rule to detect a failed probe that persists for one minute.
  5. Infrastructure dashboards: Imported the Node Exporter Full dashboard and created a panel for Tabulae endpoint availability.
  6. Centralized logs: Configured Grafana Alloy on the application server to collect Tabulae container logs and forward them to Loki.
  7. End-to-end log verification: Generated a fresh backend health request and confirmed that its log entry appeared in Loki.
  8. Access protection: Put monitoring interfaces behind Caddy with HTTPS and authentication, kept Loki off the public internet, and used AWS Systems Manager Session Manager for administration.

Verified in the repository

  • Docker Compose stack with version-pinned monitoring components.
  • Blackbox probes for the Tabulae backend health endpoint and frontend.
  • TabulaeEndpointDown alert rule with a one-minute failure duration.
  • Alloy configuration for collecting Tabulae container logs and forwarding them to Loki.
  • Grafana datasource provisioning and an availability panel.
  • Terraform configuration for AWS networking, a restricted security group, and an EC2 instance.

04Decisions and trade-offs

Probe Real Application Endpoints

Blackbox Exporter checks the endpoints users depend on. This helps identify availability problems that basic process or container status alone may not reveal.

Keep Application Logs Focused

Alloy filters for Tabulae containers before forwarding their logs to Loki, making application troubleshooting more focused.

Separate Local Testing from AWS Monitoring

Docker Compose provides a local environment for testing configuration changes. The AWS deployment monitors the running application from a separate instance.

Protect the Monitoring Platform

Monitoring dashboards and logs can expose operational information. HTTPS, authentication, restricted Loki exposure, and Session Manager administration help reduce unnecessary access.

Pin Component Versions

Fixed image versions make the monitoring stack more predictable and reduce unexpected changes when it is restarted.

05Security considerations

  • Monitoring interfaces are protected by Caddy with HTTPS and authentication.
  • Loki is not exposed directly to the public internet.
  • AWS Systems Manager Session Manager is used for server administration.
  • Credentials and environment files are kept out of Git; an example environment file is provided instead.
  • The Terraform security group restricts SSH access to a designated address.

Example Loki queries

All Tabulae logs

{job="tabulae"}

Health-check requests

{job="tabulae"} |= "/health"

06Evidence

Availability monitoring: the Grafana availability panel displays the Tabulae endpoint status based on Blackbox Exporter probes.
Infrastructure monitoring: the Node Exporter dashboard displays host-level metrics such as CPU, memory, network, and disk usage for the monitoring server.
Centralized logs: frontend and proxy log lines shown in Grafana, including the Blackbox Exporter health probes.
Centralized logs: backend application log lines shown in Grafana.

07Scope and next steps

This project provides infrastructure metrics, endpoint availability checks, centralized Tabulae logs, and Prometheus alert evaluation. The alert rule is connected to Alertmanager, but email and chat notifications have not yet been configured for this platform.

Cluster-level monitoring with email alerts is demonstrated separately in the Saleor on EKS project.

Potential improvements

  • Configure email or chat notification delivery for availability alerts.
  • Add application-specific metrics.
  • Document dashboards with annotated screenshots.
  • Automate deployment and configuration validation.

Related projects

01Cloud platform

Saleor E-Commerce on Amazon EKS

Terraform builds the network, IAM and EKS cluster. Kubernetes runs the Saleor API, dashboard and worker behind an Application Load Balancer with HTTPS, backed by Amazon RDS.

  • AWS EKS
  • Terraform
  • Kubernetes
  • Docker
Read the case study
02Delivery & security

Secure CI/CD Pipeline for Tabulae

GitHub Actions runs backend tests, frontend checks, Docker builds, secret and dependency scanning, and publishes images to Amazon ECR using OIDC.

  • GitHub Actions
  • Docker
  • Pytest
  • PostgreSQL
Read the case study
04Infrastructure automation

Infrastructure Automation with Terraform, Ansible and Jenkins

Terraform with S3 remote state, a Jenkins pipeline with a manual approval gate, and Systems Manager commands that start and verify Nginx on EC2.

  • Terraform
  • Jenkins
  • Ansible
  • AWS EC2
Read the case study