I work at Dynatrace as a Product Architect, which means I take care of non-functional requirements for our product. Right now, I spend most of my time developing our platform, thinking about how to make it useful for advanced data analytics and open it to external data sources. I am also very interested in leveraging Grail for internal use cases. I believe that internal adoption is a perfect way to learn what our customers also need.
Certainly, it is the product, but so are its users. For 25 years, I have enjoyed creating software that helps in the day-to-day lives of engineers like me. This is also why I see value in Dynatrace Community – a place where you can dialog with users.
🔹 We can make it express the needs we learned from our customers over multiple years of our experience and decide how to do it best.
🔹 We decide on the priority of the use cases we address. As we gather primarily observability-oriented data, we focused on providing means to analyze it.
🔹 We can introduce unifications when needed: in the past version of Dynatrace, we had several different languages: one for querying logs, different for metrics, different for entities, and different for real user and synthetic monitoring. Now, we end up making all these data sources behave similarly, and query the same way, and joint analysis is possible and easy to proceed with.
🔹 We can also introduce specialization when needed: reaching for metrics differs from for logs. It spans as their nature differs, but later processing (like filtering, summarization, or joining) is done similarly to maintain a unified experience.
🔹 Also, we can go beyond our traditional use cases and dive into advanced analytics, predicting behaviors and detecting anomalies.
...because it is new and unique. No one knows it from university, previous jobs, or other tools. This is a novelty to some users, something to learn that may feel scary or unnecessary (“because I know SQL already”).
This is the moment when we need to support built-in ease of use of the language with proper help and explanations. Questions and doubts may be about, e.g., general about syntax (how to express something) or very specific about a particular problem (how to get an answer for my question). The quality of this support will decide the speed of adoption and the value that can be obtained from our platform.
In many cases, there is more than one good answer to the question asked. My best practice is to give more than one option and explain the differences. This allows a reader to think again about the problem and analyze different paths to achieving the goal vs. copying a given solution. In many situations, it allows for a better understanding of the DQL language tailored.
What comes with full control of one's own language is the great responsibility: it is easy to migrate users from one product screen to another, but it is very difficult to do so when someone invests days or months of work creating dedicated notebooks, dashboards, or applications. As a result, each addition to DQL has to be thought through and proceeded by deep study because what is added there will stay for years. Any interaction with a user, especially one curious and eager to achieve a specific goal, is a perfect source of needs and feedback on what we already allow.
Asking questions on the Community forum as the next step after one’s own attempt to find a solution and searching out manuals is a very good approach. Still, it also means that documentation and other resources don’t sufficiently cover the topic.
The same questions hint us to where the documentation needs to be improved by documenting syntax better, providing simpler or richer examples, addressing sets of use cases around specific commands, or maybe delivering complete examples in the form of a notebook explaining step-by-step real-life problem-solvable in a set of logical steps in DQL.
To sum up, Dynatrace Query Language (DQL) is a powerful tool to explore your data and discover patterns, identify anomalies and outliers, create statistical modeling, and more based on data stored in Dynatrace Grail storage.
DQL offers maximum flexibility because it is built for processing arbitrary event data, requiring no up-front description of the input data's schema, contrary to relational databases like SQL tables.
The only way to understand DQL better is to try and use it. 🙂 We encourage you to do that with the help of vast Dynatrace learning, self-service, and support resources.
🔹 Grail documentation
🔹 DQL (Dynatrace Query Language) documentation
🔹 DPL (Dynatrace Pattern Language) documentation
🔹 Learn DQL App A learning environment that guides you step-by-step through a given set of exercises
🔹 Learning Dynatrace Query Language (DQL) YouTube series - key commands of DQL explained, developers, demonstrating how to apply them for different use cases
🔹 DQL Q&A forum
🔹 Developer forum This is a community for developers. Share some knowledge, ask questions, find the best answers, connect with others, and explore the best practices for creating apps on the Dynatrace Platform.
🔹 Automations Q&A forum All questions related to Workflow Automation, AutomationEngine, and EdgeConnect, as well as integrations with various tools.
🔹 DQL course on Dynatrace University
🔹 Expanded Grail data lakehouse and new Dynatrace user experience unlock boundless analytics Blog article
🔹 Use cases addressed with DQL for different functional areas:
• Business event analysis and examples
• DQL examples for security data
• Data-driven cloud tuning
🔹 Use cases addressed with DQL for different types of data:
• Log on Grail examples
• Metrics on Grail examples
🔹 All recordings related to DQL on the Dynatrace YouTube channel