Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pod info is missing in data generated by mixer when pod name contains '.' #20028

zhranklin opened this issue Jan 9, 2020 · 2 comments


Copy link

@zhranklin zhranklin commented Jan 9, 2020

Bug description
When two pods with '.' in their names are injected sidecars and then make http request from one to another, the generated mixer data is missing some fields which depends on pod info, which includes:

  • source/destination.labels
  • source/
  • source/destination.owner
  • source/destination.workload
  • destination.namespace (parsed as default but it's wrong)

When making a request from a.deploy.powerful-mix to b.deploy.powerful-mix, we can't get information of this request from prometheus or kiali, and the access log on istio-telemetry is:

2020-01-09T11:53:40.645249Z     info    accesslog.instance.istio-system {"apiClaims": "", "apiKey": "", "clientTraceId": "", "connection_security_policy": "unknown", "destinationApp": "", "destinationIp": "", "destinationName": "unknown", "destinationNamespace": "default", "destinationOwner": "unknown", "destinationPrincipal": "", "destinationServiceHost": "b.powerful-mix.svc.cluster.local", "destinationWorkload": "unknown", "grpcMessage": "", "grpcStatus": "", "httpAuthority": "b", "latency": "7.100119ms", "method": "POST", "permissiveResponseCode": "none", "permissiveResponsePolicyID": "none", "protocol": "http", "receivedBytes": 712, "referer": "", "reporter": "source", "requestId": "938fb7c0-5c3f-4958-8371-0030cc00d7da", "requestSize": 233, "requestedServerName": "", "responseCode": 200, "responseFlags": "-", "responseSize": 10, "responseTimestamp": "2020-01-09T11:53:40.652286Z", "sentBytes": 146, "sourceApp": "", "sourceIp": "", "sourceName": "unknown", "sourceNamespace": "deploy-686ff98446-5xdvj", "sourceOwner": "unknown", "sourcePrincipal": "", "sourceWorkload": "unknown", "url": "/execute", "userAgent": "Java/1.8.0_222", "xForwardedFor": ""}

The json is formatted as:

  "apiClaims": "",
  "apiKey": "",
  "clientTraceId": "",
  "connection_security_policy": "unknown",
  "destinationApp": "",
  "destinationIp": "",
  "destinationName": "unknown",
  "destinationNamespace": "default",
  "destinationOwner": "unknown",
  "destinationPrincipal": "",
  "destinationServiceHost": "b.powerful-mix.svc.cluster.local",
  "destinationWorkload": "unknown",
  "grpcMessage": "",
  "grpcStatus": "",
  "httpAuthority": "b",
  "latency": "7.100119ms",
  "method": "POST",
  "permissiveResponseCode": "none",
  "permissiveResponsePolicyID": "none",
  "protocol": "http",
  "receivedBytes": 712,
  "referer": "",
  "reporter": "source",
  "requestId": "938fb7c0-5c3f-4958-8371-0030cc00d7da",
  "requestSize": 233,
  "requestedServerName": "",
  "responseCode": 200,
  "responseFlags": "-",
  "responseSize": 10,
  "responseTimestamp": "2020-01-09T11:53:40.652286Z",
  "sentBytes": 146,
  "sourceApp": "",
  "sourceIp": "",
  "sourceName": "unknown",
  "sourceNamespace": "deploy-686ff98446-5xdvj",
  "sourceOwner": "unknown",
  "sourcePrincipal": "",
  "sourceWorkload": "unknown",
  "url": "/execute",
  "userAgent": "Java/1.8.0_222",
  "xForwardedFor": ""

As we know, the default logentry config shows mappings of the fields:

      sourceApp: source.labels["{{ }}"] | ""
      sourceName: | ""
      sourceWorkload: | ""
      sourceOwner: source.owner | ""
      destinationApp: destination.labels["{{ }}"] | ""
      destinationWorkload: | ""
      destinationName: | ""
      destinationNamespace: destination.namespace | ""
      destinationOwner: destination.owner | ""

So we can infer the above attributes are missing or incorrectly parsed.

Expected behavior
The mixer access log should show the right information of source workload and destination workload.

And we should be able to see this request on kiali and prometheus.

Steps to reproduce the bug

  • create 2 deployments named a.deploy and b.deploy
  • make a request from a.deploy-xxx-xxx to b.deploy-xxx-xxx
  • see access log on mixer and the result in kiali and prometheus

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)


How was Istio installed?

installed with config for mixer:

    enabled: true
      enabled: true
      outputAsJson: false

Environment where bug was observed (cloud vendor, OS, etc)


This comment has been minimized.

Copy link
Member Author

@zhranklin zhranklin commented Jan 9, 2020

I have fixed this bug in our production env, and try to make a PR: #20026


This comment has been minimized.

Copy link

@jwendell jwendell commented Feb 10, 2020

Fixed by #20026

@jwendell jwendell closed this Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.