Dynatrace — quick tutorial notes (your outline, cleaned + expanded)
1) What is Dynatrace?
Dynatrace is an Observability (Obs) platform that unifies:
- APM (traces + service performance)
- Infrastructure monitoring (hosts, processes, containers, K8s, cloud)
- Logs (ingest, search, correlate)
- Digital Experience / RUM (real user monitoring)
- AI-assisted problem detection (Davis) and alerting/problem workflow (Dynatrace Documentation)
2) Monitoring vs Observability (the “future vs past” idea)
Your statement is a useful mental model:
- Monitoring: Events → Past → Alert → Human takes action
- Observability: Events + context → Predict/Detect earlier → Alert → (Often) auto / guided action
Dynatrace leans toward observability by automatically correlating signals (metrics/logs/traces + topology) into Problems with root-cause guidance.
3) The universal pipeline
Collect → Store → Analyze → Alert → Dashboard
Dynatrace mapping (typical):
- Collect: OneAgent (+ extensions, OpenTelemetry, log ingest)
- Store: Dynatrace backend (SaaS/Managed)
- Analyze: Davis AI + distributed tracing + entity model/topology
- Alert: Problems + alerting profiles + integrations
- Dashboard: Dashboards / Notebooks / Explorer views
4) High-level architecture
[Servers / VMs / K8s Nodes / Cloud]
|
ONEAGENT
|
Dynatrace backend
|
UI (Apps, Dashboards, Notebooks)
|
PROBLEMS (Davis)
OneAgent is the “single agent” that auto-instruments many stacks out-of-the-box (Dynatrace Documentation)
5) MELT model in Dynatrace
MELT = Metrics, Events, Logs, Traces
In Dynatrace, these combine into a single “story”:
- Metrics → counters/gauges/timers (infra + app)
- Logs → text records (app/system)
- Traces → spans/transactions across services
Dynatrace correlates these into entities (host, process, service, pod, namespace, database, etc.) and then into Problems.
6) “What gets monitored?” (your list)
Dynatrace commonly covers:
- Servers/OS, Docker, Kubernetes, Cloud
- Apache, Tomcat
- MySQL
- Network / synthetic checks / RUM (depending on setup)
OneAgent supports broad technology coverage and modules by platform (Dynatrace Documentation)
Hands-on labs (based on your links)
Lab A — Deploy OneAgent as a Docker container (container platforms)
Use this when you want OneAgent running as a container on a Docker host / container platform.
Official guide: Set up Dynatrace OneAgent as a Docker container (Dynatrace Documentation)
(You’ll copy the installer URL/token from Dynatrace UI as shown in that doc.)
Key outcome:
- OneAgent container runs on the host and can provide full-stack/container monitoring (depending on mode and platform).
Related Docker setup hub page (overview/entry point) (Dynatrace Documentation)
Lab B — Deploy OneAgent at scale (orchestration)
If you have many hosts, don’t do it manually.
Dynatrace provides deployment orchestration scripts, including an Ansible collection path (Dynatrace Documentation)
Use-cases:
- Standardize agent rollout
- Controlled upgrades
- Consistent tokens / endpoints / tags
Lab C — Install a demo app: easyTravel on Docker (great for demos)
This is the quickest way to generate real telemetry (services, traces, DB calls, errors, response time, etc.).
Repo: Dynatrace easyTravel-Docker (GitHub)
Typical flow:
- Clone the repo
- Configure Dynatrace endpoint/tenant vars (as README describes)
- Start the stack (often via docker-compose / scripts in the repo)
- Generate traffic
- Watch Dynatrace auto-discover services → see traces → see Problems
(Your DevOpsSchool post also references the same “sample app for demo/lab” idea.) (DevOps School)
Lab D — OneAgent CLI basics (host-level operations)
Dynatrace has an official CLI reference for oneagentctl used for post-install configuration on a host (Dynatrace Documentation)
Common things teams do with oneagentctl:
- Set monitoring mode
- Networking/proxy settings
- Host tagging (depending on environment)
- Troubleshooting agent status
Your DevOpsSchool CLI reference can be used as a quick “cheat sheet” too (DevOps School)
“Problems” view (your Dynatrace UI link)
You shared a Problems URL from your tenant, but it requires Dynatrace login so I can’t read its contents directly from here. What you’ll typically validate on that page:
- Problem title + impact (services/users)
- Root-cause entity (host/service/pod/process)
- Contributing events (deployments, resource saturation, errors)
- Related traces/logs/metrics in one timeline
If you want, paste a screenshot or the text from that Problem page and I’ll turn it into a clean incident-style note (symptoms → impact → root cause → fix → prevention).