newrelic / nr1-nimbus

NR1 Nimbus allows you to migrate workloads to the cloud, or across different cloud environments
https://discuss.newrelic.com/t/new-relic-one-nimbus/116523
Apache License 2.0
2 stars 5 forks source link

Extend "Complexity Profiling" feature to include APM apps #22

Closed iamfuzz closed 4 years ago

iamfuzz commented 4 years ago

Summary

Currently, the Complexity Profiling feature only works with fully instrumented web apps: Browser, APM, and Infra. For these apps, it is quite useful as the user can create a workload of the app and its underlying hosts with the click of a button, never having to leave the Nimbus UI.

Please extend this functionality to applications only instrumented with APM + Infra.

Desired Behaviour

The Complexity Profiling page will show a listing of all APM applications that also have infrastructure agents installed on their underlying hosts.

Possible Solution

Adjust the default algorithm to exclude Browser dependencies or allow for the configuration of the algorithm so that the user can choose to exclude them.

Additional context

This feature would allow APM users to be able to create workloads without ever having to leave the Nimbus UI.

ricegi commented 4 years ago

I've been able to create workloads from the complexity profiler with just APM and Infra dependencies. The feature also includes associated synthetics, mobile, and browser entities when available but isn't a strict dependency.

Please provide more details, screenshots, or a reference example in an accessible environment.

iamfuzz commented 4 years ago

Hi Gil,

I deployed 5 sample apps to the demobot account, and only those instrumented with Browser appear under Complexity Profiling:

image

image

image

Based on your comments, I deployed the latest Nimbus to Demotron_CAS, and indeed, it doesn't appear Browser is the common denominator, but some applications still aren't present ("Box" being one example):

image

image

Since Kav based the simple complexity algorithm on this: https://github.com/iamfuzz/app-complexity-assessement/blob/master/README.md I dug a little further to see if it was perhaps apps lacking database transactions that were being excluded, but that doesn't appear to be it either. I'm now not sure why some applications are present and others are not.

iamfuzz commented 4 years ago

Digging a bit further, the app GUIDs appear to be retrieved with the following graphql query:

{ actor { account(id: 2246998) { nrql(query: "from Relationship select uniques(sourceEntityGuid) where sourceEntityType='APPLICATION'") { results } } } }

For some reason, that query does not return all applications.

ricegi commented 4 years ago

might have something to do with those apps not having throughput in the period where the request is being made. It might make more sense to look at how the relationship service is expressed in graphql rather than nrql when creating those dependencies.

the nrql is a simpler approach would require the recursion multiple entity lookups and subsequent relationship lookups. But will probably be more robust and complete.

iamfuzz commented 4 years ago

Good idea, this appears to be the way to do it:

{
  actor {
    entitySearch(query: "type IN ('APPLICATION')") {
      results {
        entities {
          guid
        }
        nextCursor
      }
    }
  }
}

This has the added benefit of being cross-account as well but will require some pagination work and filtering (this will return two entries for the same app if the app is instrumented with both APM and Browser)

ricegi commented 4 years ago

Yes that is a piece of a graph query.

Switching the mechanism has broader implications for how the component is built. I am going to close this issue and park this pending a larger design review.