yes, this is a great usage of the properties -Dappdynamics.agent.reuse.nodeName=true -Dappdynamics.agent.reuse.nodeName.prefix=${HOSTNAME}, because they'll ensure a continuity of metric reporting for a node when the pod changes.
1. No I don't see any downside for this solution, it's a very good one
2. In theory, we'd recommend naming tiers based on the business purpose / service they fulfil.
For example in this picture, a Checkout business transaction:
- Is being handled at the start by the tier "Ecommerce-services" (which has 40 nodes) which aim is to be the first level of the request processing and to commit the transaction in the database
- Then the Inventory Services tier (with 4 nodes), which aim is to check the availability of the item, update the counter accordingly, etc, is called in order to make an API call to the main supplier
- Then the order is put in a queue that is processed by the "Order Processing Services" tier which aim is to process orders being placed, and that makes a call to another remote service.
Splitting the tiers by region, even though they have common business purposes across these regions, would lead to different business transactions for "Checkout" for example, each originating from a regional tier, for example:
. A Checkout transaction (with its own metrics and snapshots) originating from "us-east-1"
. Another Checkout transaction (with its own metrics and snapshots) originating from eu-west-1
etc.
The downsides are that:
1. You wouldn't be able to aggregate automatically the metrics of the business transaction and the tiers across the different regions.
2. This could increase very easily the number of business transactions close to the default limit of 200, which is not recommended.
Here are the best practices around an application organisation in AppDynamics (application name, tiers names, nodes names, etc):
https://docs.appdynamics.com/appd/24.x/latest/en/application-monitoring/overview-of-application-moni...
Here is a great article on how to define business transactions (which is very related to the choice of tiers organisation):
Happy to discuss further over a call!
Thank you @Paula.Semaan for the response.
After some more digging, we went with -Dappdynamics.agent.reuse.nodeName=true -Dappdynamics.agent.reuse.nodeName.prefix=${HOSTNAME}
So, this way we could dynamically register new pods/instances/replicas coming in our Kubernetes cluster and this node would be registered in the AppD console as the pod name as shown below.
So this handled upscaling/downscaling and updating in the console.
1. Do you see any downsides in this as we only wanted to use the Java agent?
2. We have a multi-region deployment of our applications, can you suggest any better organization structure for our apps and nodes in this case? We were thinking of using AppName -> Tier as region ( us-east-1 is one tier, eu-west-1 is another tier, etc ) -> Nodes as Kubernetes pods under that tier/region.
Thank you
yes, this is a great usage of the properties -Dappdynamics.agent.reuse.nodeName=true -Dappdynamics.agent.reuse.nodeName.prefix=${HOSTNAME}, because they'll ensure a continuity of metric reporting for a node when the pod changes.
1. No I don't see any downside for this solution, it's a very good one
2. In theory, we'd recommend naming tiers based on the business purpose / service they fulfil.
For example in this picture, a Checkout business transaction:
- Is being handled at the start by the tier "Ecommerce-services" (which has 40 nodes) which aim is to be the first level of the request processing and to commit the transaction in the database
- Then the Inventory Services tier (with 4 nodes), which aim is to check the availability of the item, update the counter accordingly, etc, is called in order to make an API call to the main supplier
- Then the order is put in a queue that is processed by the "Order Processing Services" tier which aim is to process orders being placed, and that makes a call to another remote service.
Splitting the tiers by region, even though they have common business purposes across these regions, would lead to different business transactions for "Checkout" for example, each originating from a regional tier, for example:
. A Checkout transaction (with its own metrics and snapshots) originating from "us-east-1"
. Another Checkout transaction (with its own metrics and snapshots) originating from eu-west-1
etc.
The downsides are that:
1. You wouldn't be able to aggregate automatically the metrics of the business transaction and the tiers across the different regions.
2. This could increase very easily the number of business transactions close to the default limit of 200, which is not recommended.
Here are the best practices around an application organisation in AppDynamics (application name, tiers names, nodes names, etc):
https://docs.appdynamics.com/appd/24.x/latest/en/application-monitoring/overview-of-application-moni...
Here is a great article on how to define business transactions (which is very related to the choice of tiers organisation):
Happy to discuss further over a call!
