Access log with JSON encoding #12232

njyeti · 2019-03-04T18:59:17Z

Istio: 1.1.0-rc.2
K8s: v1.11.5-gke.5

I'm currently seeing two issues while using the JSON encoding for the access log but works fine with the TEXT

Method has the incorrect value i.e. %REQ(:METHOD)% ("method": "2019-03-04T18:50:40.527Z" in the below JSON output)
My custom header values are getting omitted from the JSON but works fine with TEXT encoding

Text encoding:
'2019-03-04T18:48:42.884Z' 'foo' 'GET' /prod/v1 HTTP/1.1 200 - 0 3173 3 2 10.138.0.20 'curl/7.54.0' b1dc5045-0975-46f5-b217-5fa1eb3876af website.com 10.52.4.52:80 outbound|80|version-2|website-path.path.svc.cluster.local - 10.52.1.77:80 10.138.0.20:53461

JSON encoding:
{ "upstream_cluster": "outbound|80|version-1|website-path.path.svc.cluster.local", "downstream_remote_address": "10.138.0.17:43587", "path": "\/prod\/v1", "authority": "website.com", "protocol": "HTTP\/1.1", "upstream_service_time": "2", "upstream_local_address": "-", "duration": "3", "downstream_local_address": "10.52.3.56:80", "response_code": "200", "user_agent": "curl\/7.54.0", "response_flags": "-", "start_time": "2019-03-04T18:50:40.527Z", "method": "2019-03-04T18:50:40.527Z", "request_id": "bf57fa95-3a15-4078-9353-ad5a74e2ce5e", "upstream_host": "10.52.2.15:80", "x_forwarded_for": "10.138.0.17", "requested_server_name": "-", "bytes_received": "0", "istio_policy_status": "-", "bytes_sent": "3176" }

istio-configmap-1.1.0-rc.2.yaml

apiVersion: v1
kind: ConfigMap
metadata:
name: istio
namespace: istio-system
labels:
app: istio
chart: istio-1.1.0
heritage: Tiller
release: istio
data:
mesh: |-
# Set the following variable to true to disable policy checks by the Mixer.
# Note that metrics will still be reported to the Mixer.
disablePolicyChecks: true

# Set enableTracing to false to disable request tracing.
enableTracing: true

# Set accessLogFile to empty string to disable access log.
accessLogFile: "/dev/stdout"

# If accessLogEncoding is TEXT, value will be used directly as the log format
# example: "[%START_TIME%] %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\n"
# If AccessLogEncoding is JSON, value will be parsed as map[string]string
# example: '{"start_time": "%START_TIME%", "req_method": "%REQ(:METHOD)%"}'
# Leave empty to use default log format
accessLogFormat: "'%START_TIME%' '%REQ(MY-CUSTOM-REQ-NAME)%'  '%RESP(MY-CUSTOM-RESP-NAME)%' '%REQ(:METHOD)%' %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL% %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% %REQ(X-FORWARDED-FOR)% '%REQ(USER-AGENT)%' %REQ(X-REQUEST-ID)% %REQ(:AUTHORITY)% %UPSTREAM_HOST% %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% \n"

# Set accessLogEncoding to JSON or TEXT to configure sidecar access log
accessLogEncoding: 'JSON'
mixerReportServer: istio-telemetry.istio-system.svc.cluster.local:9091
# Let Pilot give ingresses the public IP of the Istio ingressgateway
ingressService: istio-ingressgateway

... ... ...

The text was updated successfully, but these errors were encountered:

GregHanson · 2019-03-04T21:35:28Z

@njyeti can you grab the format string from envoy in the TEXT case?

kubectl exec -it <app_pod_name> -c istio-proxy -- curl locahost:15000/config_dump | grep format

njyeti · 2019-03-04T21:55:06Z

Here you go.

Encoding: TEXT
"access_log": [ { "name": "envoy.file_access_log", "typed_config": { "@type": "type.googleapis.com/envoy.config.accesslog.v2.FileAccessLog", "path": "/dev/stdout", "format": "'%START_TIME%' '%REQ(MY-CUSTOM-REQ-NAME)%' '%RESP(MY-CUSTOM-RESP-NAME)%' '%REQ(:METHOD)%' %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL% %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% %REQ(X-FORWARDED-FOR)% '%REQ(USER-AGENT)%' %REQ(X-REQUEST-ID)% %REQ(:AUTHORITY)% %UPSTREAM_HOST% %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% \n" } } ]

Encoding: JSON
"access_log": [ { "name": "envoy.file_access_log", "typed_config": { "@type": "type.googleapis.com/envoy.config.accesslog.v2.FileAccessLog", "path": "/dev/stdout", "json_format": { "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%", "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%", "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%", "requested_server_name": "%REQUESTED_SERVER_NAME%", "start_time": "%START_TIME%", "method": "%START_TIME%", "upstream_cluster": "%UPSTREAM_CLUSTER%", "istio_policy_status": "%DYNAMIC_METADATA(istio.mixer:status)%", "protocol": "%PROTOCOL%", "duration": "%DURATION%", "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%", "upstream_host": "%UPSTREAM_HOST%", "bytes_received": "%BYTES_RECEIVED%", "bytes_sent": "%BYTES_SENT%", "response_flags": "%RESPONSE_FLAGS%", "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%", "user_agent": "%REQ(USER-AGENT)%", "request_id": "%REQ(X-REQUEST-ID)%", "authority": "%REQ(:AUTHORITY)%", "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%", "response_code": "%RESPONSE_CODE%" } } } ]

dwradcliffe · 2019-03-13T20:47:59Z

This is still present in rc4. I put up a PR to fix the first part here: #12473

(I'm not actually sure what the second problem is referring to)

njyeti · 2019-03-13T21:27:01Z

Hi @dwradcliffe,

Regarding the 2nd problem, if we want to capture the HTTP request or response header in the access log, currently, it is does not capture custom value the JSON format but works fine when we use the TEXT format.

For example, if we have the below access log pattern where we have defined custom header for request and response:
accessLogFormat: "'%START_TIME%' '%REQ(MY-CUSTOM-REQ-NAME)%' '%RESP(MY-CUSTOM-RESP-NAME)%' \n"
TEXT encoding will output:
'2019-03-04T18:48:42.884Z' 'foo' 'bar'

But, JSON encoding will output only:
{"start_time": "2019-03-04T18:50:40.527Z"}

whereas Envoy supports customer header as mentioned https://www.envoyproxy.io/docs/envoy/latest/configuration/access_log#format-dictionaries

dwradcliffe · 2019-03-13T21:49:27Z

What's your custom accessLogFormat for JSON?

njyeti · 2019-03-13T22:58:02Z

hmmm, is it the same format being used for both TEXT and JSON?

Snippet from the 'istio" configMap
# If accessLogEncoding is TEXT, value will be used directly as the log format # example: "[%START_TIME%] %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\n" # If AccessLogEncoding is JSON, value will be parsed as map[string]string # example: '{"start_time": "%START_TIME%", "req_method": "%REQ(:METHOD)%"}' # Leave empty to use default log format accessLogFormat: "'%START_TIME%' '%REQ(MY-CUSTOM-REQ-NAME)%' '%RESP(MY-CUSTOM-RESP-NAME)%' \n" ... ... ...

dwradcliffe · 2019-03-13T23:04:16Z

If you want to use custom vars and JSON you need to put the mapping in accessLogFormat in json, not the same string you used for text. I’m guessing it failed to decide json and failed back to the default format.

njyeti · 2019-03-13T23:15:42Z

got it. Will try it out quickly. Thank you!!

GregHanson · 2019-03-25T13:57:37Z

bug fix for the timestamp merged - marking as closed unless further issues detected

my3sons · 2019-11-13T22:34:36Z

Hello @njyeti,
How did you ultimately end up resolving this. I am facing same issue where my custom accessLogFormat only works with TEXT, but is ignored with JSON. Did you end up creating a accessLogFormat with a Json value and updating the configmap accordingly?

njyeti · 2019-11-14T01:13:20Z

@my3sons,
We updated the Istio ConfigMap with below values:

accessLogEncoding: 'JSON'
accessLogFile: "/dev/stdout"
accessLogFormat: '{"start_time": "%START_TIME%","req_method": "%REQ(:METHOD)%","x_envoy_original_path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","protocol": "%PROTOCOL%","response_code": "%RESPONSE_CODE%","response_flags": "%RESPONSE_FLAGS%","bytes_received": "%BYTES_RECEIVED%","bytes_send": "%BYTES_SENT%","duration": "%DURATION%","resp_x_envoy_upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","x_forwarded_for": "%REQ(X-FORWARDED-FOR)%","user_agent": "%REQ(USER-AGENT)%","x_request_id": "%REQ(X-REQUEST-ID)%","authority": "%REQ(:AUTHORITY)%","upstream_host": "%UPSTREAM_HOST%","upstream_cluster": "%UPSTREAM_CLUSTER%","upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%","downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%","downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%","resp_x_foo_fault_flag": "%RESP(X-FOO-FAULT-FLAG)%"}'

If I remembered correctly there Is a way to update these using helm install as well but didn't remember the cmd and args top of my head

my3sons · 2019-11-14T13:02:21Z

@njyeti,
Yea, I was initially trying to update the accessLogFormat using helm, but it would not stick when trying to set the value as json. We'll just do the same and update the configmap directly as you did with our custom format.
Thanks!

haf · 2020-02-19T07:32:12Z

@dwradcliffe Quick question: how come Istio decided to use string interpolation (which doesn't properly escape values) when constructing the JSON value? Isn't that obviously bugged?

pantelis-karamolegkos · 2021-01-26T23:44:52Z

I am having the exact same issue.

Using the following in istio-operator

 accessLogFile: "/dev/stdout"
 accessLogEncoding: "JSON"
 accessLogFormat: "{'x_request_id': '%REQ(X-REQUEST-ID)%'}"

has no effect at all....It keeps printing the default log...

Any suggestions?

boeboe · 2021-03-16T17:40:12Z

When the accessLogEncoding is set to JSON, accessLogFormat is not used (whether that is a bug or by design, I cannot say). This makes sense, as if you want to overrule elements in the accessLogFormat and are expecting JSON, you have to write a JSON alike template anyway.

This is what worked for me

global:
  proxy:
    accessLogEncoding: TEXT
    accessLogFile: /dev/stdout
    accessLogFormat: "{ \"authority\": \"%REQ(:AUTHORITY)%\", \"bytes_received\": %BYTES_RECEIVED%, \"bytes_sent\": %BYTES_SENT%, \"downstream_local_address\": \"%DOWNSTREAM_LOCAL_ADDRESS%\", \"downstream_peer_cert_v_end\": \"%DOWNSTREAM_PEER_CERT_V_END%\", \"downstream_peer_cert_v_start\": \"%DOWNSTREAM_PEER_CERT_V_START%\", \"downstream_remote_address\": \"%DOWNSTREAM_REMOTE_ADDRESS%\", \"downstream_tls_cipher\": \"%DOWNSTREAM_TLS_CIPHER%\", \"downstream_tls_version\": \"%DOWNSTREAM_TLS_VERSION%\", \"duration\": %DURATION%, \"hostname\": \"%HOSTNAME%\", \"istio_policy_status\": \"%DYNAMIC_METADATA(istio.mixer:status)%\", \"method\": \"%REQ(:METHOD)%\", \"path\": \"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%\", \"protocol\": \"%PROTOCOL%\", \"request_duration\": %REQUEST_DURATION%, \"request_id\": \"%REQ(X-REQUEST-ID)%\", \"requested_server_name\": \"%REQUESTED_SERVER_NAME%\", \"response_code\": \"%RESPONSE_CODE%\", \"response_duration\": %RESPONSE_DURATION%, \"response_tx_duration\": %RESPONSE_TX_DURATION%, \"response_flags\": \"%RESPONSE_FLAGS%\", \"route_name\": \"%ROUTE_NAME%\", \"start_time\": \"%START_TIME%\", \"upstream_cluster\": \"%UPSTREAM_CLUSTER%\", \"upstream_host\": \"%UPSTREAM_HOST%\", \"upstream_local_address\": \"%UPSTREAM_LOCAL_ADDRESS%\", \"upstream_service_time\": %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%, \"upstream_transport_failure_reason\": \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\", \"user_agent\": \"%REQ(USER-AGENT)%\", \"x_forwarded_for\": \"%REQ(X-FORWARDED-FOR)%\" } \n"

This did not work for me

global:
  proxy:
    accessLogEncoding: JSON
    accessLogFile: /dev/stdout
    accessLogFormat: "{ \"authority\": \"%REQ(:AUTHORITY)%\", \"bytes_received\": %BYTES_RECEIVED%, \"bytes_sent\": %BYTES_SENT%, \"downstream_local_address\": \"%DOWNSTREAM_LOCAL_ADDRESS%\", \"downstream_peer_cert_v_end\": \"%DOWNSTREAM_PEER_CERT_V_END%\", \"downstream_peer_cert_v_start\": \"%DOWNSTREAM_PEER_CERT_V_START%\", \"downstream_remote_address\": \"%DOWNSTREAM_REMOTE_ADDRESS%\", \"downstream_tls_cipher\": \"%DOWNSTREAM_TLS_CIPHER%\", \"downstream_tls_version\": \"%DOWNSTREAM_TLS_VERSION%\", \"duration\": %DURATION%, \"hostname\": \"%HOSTNAME%\", \"istio_policy_status\": \"%DYNAMIC_METADATA(istio.mixer:status)%\", \"method\": \"%REQ(:METHOD)%\", \"path\": \"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%\", \"protocol\": \"%PROTOCOL%\", \"request_duration\": %REQUEST_DURATION%, \"request_id\": \"%REQ(X-REQUEST-ID)%\", \"requested_server_name\": \"%REQUESTED_SERVER_NAME%\", \"response_code\": \"%RESPONSE_CODE%\", \"response_duration\": %RESPONSE_DURATION%, \"response_tx_duration\": %RESPONSE_TX_DURATION%, \"response_flags\": \"%RESPONSE_FLAGS%\", \"route_name\": \"%ROUTE_NAME%\", \"start_time\": \"%START_TIME%\", \"upstream_cluster\": \"%UPSTREAM_CLUSTER%\", \"upstream_host\": \"%UPSTREAM_HOST%\", \"upstream_local_address\": \"%UPSTREAM_LOCAL_ADDRESS%\", \"upstream_service_time\": %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%, \"upstream_transport_failure_reason\": \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\", \"user_agent\": \"%REQ(USER-AGENT)%\", \"x_forwarded_for\": \"%REQ(X-FORWARDED-FOR)%\" } \n"

And also the following did not work

global:
  proxy:
    accessLogEncoding: JSON
    accessLogFormat: |
      {
        "authority": "%REQ(:AUTHORITY)%",
        "bytes_received": %BYTES_RECEIVED%,
        "bytes_sent": %BYTES_SENT%,
        "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
        "downstream_peer_cert_v_end": "%DOWNSTREAM_PEER_CERT_V_END%",
        "downstream_peer_cert_v_start": "%DOWNSTREAM_PEER_CERT_V_START%",
        "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
        "downstream_tls_cipher": "%DOWNSTREAM_TLS_CIPHER%",
        "downstream_tls_version": "%DOWNSTREAM_TLS_VERSION%",
        "duration": %DURATION%,
        "hostname": "%HOSTNAME%",
        "istio_policy_status": "%DYNAMIC_METADATA(istio.mixer:status)%",
        "method": "%REQ(:METHOD)%",
        "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
        "protocol": "%PROTOCOL%",
        "request_duration": %REQUEST_DURATION%,
        "request_id": "%REQ(X-REQUEST-ID)%",
        "requested_server_name": "%REQUESTED_SERVER_NAME%",
        "response_code": "%RESPONSE_CODE%",
        "response_duration": %RESPONSE_DURATION%,
        "response_tx_duration": %RESPONSE_TX_DURATION%,
        "response_flags": "%RESPONSE_FLAGS%",
        "route_name": "%ROUTE_NAME%",
        "start_time": "%START_TIME%",
        "upstream_cluster": "%UPSTREAM_CLUSTER%",
        "upstream_host": "%UPSTREAM_HOST%",
        "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
        "upstream_service_time": %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%,
        "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%",
        "user_agent": "%REQ(USER-AGENT)%",
        "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%"
      }

Bottom line, if you want to modify the fields (add/modify/remove), you just fall back on accessLogFormat TEXT, where you have full control anyway. The accessLogEncoding JSON seems a shortcut feature to quickly switch from TEXT to JSON, but do not use it when tweaking is needed.

Note: this way my JSON fields are ordered in alphabetical order, which I like more.

quant-daddy · 2021-04-12T19:24:41Z

This worked for me:

  meshConfig:
    accessLogFormat: |
      {
        "authority": "%REQ(:AUTHORITY)%",
        "bytes_received": "%BYTES_RECEIVED%",
        "bytes_sent": "%BYTES_SENT%",
        "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
        "downstream_peer_cert_v_end": "%DOWNSTREAM_PEER_CERT_V_END%",
        "downstream_peer_cert_v_start": "%DOWNSTREAM_PEER_CERT_V_START%",
        "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
        "downstream_tls_cipher": "%DOWNSTREAM_TLS_CIPHER%",
        "downstream_tls_version": "%DOWNSTREAM_TLS_VERSION%",
        "duration": "%DURATION%",
        "hostname": "%HOSTNAME%",
        "istio_policy_status": "%DYNAMIC_METADATA(istio.mixer:status)%",
        "method": "%REQ(:METHOD)%",
        "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
        "protocol": "%PROTOCOL%",
        "request_duration": "%REQUEST_DURATION%",
        "request_id": "%REQ(X-REQUEST-ID)%",
        "requested_server_name": "%REQUESTED_SERVER_NAME%",
        "response_code": "%RESPONSE_CODE%",
        "response_duration": "%RESPONSE_DURATION%",
        "response_tx_duration": "%RESPONSE_TX_DURATION%",
        "response_flags": "%RESPONSE_FLAGS%",
        "route_name": "%ROUTE_NAME%",
        "start_time": "%START_TIME%",
        "upstream_cluster": "%UPSTREAM_CLUSTER%",
        "upstream_host": "%UPSTREAM_HOST%",
        "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
        "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
        "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%",
        "user_agent": "%REQ(USER-AGENT)%",
        "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%",
        "x_graphql_operation": "%REQ(X-GRAPHQL-OPERATION)%",
        "x_graphql_operation_name": "%REQ(X-GRAPHQL-OPERATION-NAME)%",
        "x_graphql_response_status": "%RESP(X-GRAPHQL-RESPONSE-STATUS)%",
        "x_graphql_root_operation": "%REQ(X-PROP-GRAPHQL-OPERATION)%",
        "x_graphql_root_operation_name": "%REQ(X-PROP-GRAPHQL-OPERATION-NAME)%"
      }
    accessLogEncoding: "JSON"
    accessLogFile: "/dev/stdout"

hustshawn · 2021-06-01T08:37:40Z

Since this issue not solved officially, I suppose this ticket should be re-open. @GregHanson

verified not working on Istio 1.7.4.

sonnyhcl · 2021-08-24T15:05:04Z

Hi guys, is there any way to define JSON ordering for access log in JSON format?

Note: this way my JSON fields are ordered in alphabetical order, which I like more.

@boeboe What do you mean "ordered" in this message?

sonnyhcl · 2021-08-24T15:06:31Z

BTW below config works for me, which is istio 1.8.1

  meshConfig:
    # Istio access log leveraging Envoy
    # https://istio.io/latest/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging
    # https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#access-logging
    accessLogFile: /dev/stdout
    accessLogEncoding: "JSON"
    accessLogFormat: '{
      "authority": "%REQ(:AUTHORITY)%",
      "bytes_received": "%BYTES_RECEIVED%",
      "bytes_sent": "%BYTES_SENT%",
      "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%",
      "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
      "duration": "%DURATION%",
      "method": "%REQ(:METHOD)%",
      "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
      "protocol": "%PROTOCOL%",
      "requested_server_name": "%REQUESTED_SERVER_NAME%",
      "response_code": "%RESPONSE_CODE%",
      "response_flags": "%RESPONSE_FLAGS%",
      "route_name": "%ROUTE_NAME%",
      "start_time": "%START_TIME%",
      "upstream_cluster": "%UPSTREAM_CLUSTER%",
      "upstream_host": "%UPSTREAM_HOST%",
      "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%",
      "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
      "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%",
      "user_agent": "%REQ(USER-AGENT)%",
      "x_forwarded_for": "%REQ(X-FORWARDED-FOR)%"
    }'

yuliyantsvetkov · 2022-06-20T06:02:33Z

I have problem with the mesh config, and I wonder how to apply ingressSelector, because my infrastructure differs from the default one.

I have two ingresses installed with different selector, due to the fact I route traffic in a way I need my ingresses totally separated.

When I apply the meshConfig the access logs of the ingresses is not affected, since they don't use the default ingressSelector string, but custom one.

This makes the JSON schema and the JSON encoding not to be applied on my ingresses, but only to work on default ingresses.

Any ideas ?

GregHanson · 2022-06-21T14:51:00Z

@yuliyantsvetkov what version of Istio are you using? You might be better off opening a new issue, and providing your meshConfig access log settings. The access log fields in meshconfig (spec here) are not conditional on the ingressSelector

rshriram assigned GregHanson Mar 4, 2019

rshriram added the area/networking label Mar 4, 2019

dwradcliffe mentioned this issue Mar 13, 2019

fix typo in default envoy JSON log format #12473

Merged

GregHanson closed this as completed Mar 25, 2019

jgournet mentioned this issue May 22, 2023

Json log ordering envoyproxy/envoy#27439

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Access log with JSON encoding #12232

Access log with JSON encoding #12232

njyeti commented Mar 4, 2019 •

edited

GregHanson commented Mar 4, 2019

njyeti commented Mar 4, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

GregHanson commented Mar 25, 2019

my3sons commented Nov 13, 2019

njyeti commented Nov 14, 2019

my3sons commented Nov 14, 2019

haf commented Feb 19, 2020

pantelis-karamolegkos commented Jan 26, 2021 •

edited

boeboe commented Mar 16, 2021 •

edited

quant-daddy commented Apr 12, 2021

hustshawn commented Jun 1, 2021 •

edited

sonnyhcl commented Aug 24, 2021

sonnyhcl commented Aug 24, 2021

yuliyantsvetkov commented Jun 20, 2022

GregHanson commented Jun 21, 2022

Access log with JSON encoding #12232

Access log with JSON encoding #12232

Comments

njyeti commented Mar 4, 2019 • edited

GregHanson commented Mar 4, 2019

njyeti commented Mar 4, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

dwradcliffe commented Mar 13, 2019

njyeti commented Mar 13, 2019

GregHanson commented Mar 25, 2019

my3sons commented Nov 13, 2019

njyeti commented Nov 14, 2019

my3sons commented Nov 14, 2019

haf commented Feb 19, 2020

pantelis-karamolegkos commented Jan 26, 2021 • edited

boeboe commented Mar 16, 2021 • edited

quant-daddy commented Apr 12, 2021

hustshawn commented Jun 1, 2021 • edited

sonnyhcl commented Aug 24, 2021

sonnyhcl commented Aug 24, 2021

yuliyantsvetkov commented Jun 20, 2022

GregHanson commented Jun 21, 2022

njyeti commented Mar 4, 2019 •

edited

pantelis-karamolegkos commented Jan 26, 2021 •

edited

boeboe commented Mar 16, 2021 •

edited

hustshawn commented Jun 1, 2021 •

edited