dynaTrace 6.0 – Core Diagnostics

1. dynaTrace 6.0 – Core Diagnostics

2. Prerequisites Students have received Core Concepts Training dynaTrace installed easyTravel with custom userscenarios.xml installed

3. Agenda Sensors Custom Entry Points APIs Configurations Business Transactions Basic Diagnostics

4. Sensors

5. Sensors – Delivering End-To-End Context Data • Context information • HTTP Parameters • Session attributes • SQL Statements • Bind values • Arguments & Return values • Exception details • Log messages • Number of invocations • Entry Points • User Actions • Web Requests • Web Service calls • Batch processing • Fat Client calls • Communication across tiers • Web Service • WCF • Remoting • Messaging • Custom Protocols

6. Available Sensors Defines which Sensor Packs are visible in the Agent Group for Placement “Add Tier” Wizard will select the right technology

7. dynaTrace Sensors Types • Out ofthe Box Sensors Information on an example PurePath Tree

8. dynaTrace Sensors Types • Auto Sensors Information on an example PurePath Tree

9. dynaTrace Sensors Types • Custom Sensors Information on an example PurePath Tree

10. Sensors Packs (OOTB and Custom) capture Contextual Information • Capture contextual information per transaction • Method arguments and return values, e.g.: which search keyword was used? • Number of invocations per transaction, e.g.: how many calls into the authentication framework? Custom Sensor forfindJourneyByLocation Custom Sensor captures Method Arguments

11. Analyzing Custom Sensor Data • Using Contextual Data in Business Transactions • How many bookings per destination? • How many executed searches?

12. Sensors are placed per Agent Group/Tier • Using the Add Tier Wizard will pre-select all correct Sensor Packs based on selected Technology Placing a Sensor will impact Byte Code Instrumentation ofAgentsthatmaptothis Agent Group/Tier

13. Sensor Configuration • Placed Sensors can be configured to change the behavior Capture Bind Values or not? Capture Message Content or not?

14. Special Sensor Pack Properties • Special Sensor Properties for Database, Web Requests, Messaging, … • Control level of detail that gets captured • Control overhead introduced with capturing • Examples on Sensor Pack Properties

15. Best Practices on Sensor Pack Properties • Exception Sensors • Exclude common Exception classes, e.g.: System.Data.*, java.*, javax.* • Do not capture Call Stack -> Exception Message is usually enough • Database Sensors (JDBC, ADO.NET) • Disable Bind Value Capturing • Use Database Aggregation • Trim SQL to < 100: Long SQL Statements are often created by Frameworks and not interesting for detailed SQL Analysis • Logging Sensors • Exclude certain severity levels, e.g: DEBUG, INFO, FINE, WARN, … • Web Requests Sensors (ASP.NET, Servlet) • Exclude URLs for static resource requests, e.g: images, css, javascript • Only capture parameters that you need for Business Transactions – avoid using “*“ (asterisk) for Attribute column

16. Make Bulk Configuration Changes to Sensor Properties • Can Apply changes to just this Agent Group or to this and other Agent Groups

17. Hands OnSensor Properties

18. Hands On: Sensor Properties • Goal: Turn on Sensor Properties to capture more detail • Scenario • Core Training -> Standard • Steps • In the BusinessBackend Agent Group, edit the JDBC Sensor Properties and enable Bind Value capturing • In the dotNetBackend Agent Group, edit the ADO.Net Sensor Properties and enable Bind Value capturing • Open the Database Dashlet and display Bind Values (either dashlet button bar or right-click->Group by) • Verify that you can now see Bind Values.

19. Custom Sensors

20. Managing Custom Sensors • Custom Sensors are organized per System Profile in Sensor Groups Unique Sensor Group Name per Technology (.NET/Java) Add/Edit/Remove Sensor Groups Sensor Rules that define which methods to instrument and what contextual information to capture

21. Adding Sensor Rules – Class Browser IMPORTANT: ONLY SELECT METHODS THAT ADD CONTEXTUAL VALUES. AVOID INSTRUMENTING FULL PACKAGES or CLASSES Auto Sensors will take care of the rest • Through the Class Browser 1. Select Agent Group 2. Load Information 4. Pick packages/classes/methods to instrument Hint: Methods in italic are already covered by existing Sensor Packs / Sensor Groups 3. Search for method names or argument names. You can even use fully qualified names like easytravel.business.webservice

22. Adding Sensor Rules – Class Browser (contd.) • Tip: Use Filter and and Grouping Options to locate classes of interest Hint: Group by Packages, Classes, Interfaces or Hierarchy Hint: Just start typing and the Class Browser will only show matching entries

23. MethodSensor Rule Class Rule Class Rule Class Rule Overview of Groups, Class and Method Rules Sensor Group

24. Class Rule Definition Match package/name space and/or class Annotation based matching definition Define whether sensor gets injected • Starts + Pattern declares a Package: All classes in this and in subordinate packages/namespaces • Equals + Pattern declares a Package: All classes in this package/namespace

25. Method Rule Definition Rule type Match Method(s) Inheritance definition Argument (or annotation) capturing Entry Point

26. Method Sensor Rules • Inheritance Types • this method – only methods matching class rule • inherited methods – subclasses of classes matching class rule • super methods – superclasses of classes matching class rule • automatic - inherited for interfaces/this method for classes • Rule Types • Include Rules – Method(s) should be instrumented • Exclude Rules – Method(s) should not be instrumented • Global Exclude Rules – Method(s) should not be instrumented even if other Senor Packs or Groups include them • Inactive Rules – Rule will be ignored

27. Placing Custom Sensor Groups • Sensor Groups work just as Sensor Packs • Need to be placed per Agent Group • Can be configured by Agent Group and System Profile Configuration • Require Hot Sensor Placement or Restart of the Application Place your Sensor Groups Indicates whether a Hot Sensor Placement is possible Define Priority of your Sensor Group compared to other Sensor Groups / Sensor Packs

28. The 4 Golden Rules of Prioritization • Exclude Rules affect only one Sensor Pack • Include Rules are always “global” • Global excludes affect all Sensor Packs • The sequence (Priority) of Sensor Packs defines • the Sensor properties applied, e.g. • active and start PurePath • argument capturing • return value capturing

29. Priority of Method Sensor Rules Priority Put important Rules on Top: Exclusions, Data for Business Transaction and Incidents

30. 3 Samples of Rule Application, 1 Sensor Packs Sensor Rules

31. 3 Samples of Rule Application, 2 Sensor Packs Sensor Rules

32. 3 Samples of Rule Application, 3 Sensor Packs Sensor Rules

33. Configuring Sensor Groups • Sensor Groups work just as Sensor Packs • Configure Sensor Groups per Agent Group and System Profile Configuration Configure Capture Options

34. Make Bulk Changes to Sensor Placement and Capture • Sensor Placement Screen – right-click on a Sensor • Sensor Configuration Screen – right-click on a Sensor

35. Hands OnSensor Groups & Priorities

36. Hands On: Custom Sensors and Priorities • Goal: Capture Context Information • Steps • Create Sensor Group “BusinessHighLevel” • Rule for BookingService.callPaymentService no argument capturing • Create Sensor Group “BusinessLowLevel” • Rule for BookingService.callPaymentService and capture first 4 arguments • Place Sensor Groups on Business Backend • Verify how Instrumentation changes by changing priorities of BusinessHighLevel and BusinessLowLevel • Always perform a Hot Sensor Placement • Look at the PurePath and see whether you are not capturing method arguments • Look at Deployed Sensors to see which Sensor Group has priority

37. Measures on Custom Sensors • Another reason for Custom Sensors is to use them for Measures • To use method arguments or return values for Business Transactions, e.g: Analyze Transactions by used Search Keyword • To use method invocation as Business Transaction Filter, e.g: Only show transactions that process a purchase order • To analyze method execution time and chart it over time, e.g.: What is the execution time into the Mainframe? • To enforce SLAs on certain Interfaces, e.g.: call to 3rd Party Library takes too long Start in PurePathorMethodsDashlet Start in PurePath or Methods Dashlet

38. Measures on Auto Sensors • Measures can also be created on Auto Sensor Nodes • Creating a Measure on an Auto Sensor node will creates a new Sensor Rule -> follow the Wizard • In other words, Sensors are required for Method Measures.

39. Adding Sensor Rules – Other Options • Add Rules through PurePath Dashlet • When you need more context from Auto Sensors -> Include Method • When you need Callee Information -> Refine with Callee Methods • When you want to exclude methods -> Exclude Method

40. Sensors – How they technically work • Every Sensor (Custom and OOTB) instruments Java/.NET Methods • Code gets added to each method that matches the Sensor Rule to • Measure Execution Time • Capture Method Arguments and Return Values • Count Method Invocations • Capture Exceptions

41. Avoid Overhead with Over-Instrumentation • DO NOT INSTRUMENT METHODS THAT • are called very often with low execution time • don‘t add contextual value to your PurePath • Automatic Sensors • will show methods that have problems without needing custom sensor rules • are more efficient than custom sensors Instrumented Application Uninstrumented Application Execution Time of Diagnosis Code

42. Sensors - Total Time & Execution Time

43. Troubleshooting • How to verify that your rule is really active • Perform Hot Sensor Placement or restart App (.NET) • Execute your transactions and analyze your PurePaths that should contain the method • Verify “Deployed Sensors” in Agents Overview • What if your method doesn‘t show in the PurePath? • Make sure you have Placed and Configured your Custom Sensor correctly • Make sure that no other Sensor Pack / Group excludes your rules • Make sure you executed a Hot Sensor Placement or restarted your Application • How can I verify if my rule is not overruled by somebody else? • Use the Agent Overview / Sensor Placement View and search for your method • If it is not there look for other Sensor Groups / Packs with global exclude rules

44. Troubleshooting – Deployed Sensors 1. Select an Agent 3. See which Sensor Group(s) have a rule for this method. First one is highest priority and defines which arguments to capture 2. Deployed Sensors

45. Hands OnCustom Sensors

46. Hands On: Custom Sensors • Goal: We want to be able to identify Login transactions in the easyTravel (cannot use URL as URL is orange.jsf which does other things than logins) • Scenario: Core Training -> Standard • Steps: • Create a Sensor on the LoginLogic.authenticate() method in the CustomerFrontend and capture the two string arguments. • You can use the Class Browser or login to easyTravel, and look for it in the orange.jsf PurePath • Perform a Hot Sensor Placement • Verify that the LoginLogic.authenticate() method is now instrumented

47. Hands On: Business Dashboard • Goal: We want an Business Dashboard that shows: • The number of easyTravel Bookings • Bookings are done through BookingService.callPaymentService (BusinessBackend) • The number of logins • Logins are done through the LoginLogic.authenticate (You already have a Sensor for this one) • The number of searches • Searches are done through SearchBean.findJourneysByLocation (CustomerFrontend) • Scenario • Core Training -> Standard • Steps • These Measures will require Sensors – either use the Class Browser to create the Sensor and then create the Measure or find the Auto Sensor data in the PurePaths and create the Measure (which will guide you through creating the Sensor)

48. Hands On: Business Dashboard

49. Hands On: Custom Sensors • Goal: We want to be able to identify Login transactions in the Administration Portal (cannot use URL as /Account/Logon URL is captured from the page load, i.e. includes just hitting page) • Scenario: Core Training -> Standard • Steps: • Create a Sensor on the AuthenticationService.AuthenticationServicePortTypeClient.authenticateTenant() method in the dotNetFrontend and capture the two string arguments. • You can use the Class Browser or login to the Admin Portal and look for it in the (correct) Account/Logon PurePath • Restart the dotNetFrontend • Verify that the method is now instrumented

50. Deep Object Access