vehicle-service config

custom-service-JONYR
qxz15oi 2021-04-22 16:01:01 +02:00
parent cb43f8684d
commit a51b7fc6ad
6 changed files with 176 additions and 0 deletions

View File

@ -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

View File

@ -0,0 +1,8 @@
config:
- CDvehicle-service: template.json
CDvehicle-service:
- name: MyProcessNamingRule
- nameFormat: "{ProcessGroup:KubernetesNamespace/regex-example}"
- tag: vehicle-service
- skipDeployment: "true"

View File

@ -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"
}

View File

@ -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/[^\\-]*$}

View File

@ -0,0 +1,8 @@
config:
- CDvehicle-service: template.json
CDvehicle-service:
- name: MyProcessNamingRule
- nameFormat: "{ProcessGroup:KubernetesNamespace/regex-example}"
- tag: vehicle-service
- skipDeployment: "true"

View File

@ -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"
}