How I passed the Dynatrace Associate Exam

Introduction

At the start of this year I set myself a goal to get at least certain DevOps and monitoring related certifications before the end of year 2018. Any Dynatrace related certification was one of them. I recently attempted the Dynatrace Associate Exam and achieved 82%, while the passing percentage was 72. I have been using Dynatrace Managed daily at my current job for the past six months or so, mostly for debugging and analysis of performance problems. However, the blueprint of the Associate exam suggested quite a few topics that I needed to work on so I could feel comfortable.

My goal in writing this article is sharing my own experience about the preparation and the exam as there wasn't much found while I looked for it myself.

Some info about the exam

Before I booked the exam all I knew about the exam was that it was multiple choice questions. A Dynatrace consultant who took the exam mentioned that it is primarily about knowing where features lie in the tool. Upon investigating a bit on the Dynatrace community, I found that the Associate level certification intends to check the following:

- That the user is aware of all Dynatrace features/dashboards/reports available in the tool from analysis/outcome & navigation point of view.

- User is aware of all the supported monitoring capabilities.

- User has experience real life use cases


Based on the above the following is how I went about preparing for the exam.

The preparation

since I had been working with Dynatrace already for the past six months or so, I gave myself two weeks of dedicated effort to prepare for the exam while I had been on vacation visiting my parents.

I decided to start with those recorded videos and judiciously watched the infrastructure and analysis related sessions. After about a week of watching these recordings, I decided to test myself out using the mock test. I managed 66% in the test while the passing was 100% i.e. getting all the 15 mock test questions right. This was a reality check and what I found lacking was my understanding of the global/local settings and the terminology. That is when I decided to fall back at the Dynatrace online documentation. While I read the documentation, I also played around in the tool and familiarised myself with Dashboards, Custom graphs, Smartscape, Reports, Applications, Process groups, Services, Databases, and the uniqueness of all the views. I also suggest familiarising with the process views based on their technologies such as Java, .NET, etc. I also made sure I familiarised with the counters especially the application related such as Appdex, bounce rate and the server side stats based on respective graphs.

While I went through the glossary definitions I also decided to watch the Dynatrace university videos so as I also get familiarised with the application navigation and the terminology used. I then decided to test myself again with the mock test and fared much better with 13.2 questions right out of 15.

Besides the above, following were some tips from the Dynatrace community regarding preparation for the test:

- Reading documentation exhaustively and follow this up with hands-on using the Dynatrace free trial(15 days)

- Download and refer to the blueprint and the mindmap of the exam.

- Covering all videos in university: this can be done basis your convenience as a mix up with hands-on and documentation reading.

- Attempting the free mock test available (once in 24 hours) to get actual taste of the test.

- Keeping a close watch on community discussions to give you taste of real life issues & their corresponding solutions

The exam day

Having done my best, I finally decided to revise what I had already learnt right before the exam.

At the exam, once you login to Examity you need to connect to the proctor and confirm your identity.

Since I gave the exam from home, some of the other things I worried about were my home internet connection, connectivity with the proctor and other unwanted disturbances by family members who would visit often. I took my time in the exam and focussed on each question until I was comfortable with an answer. I wanted to answer the questions just once and did not want to come back to the them later. The proctor interrupted me mostly as I ventured out of the webcam screen. I finished the barely before the stipulated time and soon received my score. The proctor then checked the completion and asked the download of the certificate before closing the session.

Working as a consultant

When I first started working as a consultant which was no more than a few months back, I was told that the it is about taking the client on a journey.

So, what are my experiences about being a consultant as compared to working as an engineer in a product company.

1) As a consultant you need to know contractual and time limitations. You should be able to make a decision on whether something can be done or not. While in a product company there is a lot more team involvement in what needs to happen.

2) You need to be more professional in terms of the assignments that come across. This is to do with right from time management to documentation to communication with the stakeholders. In a product company, it again goes down to the team that you work for especially in an agile environment.

3) More responsibility on individuals rather than the team. If things go wrong the blame goes to the consultant rather than the team.

The above are general observations.

Working with people

I consider myself as a individualistic person. Working alone on a challenging assignment is an ideal situation I thrive in. However, working with people is an important aspect of finishing a work on time and with better quality. So here are a few situations I have faced and perhaps how I should have handled them.

1) You are new in a job and are struggling with the process, tools and the setup and end up slowing down the schedule.
- Calm down, its common to be struggling in a new assignment unless you are a genius. For a guy like me who is not the fastest learner, I would suggest putting in extra hours, gaining confidence, being thorough with new things encountered today and reflecting on what went wrong.

2) You are dedicated to get the job done with high quality, however the one with you lacks motivation.
- Do your best. Try and help out whenever needed but only when your tasks are completed. I say this as it has been noticed many a times that people blame others when things go wrong but take credit when things go right. Hence it is important to finish your own work before helping out unless you are sure of the colleague you are working with. It can also be frustrating when dealing with people who act that they are working but in reality are only working for the final paycheck and expect blockages so that work can be procrastinated. Try and avoid arguments, escalate if things don't happen as it should be to achieve high quality objectives.

3) Work place politics, jealousy.
- It is very difficult for humans to robots (LOL) hence politics, jealousy and other such resistance is best avoided by focusing on the goals. This may make you fewer friends but would surely make you work better. However, it may be difficult to be neutral when the problems at work involve you as well. It is best to remind yourself what your duties at work are and stay professional at the place you are paid to do a job.

Load test crashed - Load Runner

Many a times we see that the load test crashes due to various environmental or test tool related factors. A Good part about Load Runner to what I used to work on is the reporting.  Hence most of the times when crashes occur and the results files tend to not have the stop times. Hence there tend to be errors while opening the analysis files.

Fix the error by opening the lrr file in a text editor and add the stoptime parameter as the current unix epoch time. Here is one link to find the same.

Performance Engineer.. vitals

So, what are some of the key attributes one must have to be a better performance engineer? 

I have always had this question. This may perhaps be because I was a lone wolf performance tester/engineer in most of my roles and never had a mentor or a senior engineer for guidance. Any, opportunity I had to pick peoples brains was used upon whenever possible. Those 15 or 30 minute interactions I had with engineers have gone a long way in developing ideas, gaining vital knowledge and building confidence. I even once asked a naive question as to how can one judge a good performance engineer, to which I got an answer that said you never judge one as everyone has his/her own distinct qualities.

But still, how do one become a better performance engineer. After working at a few places and interacting and reading about this I have here a list of few key attributes that I suggest performance engineers or aspirants should have a look at.

For those who want to make a start with performance testing, start off with learning a performance testing tool. JMeter is a good start, however with other tools such as Load Runner I have known so many extra and important feature which are not there in JMeter. Next I suggest learning a bit about server monitoring, server resources to measure, response times and a little bit about statistics. Zabbix is one good open source tool for remote monitoring. It is advisable to keep building knowledge as you progress. Load testing is dangerous and it is advisable to be judicious with the test application you choose or the load you generate. This was a little para about starting with Performance testing. I will perhaps write a separate post on this later.

Now for the intermediates, try and pay attention to detail always, especially with analysis:

·          Every load test you run the one graph you need to pay attention to detail is the Response time graph.

·          Ignoring a spike or ignoring different requests can be disastrous. 

·         Correlation with a corresponding abnormality you see in other graphs, resources or parameters you are monitoring is the next step.

   

     Some advice:

It is also important to fully confirm what the requirements are and what happened the last time the test was run. When you join a new project or are assigned to a new task, just spend some time knowing the requirements thoroughly and the older reports if there are any.

For ongoing projects try and understand what happened, especially for response times and defects.

Performance engineers are expected to provide analysis and recommendations hence analyse data for potential bottlenecks or at least specify that analysis is coming soon in order to avoid any repercussions.

Assertions who? Yes they are vital

I have seen many a time that performance engineers skip using Assertions in load generation scripts. Many a times they assume that anything returned as an error by the tool itself such as a 404 or the 500 family errors are the only errors that need to be verified. However, there is more to a response than just the status code. For a perfectly valid output response all the resources related to the page need to be present and not just the base page/data for the request.

These are a few points for which assertions should always be present in a performance or load script:

1. Absence of assertions may result in response times being inaccurate as all the resources may not have been downloaded properly.
2. For performance testing tools a 200 OK and similar success tools suggest the affirmative whereas in a performance testing use case such as the ones with login activity even an incorrect login is treated as not an error. This hence does not show the correct picture for the performance engineer. the idea should be to simulate the correct user behavior. Hence adding an assertion or many assertions to check whether a user has logged in correctly does make sense.
3. Sometimes especially for web services, we may have 200OK responses without any meaningful data or with mostly blank data. Assertions help catch such issues.

Now people would argue that assertions consume memory. True, they do but the cost of an erroneous load test is much higher. 

Assertions can be equivalent to unit tests in software programming. Too many meaningless unit tests add less value and only increase the time of builds. Similarly, assertions used cleverly gives huge security. Use few assertions but make sure you use them. One good example of assertions on a page or response is the most frequent text/link/resource the user is expected to view on the page. Next best assertion type is the page response size. Both the above mentioned assertion types are critical and light weight respectively and are advised to be used.

Performance testing environment

One of the very essential things for implementing performance testing for a web application is to have a suitable performance testing environment. Ideally, it should be a replica of the production environment. However, as the production environments tend to normally be quite expensive, reproducing them for a non functional testing activity such as performance testing does not make for a good business case. Hence, most small and medium scale IT businesses tend to undergo their performance testing on the same environment that they undertake their other testing activities on.

One thing to note about performance metrics for a website is that we cannot scale results. Test environments have hardware far less capable of handling as many users as what the production systems can handle, would certainly have different performance results. The results achieved for the tests on the performance environments are far difficult to scale to match the hardware capabilities of the production environment. For a test environment which is a replica of the production environment the results could be straight away used to predict the performance of release code. But as in most cases where the test environment is not the same as the production environment how do we predict the performance wise health of a release? This was a question I had put across to one of the senior managers from another branch of the project that I worked for. He first said that he was lucky to have an environment that was similar to the production environment, so he didn't have to bother about such a situation. But to answer my question, he said if he were in my situation he would try and extrapolate results by plotting a graph based on numerous tests with incremental hardware capabilities.

Eg.
For a production web server with following hardware specifications:

• 16GB RAM
• 8 cores
• 160 GB Disk space

We would have to start a performance test with web server in the test environment having specifications 2 GB RAM, 1 core, 20 GB disk space (assuming the network bandwidth is similar) note down results, and then increase hardware specifications to 4GB, 2 cores and 40GB of hard drive space and note down results again. This way we can plot a graph of parameters against response times and extrapolate results to predict results in the production environment.