15.1 Notebooks: Section-Based Investigation & Shareable Analysis
Key Takeaways
- Dashboards is a separately scored Associate exam topic, and the official learning path devotes a full lesson to Notebooks and Dashboards together.
- Notebooks are organized into sections — DQL query sections, code sections powered by Dynatrace functions, and markdown sections for narrative.
- Notebooks are the investigation and storytelling surface: the analytical narrative is stored inside the notebook itself, whereas a dashboard is something you view.
- The standard incident workflow is to investigate in a Notebook, then promote the queries that proved useful into a Dashboard for ongoing monitoring.
- Notebooks can combine logs, metrics, traces, business events, and markdown commentary in one document because every data type is queryable with DQL against Grail.
Dashboards is one of the twelve scored topics on the Dynatrace Associate exam score report, and the official learning path pairs it with Notebooks in a single lesson: "Notebooks enable custom exploration and visualization of observability data, integrating external sources and predictive analytics within interactive documents. Dashboards provide continuous monitoring and visualizations of key performance metrics."
The exam tests whether you can pick the right one for a given task, so start with the distinction and then learn each tool.
The Core Distinction
Data in a notebook is stored within the notebook; a dashboard is something you view.
That one sentence carries most of the exam weight. A Notebook is a document — it holds the queries, the results, and your written reasoning, so it can be handed to somebody who was not in the incident call. A Dashboard is a live view — it re-queries continuously and shows current state, but it does not carry an argument.
| Notebook | Dashboard | |
|---|---|---|
| Organized into | Sections | Tiles |
| Primary purpose | Investigation, root-cause storytelling, analysis | Continuous, real-time monitoring |
| Reading order | Top to bottom, like a document | At-a-glance, all tiles simultaneously |
| Contains narrative | Yes — markdown sections between queries | Only via markdown tiles |
| Typical audience | Analyst, incident reviewer, stakeholder briefing | NOC, on-call, service owner, executive wall |
| Typical lifespan | One investigation | Ongoing |
Notebook Sections
A notebook is a sequence of sections, and there are three types you must know:
Query section
The query section consists of a query input where you write a DQL query. Results render as a table or chart, and the visualization can be changed without altering the query. This is where the analysis happens:
fetch logs, from: now() - 2h
| filter k8s.namespace.name == "checkout" and loglevel == "ERROR"
| summarize errors = count(), by: { k8s.workload.name }
| sort errors desc
Code section
The code section enables you to fetch data for your notebook using Dynatrace functions. This is how a notebook reaches beyond Grail — calling an external API, applying a transformation Grail does not express natively, or blending platform data with a third-party source.
Markdown section
A markdown section can be anything from a minor note about something on the notebook to a whole page of formatted information with links and pictures. This is what turns a pile of queries into an artifact somebody else can read: the hypothesis, what was ruled out, and the conclusion.
The Canonical Investigation Flow
The learning path's Playground exercise is deliberately this shape, and exam scenarios mirror it:
- State the question in a markdown section. "Checkout latency doubled at 14:05. Which layer?"
- Query the service to confirm and scope the degradation.
- Query the infrastructure to test the host hypothesis — and write down that it was eliminated.
- Query the logs for the affected workload in the same window.
- Query business events to quantify what it cost (Chapter 14).
- Conclude in markdown, then share the notebook.
Because every one of those steps is DQL against Grail, a single document spans logs, metrics, traces, and business events with no tool switching. That cross-data-type capability in one document is a recurring exam theme.
Notebooks and Predictive Analysis
Notebooks integrate external sources and predictive analytics, which is how capacity questions are answered inside the platform rather than in a spreadsheet: fit a trend over historical usage and project when a volume, licence pool, or cluster reaches a threshold. The exam does not require you to write the forecast, only to know that a Notebook — not a dashboard tile — is where analysis of that kind belongs.
Promotion to a Dashboard
The two tools are stages of one workflow, not competitors. The official call to action is explicit: create a Notebook with DQL and markdown tiles, then do the same in a Dashboard and consider how the apps differ.
The operational rule:
Investigate in a Notebook. Once a query has proven it detects a real, recurring condition, promote it to a Dashboard tile so it is watched continuously.
A dashboard assembled from queries that were never validated during a real investigation is how organizations end up with wall displays nobody trusts. Exam answers that propose building a dashboard first to explore an unfamiliar problem are working backwards.
Access, Sharing, and Governance
Notebooks and dashboards are documents with sharing controls, and they are managed through the Document API for programmatic creation and version control. Two governance points appear in scenarios:
- Management zones and segments (Chapter 12) constrain what a viewer can see, so the same shared notebook can legitimately show different results to different readers.
- Sharing a notebook does not grant the recipient permission to data they could not otherwise query. Permissions are evaluated on the reader, not baked into the document.
After a two-hour incident, an engineer must hand a complete account of the investigation — the hypotheses tested, the queries run, what was ruled out, and the conclusion — to a stakeholder who was not on the call. Which Dynatrace surface is designed for this?
A team is unfamiliar with a newly reported performance issue and asks whether to start by building a dashboard for the affected service. What is the better approach and why?
Within a single notebook, an analyst needs to combine a DQL query over logs, a call to an external system, and written commentary explaining the finding. Which notebook section types support this?