vehicle-service config
parent
cb43f8684d
commit
a51b7fc6ad
|
|
@ -0,0 +1,67 @@
|
||||||
|
### Process Group Detection Rules and Naming
|
||||||
|
|
||||||
|
#### Detection Rule or Naming?
|
||||||
|
|
||||||
|
For the explanation, we're using a real example of the Infotainment application:
|
||||||
|
|
||||||
|
!(PGNaming1)[../../../../img/PGNaming1.PNG]
|
||||||
|
|
||||||
|
Before working with your dashboards and alerting profiles, an important task to do when working with Dynatrace is checking
|
||||||
|
the structure of your applications (process groups). You can do that clicking under *technologies* and filter using your
|
||||||
|
application Management Zone.
|
||||||
|
|
||||||
|
In the picture above, there are two Process Groups called bon-information-prod. **If you see duplicated process groups like in**
|
||||||
|
**this case, you MUST follow this guideline**
|
||||||
|
|
||||||
|
Next step would be to open both process groups and compare the metadata. In that way, you can identify if all process instances are
|
||||||
|
part of the same application or not. An easy way to do that is asking yourself: how many instances of my application do i have?
|
||||||
|
|
||||||
|
If you have 4 instances in total and you're able to see 2 in one PG and other 2 in other PG it means that **they are part of the **
|
||||||
|
**same application**
|
||||||
|
|
||||||
|
Another situation could be that checking on the metadata, then you see that are **two different application** and Dynatrace is just naming
|
||||||
|
the process group in the same way
|
||||||
|
|
||||||
|
*Same application*
|
||||||
|
- Problem: Dynatrace is creating two different process groups, what transalates in two separated services for the same application. Instead of
|
||||||
|
seeing all the traffic in one service, you will have it splitted and it will complicate your monitoring
|
||||||
|
- Solution: create a process group detection rule. Contact Dynatrace Expert
|
||||||
|
|
||||||
|
*Different application*
|
||||||
|
- Problem: Dynatrace is just naming in the same way applications that are different.
|
||||||
|
- Solution: This case is less severe, since it can be fixed with a process group naming rule.
|
||||||
|
|
||||||
|
|
||||||
|
What about our example?
|
||||||
|
!(PGNaming2)[../../../../img/PGNaming2.PNG]
|
||||||
|
!(PGNaming3)[../../../../img/PGNaming3.PNG]
|
||||||
|
|
||||||
|
Based on the feedback of the infotaiment team, each process group is a different application (microservice) and it's visible in the kubernetes container/workload
|
||||||
|
within the metadata of each Process Group.
|
||||||
|
|
||||||
|
#### How to create a Process Group Detection Rule
|
||||||
|
1. Open the *conditional-naming-processgroup.yaml* file and create a rule that looks like this:
|
||||||
|
```
|
||||||
|
config:
|
||||||
|
- CDInfotainmentRule1: template.json
|
||||||
|
|
||||||
|
CDInfotainmentRule1:
|
||||||
|
- name: Infotainment Rule 1
|
||||||
|
- nameFormat: {ProcessGroup:KubernetesNamespace} - {ProcessGroup:KubernetesContainerName}
|
||||||
|
- tag: Infotainment
|
||||||
|
- skipDeployment: false
|
||||||
|
```
|
||||||
|
The result of the rule will be renaming the PG to this:
|
||||||
|
```
|
||||||
|
bon-information-prod ipa
|
||||||
|
bon-information-prod rsl
|
||||||
|
```
|
||||||
|
|
||||||
|
Other possible placeholders that you can use are for example:
|
||||||
|
{ProcessGroup:KubernetesNamespace} - {ProcessGroup:KubernetesContainerName/[^\\-]*$}
|
||||||
|
{ProcessGroup:KubernetesNamespace} - {ProcessGroup:KubernetesFullPodName/buffet-(.*?)-}
|
||||||
|
{ProcessGroup:DetectedName} - {HostGroup:Name/[^\\_]*$}
|
||||||
|
{ProcessGroup:KubernetesNamespace}
|
||||||
|
{ProcessGroup:CommandLineArgs/.*?\\-f\\s\\/www\\/(.*?)\\/generated\\/httpd\\.conf.*?}
|
||||||
|
|
||||||
|
You can combine different ones. Check the (documentation)[link] for more
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
config:
|
||||||
|
- CDvehicle-service: template.json
|
||||||
|
|
||||||
|
CDvehicle-service:
|
||||||
|
- name: MyProcessNamingRule
|
||||||
|
- nameFormat: "{ProcessGroup:KubernetesNamespace/regex-example}"
|
||||||
|
- tag: vehicle-service
|
||||||
|
- skipDeployment: "true"
|
||||||
|
|
@ -0,0 +1,29 @@
|
||||||
|
{
|
||||||
|
"displayName": "{{.name}}",
|
||||||
|
"enabled": true,
|
||||||
|
"metadata": {
|
||||||
|
"clusterVersion": "1.214.107.20210407-223952",
|
||||||
|
"configurationVersions": [
|
||||||
|
0
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"nameFormat": "{{.nameFormat}}",
|
||||||
|
"rules": [
|
||||||
|
{
|
||||||
|
"comparisonInfo": {
|
||||||
|
"negate": false,
|
||||||
|
"operator": "EQUALS",
|
||||||
|
"type": "TAG",
|
||||||
|
"value": {
|
||||||
|
"context": "CONTEXTLESS",
|
||||||
|
"key": "Component",
|
||||||
|
"value": "{{.tag}}"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"key": {
|
||||||
|
"attribute": "PROCESS_GROUP_TAGS"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"type": "PROCESS_GROUP"
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,35 @@
|
||||||
|
### Service Naming Rules
|
||||||
|
|
||||||
|
A typical case could be that you access to *Transaction & Services* and you find two services that are exactly the same:
|
||||||
|
*DataDownloadV1*
|
||||||
|
*DataDownloadV1*
|
||||||
|
|
||||||
|
If you drilldown into the service and you check in the process group, you may have a PROD and a E2E for each service.
|
||||||
|
|
||||||
|
*Note: if you see that both process group are exactly the same, please contact a Dynatrace expert to create a Process*
|
||||||
|
*Group detection rule*
|
||||||
|
|
||||||
|
In the case the PG are PROD and E2E, then we need to create a rule that looks like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
config:
|
||||||
|
- CDInfotainmentRule1: template.json
|
||||||
|
|
||||||
|
CDInfotainmentRule1:
|
||||||
|
- name: Infotainment Rule 1
|
||||||
|
- nameFormat: {Service:DetectedName} - {ProcessGroup:KubernetesNamespace/[^-]+$}
|
||||||
|
- tag: Infotainment
|
||||||
|
- skipDeployment: false
|
||||||
|
```
|
||||||
|
|
||||||
|
The rule will get the Service Detected Name (current name) and it will extract (with a regex) the part of the kubernetes namespace after the "-", so -prod or -e2e, resulting in:
|
||||||
|
*DataDownloadV1 - prod*
|
||||||
|
*DataDownloadV1 - e2e*
|
||||||
|
|
||||||
|
Now, services will be easy to identify.
|
||||||
|
|
||||||
|
You can create rules based on any property/metadata. Some other placeholder's eamples:
|
||||||
|
{Service:DatabaseName} - E2E
|
||||||
|
{Service:WebServiceName} - {ProcessGroup:Kubernetes:microservice} - {ProcessGroup:Kubernetes:environment}
|
||||||
|
{Service:DetectedName} - {ProcessGroup:KubernetesContainerName} - {ProcessGroup:KubernetesNamespace/[^-]+$}
|
||||||
|
{Service:DetectedName} - {ProcessGroup:SpringBootProfileName/[^\\-]*$}
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
config:
|
||||||
|
- CDvehicle-service: template.json
|
||||||
|
|
||||||
|
CDvehicle-service:
|
||||||
|
- name: MyProcessNamingRule
|
||||||
|
- nameFormat: "{ProcessGroup:KubernetesNamespace/regex-example}"
|
||||||
|
- tag: vehicle-service
|
||||||
|
- skipDeployment: "true"
|
||||||
|
|
@ -0,0 +1,29 @@
|
||||||
|
{
|
||||||
|
"displayName": "{{.name}}",
|
||||||
|
"enabled": true,
|
||||||
|
"metadata": {
|
||||||
|
"clusterVersion": "1.214.107.20210407-223952",
|
||||||
|
"configurationVersions": [
|
||||||
|
0
|
||||||
|
]
|
||||||
|
},
|
||||||
|
"nameFormat": "{{.nameFormat}}",
|
||||||
|
"rules": [
|
||||||
|
{
|
||||||
|
"comparisonInfo": {
|
||||||
|
"negate": false,
|
||||||
|
"operator": "EQUALS",
|
||||||
|
"type": "TAG",
|
||||||
|
"value": {
|
||||||
|
"context": "CONTEXTLESS",
|
||||||
|
"key": "Component",
|
||||||
|
"value": "{{.tag}}"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"key": {
|
||||||
|
"attribute": "SERVICE_TAGS"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"type": "SERVICE"
|
||||||
|
}
|
||||||
Loading…
Reference in New Issue