Member of the Month for May 2024: Employee

[AgataWlodarczyk]

Introducing Member of the Month!

Architects, developers... They plan and build, but in IT, not buildings. 😉 Although, as we sometimes look at advanced programming code, its length is greater than really high buildings.

This month, we're very happy to introduce you to Kris Hoja, product architect from Dynatrace. In general, architects plan what developers produce. Also, information technology project managers blend the roles of these two professions to manage a project from the early planning stages all the way through implementation.

But what exactly does @krzysztof_hoja do daily, and what message does he want to give you? Answer you'll find in this article.

Hello Kris! Shed some light on your job and what interesting things you’re working on.

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.

What excites you about being a part of the Dynatrace/ projects you worked on?

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.

What can help engineers solve issues they encounter in their daily jobs?

DQL + DPL (and Grail in general) is our great innovation, enabling platform thinking and allowing customers to solve use cases where we didn’t provide solutions out of the box

The fact that we control query language destiny has many advantages:

" We can make it express the needs 
we learned from our customers
over multiple years of experience
and decide how to do it in the best way. "

🔹 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.

It may be perceived as a disadvantage...

...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.

Questions asked on Community
show how customers are using the product, what their needs are,
and what challenges they are facing.

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.

Useful links:

🔹 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 

Thank you!

Kris, thank you for your involvement in creating this article and all your very substantive contributions on the Dynatrace Community. Forum members and the Community Team appreciate it a lot! And, to be honest, we're looking for more! 😄

Member of the Month articles explained!

Member of the Month is a series of articles posted at the start of every month to honor the most engaged Community Users among our customers, business partners, and employees. We’re patiently observing the contribution in all aspects of the everyday forum run to award those who make the Dynatrace Community a valuable place to be! In the next chapters, you’ll read personal and professional highlights, as we’re all fascinating human beings with a unique story behind us. Who knows, maybe you’ll be here next month?