organization has been using Dynatrace Application Monitoring for a few months
now. Our initial drive was derived from
the needs of the middleware support team and we have achieved many good results
with the product.
Now we want
to be more efficient in our communication with the development teams. Initially we expected to be able to give
access to the rich client app to the developers. However, we understand that the number of
clients making heavy use of dashboards and drill-downs concurrently is very
limited. For example, a Large setup in Dynatrace 6.2 recommends at most 10
concurrent clients. There are hundreds
of developers in our organization.
love to hear some real world experiences regarding how to share this excellent
tool with the developers. Is the practice of exporting sessions the recommended
approach? Is it possible to limit the
number of simultaneous clients connected to the server? How about limiting the
number of simultaneous logins for specific users – e.g. allowing only one active
login for a given user?
I think we're probably one of the largest implementations of appmon anywhere. The approach we're taking is to get the personal install of dynatrace into the hands of the developers. Get them familiar with the IDE plugins for eclipse/Visual Studio. Help them understand the benefits within their local environment (localhost) for unit/component testing prior to integration into the larger product. From there the unit/load/acceptance testing happens on scheduled times and dashboard results don't need to be open all the time; reports can be generated. Production monitoring is the only time dashboards are really left up and open concurrently.
To add what David just said. I am also a big fan and promoter of the Dynatrace Personal License. We created that version especially for Developers and Testers so that they can use Dynatrace on their local machines. EVERYONE can register their own license by filling out this form: http://bit.ly/dtpersonal. They will then get a 30 DAy Trial License which will automatically convert to a Personal License after that period is over.
If you have a large number of Developers I suggest you download the installers once and distribute them - then just let them register their Personal License so that they have a license key on their local machine
This allows devs to become familiar with dynatrace, use it on their local code before checking in code changes. To give them access to PurePaths of your other systems They can either connect their client to these central servers or they can simply get the session files exported and imported on their local machine. If you have several developers that need to look at the same data I recommend installing a central dynatrace dev server that you just use for "hosting sessions" that several devs should look at. A Personal License for that server is also sufficient as it will just be used to host and distributed sessions to your engineering team.
very much for the valuable insights. They will certainly be very useful to help
us outline a strategy.
would be useful to elaborate a little more on our peculiarities. Without going
into too much detail, we would like to provide developers access to our
Dynatrace production server.
ensuring the middleware support and operation teams have a good performance
while using Dynatrace is our top priority. Thus we could benefit from some sort
of advanced user management.
instance, if we could limit the maximum number of connected clients for each
role, maybe that would be an acceptable solution, but it looks like the product
doesn't offer this option.
could simply export the sessions and share them for offline analysis, but that
would certainly be less agile then we (and certainly the developers) would
would like to know how other Dynatrace administrators address situations like
Unfortunately there is no limit that you can set. There is however one thing to consider. Every Dynatrace Client connects to the frontend server. The Frontend Server provides a handful of worker threads that handle incoming requests from your dynatrace client. I dont know the exactd number by heart but i think it is either 10 or 20. If you have a lot dynatrace clients connected and they all open and refresh dashboards these requests will actually be queued and then handled by the frontend server. this queuing should ensure that you cannot overload the dynatrace server.
Having that said I am still a big fan of exporting data on a shared dynatrace server that your devs then connect to to analyze large session files. Why? because analyzing session files means that the frontend server has to load the data in memory and using CPU to do the analysis. If you can "offload" this to a separate server you can better leverage the the resources of your Production Frontend Server