Project – Datadog Starter Observability Lab for Ubuntu

Uncategorized
Posted on | by Rajesh Kumar

Project name

Datadog Starter Observability Lab for Ubuntu

Project idea

Students deploy a very small web app on Ubuntu Linux and then connect it to Datadog step by step:

  • Datadog Agent for host and infra metrics
  • APM for request tracing
  • Logs for application logs
  • Synthetic Monitoring for uptime/API checks
  • RUM for browser/user monitoring
  • Alerts/Monitors
  • Dashboard
  • API call to read or create Datadog objects

This matches Datadog’s model well: the Agent runs on hosts and sends host telemetry, APM adds traces from the app, log collection can be enabled in the Agent config, Synthetic API tests monitor endpoints, Browser RUM captures page loads/actions/errors, monitors alert on thresholds, dashboards visualize the data, and the Datadog API uses API/Application keys. (Datadog)

Why this is good for basic students

It is small enough for 1–2 hours, but still gives them an end-to-end observability experience:

  1. run an app
  2. generate traffic
  3. see metrics
  4. see traces
  5. see logs
  6. test availability
  7. create alerts
  8. build one dashboard
  9. make one API call

Recommended app

Use a very small Python Flask app on Ubuntu with these endpoints:

  • / → normal page
  • /health → returns 200 OK
  • /slow → sleeps 2–5 seconds
  • /error → returns HTTP 500
  • /api/items → simple JSON response

Also write logs to a file like /var/log/studentapp/app.log, because Datadog’s Python log collection guidance is straightforward with file logging plus Agent tailing. (Datadog)

What students must do

1. About Datadog

Ask them to explain in 2–3 lines:

  • What Datadog is
  • Difference between metrics, logs, traces, synthetics, and RUM

2. Datadog Agent + Infra Monitoring

Install the Agent on Ubuntu and confirm the host appears in Datadog. The Agent is Datadog’s host-side collector, and Datadog’s Linux docs note the main config file is /etc/datadog-agent/datadog.yaml. (Datadog)

Student task:
Show these host metrics on screen:

  • CPU
  • Memory
  • Disk
  • Network

3. APM Monitoring

Instrument the Flask app with Datadog tracing so requests to /, /slow, and /error show up as traces. Datadog’s APM docs describe instrumentation as adding code/SDK support so the app sends traces, metrics, and related telemetry. (Datadog)

Student task:
Generate traffic and identify:

  • which endpoint is slowest
  • which endpoint throws errors

4. Log Monitoring

Enable log collection in the Agent by turning on logs_enabled in datadog.yaml, then configure the Agent to tail the application log file. Datadog’s log collection docs describe exactly this flow. (Datadog)

Student task:
Search logs and find:

  • all error logs
  • logs from /slow
  • one specific user request

5. Synthetic Monitoring

Create one API Synthetic test for /health. Datadog’s Synthetic docs say API tests proactively monitor important services and can check things like expected status code and latency. (Datadog)

Student task:
Create a test that fails when:

  • status code is not 200
  • response time is too high

6. RUM Monitoring

Add Datadog Browser RUM to the home page. Datadog’s Browser SDK docs say RUM can capture page loads, user actions, resource loading, and application errors in real time. (Datadog)

Student task:
Open the page in a browser a few times and confirm they can see:

  • page views
  • page load performance
  • a frontend click or user action

7. Alerts / Monitors

Create two simple monitors:

  • CPU high on the Ubuntu host
  • error count or failed Synthetic test

Datadog’s monitor docs say metric monitors alert when a metric crosses a threshold over a period of time. (Datadog)

8. Dashboard

Create one dashboard called Student App Observability with:

  • CPU timeseries
  • Memory timeseries
  • request count
  • latency
  • error count
  • log stream/list widget
  • Synthetic status

Datadog’s dashboard docs recommend organizing larger dashboards with tabs, but for this lab one simple dashboard is enough. (Datadog)

9. API

Use one simple Datadog API call:

  • list dashboards, or
  • create a dashboard/monitor

Datadog’s API docs say the API is REST/JSON and uses DD-API-KEY; some endpoints also require DD-APPLICATION-KEY. Datadog also notes API keys are required for the Agent to submit data. (Datadog)

Best 1–2 hour execution plan

First 20 minutes

  • run Flask app
  • install Datadog Agent
  • verify host metrics

Next 20 minutes

  • enable APM
  • hit /, /slow, /error
  • inspect traces

Next 15 minutes

  • enable log collection
  • view logs in Datadog

Next 15 minutes

  • create one Synthetic API test

Next 15 minutes

  • add Browser RUM to homepage

Last 15 minutes

  • create 2 monitors
  • build 1 dashboard
  • run 1 Datadog API call

Expected deliverables from students

Each team should submit:

  • screenshot of Infrastructure host page
  • screenshot of APM traces
  • screenshot of Logs search
  • screenshot of Synthetic test result
  • screenshot of RUM view
  • screenshot of 2 monitors
  • screenshot of 1 dashboard
  • one curl command for Datadog API
  • short note: “What issue did we detect fastest with Datadog?”

Very simple scoring rubric

  • Agent + host metrics working
  • APM visible
  • logs searchable
  • Synthetic test working
  • RUM visible
  • 2 monitors created
  • 1 dashboard created
  • 1 API call successful

Final project statement you can give students

Deploy a small Flask web app on Ubuntu and make it fully observable in Datadog using Agent, Infrastructure Monitoring, APM, Logs, Synthetics, RUM, Monitors, Dashboard, and one Datadog API call. Then generate normal, slow, and failing traffic and show how Datadog helps detect each condition.

My recommendation

Keep the project to one host + one app + one browser page + one synthetic test.