We are using keyRequests to mark the success on a specific java method as in:
This works great but we run our VM's as Immutable Cattle, So when a NEW deployment occurs the KeyRequest is lost as it is tied to Outgoing Service entity ID. The NEW VM is now under a NEW service entity ID and will require another "Mark as Key Request" to occur before Seeing in SLO. Even adding the SplitBy bridges the timeline but not any data untill the Mark as Key Request occurs again on new entity. This requires manual toil and automation outside of the event. Would making them Metrics (with DDU impact) resolve this permanently? Are there Other ways to accomplish This?
Solved! Go to Solution.
It seems like you're facing a challenge with tracking successful key requests in Dynatrace, particularly when your VMs are deployed as Immutable Cattle and the key requests are lost after each deployment. You're currently using a filter with a `keyRequest.successes.server.rate` metric, but this metric is tied to the service entity ID and doesn't carry over when a new VM is deployed. You're considering whether converting these key requests to metrics would provide a permanent solution.
Here are a few considerations and potential solutions:
1. **Using Custom Metrics:**
Converting your key request tracking to custom metrics could be a solution, as you have control over the metric definition and how it's tracked. You could define custom metrics to track the success rate of the specific Java method. This approach might offer more flexibility in tracking success across deployments, as long as you ensure that the custom metric definitions persist across deployments.
2. **Metric Separation:**
When transitioning from key requests to custom metrics, make sure to carefully plan the metric names, dimensions, and definitions. You might need to update your monitoring configuration and any alerting or reporting mechanisms that rely on these metrics.
3. **Custom Events:**
Instead of relying solely on metrics, you could consider creating custom events that indicate the success of your specific Java method. Custom events can provide contextual information and might be easier to track across deployments.
4. **Automation Integration:**
If you're already using automation for your deployments, you might be able to integrate an automated step that triggers the "Mark as Key Request" action after a deployment. This way, the necessary key requests are automatically triggered after each deployment.
5. **Communication Between Deployments:**
Ensure that your deployment automation communicates with your monitoring system when a new deployment occurs. This communication could trigger actions such as marking key requests or updating custom metrics. This way, the monitoring system is aware of deployments and can adjust its tracking accordingly.
6. **Consulting Dynatrace Support:**
Since Dynatrace provides support for complex monitoring scenarios, it's a good idea to reach out to Dynatrace support to discuss your specific use case and get recommendations tailored to your environment.
Ultimately, the solution you choose should align with your monitoring and operational requirements. Converting key requests to custom metrics might provide more control and resilience across deployments, but you'll need to carefully plan and implement this transition to ensure accurate monitoring and reporting.
If the Service Name/Request name is known, you can create a calculated metric from Multidimensional Analysis (https://www.dynatrace.com/support/help/platform-modules/applications-and-microservices/multidimensio...) using them as filter, and selecting the metric Successful request count, you should be able to get similar data.