• Forums
    • Public Forums
      • Community Connect
      • Dynatrace
        • Dynatrace Open Q&A
      • Application Monitoring & UEM
        • AppMon & UEM Open Q&A
      • Network Application Monitoring
        • NAM Open Q&A
  • Home /
  • Public Forums /
  • Application Monitoring & UEM /
  • AppMon & UEM Open Q&A /
avatar image
Question by J P. · Jul 21, 2015 at 12:03 AM · production

Monitoring Long-Running Processes

We have an application that has several threads that poll queues for processing. Just looking at the pure paths for the application gives very little insight in to what the application is actually doing, since all the pure paths are simply just adding objects to the queues, while most of the heavy processing is done asynchronously. 

What would be the recommended way to get visibility into the application in this case? Adding several of the services the processing threads have as APIs still doesn't seem to result in anything showing up as far as time spent interacting with those APIs. In fact, nothing seems to show up there at all. 

Comment

People who like this

0 Show 0
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

1 Reply

  • Sort: 
  • Most voted
  • Newest
  • Oldest
avatar image

Answer by Graeme W. · Jul 21, 2015 at 02:13 AM

JP,

It sounds like you have two separate problems.  The first problem is that you're not seeing the activity in your background threads, and the second problem is how to correlate the activity in the foreground and background threads.

You'll need to solve the first problem first.  You didn't say whether you were running in test or production, and the right path depends a bit on which it is.  In either case, you can take a CPU dump to see which methods are being called regularly.  This will give better results the more traffic you can run through the background threads.  In test, you might consider putting method sensors on entire packages – just to see what you can see – but in general you can't do that inn production.

When you're adding method sensors to catch the background processing, remember to set them to "active and start PurePaths" in the method sensor configuration.

If the background threads are making any database calls, you could set the JDBC / ADO .NET sensor to "active and start PurePaths" as well, just to verify that you can see something in the background threads.

Once you have visibility into both foreground and background threads, the way to correlate them is to construct a PurePath business transaction that splits on some transaction identifier that is shared between foreground and background activity.

-- Graeme

Comment

People who like this

0 Show 0 · Share
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

How to get started

First steps in the forum
Read Community User Guide
Best practices of using forum

NAM 2019 SP5 is available


Check the RHEL support added in the latest NAM service pack.

Learn more

LIVE WEBINAR

"Performance Clinic - Monitoring as a Self Service with Dynatrace"


JANUARY 15, 3:00 PM GMT / 10:00 AM ET

Register here

Follow this Question

Answers Answers and Comments

1 Person is following this question.

avatar image

Related Questions

Security bbest practices when deploying DT with UEM

Using the URL monitor with a login form

Notification for unchanged measure value

Monitoring SQL Cluster

Licensing model

Forum Tags

dotnet mobile monitoring load iis 6.5 kubernetes mainframe rest api dashboard framework 7.0 appmon 7 health monitoring adk log monitoring services auto-detection uem webserver test automation license web performance monitoring ios nam probe collector migration mq web services knowledge sharing reports window java hybris javascript appmon sensors good to know extensions search 6.3+ server documentation easytravel web dashboard kibana system profile purelytics docker splunk 6.1 process groups account 7.2 rest dynatrace saas spa guardian appmon administration production user actions postgresql upgrade oneagent measures security Dynatrace Managed transactionflow technologies diagnostics user session monitoring unique users continuous delivery sharing configuration alerting NGINX splitting business transaction client 6.3 installation database scheduler apache mobileapp RUM php dashlet azure purepath agent 7.1 appmonsaas messagebroker nodejs 6.2 android sensor performance warehouse
  • Forums
  • Public Forums
    • Community Connect
    • Dynatrace
      • Dynatrace Open Q&A
    • Application Monitoring & UEM
      • AppMon & UEM Open Q&A
    • Network Application Monitoring
      • NAM Open Q&A