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