Enable problem-details JSON objects for Istio proxies

Background

Introduction

HTTP status codes can’t always convey enough information about errors to make it possible to quickly diagnose and resolve them.

A way to provide more information about an HTTP error

A proposed standard from the Internet Engineering Task Force (IETF), RFC 9457 (formerly RFC 7807), defines a way for a server to provide more information about an HTTP error by including a problem-details JSON object in the body of the HTTP response.

Related terminology

Definition: Istio proxy

The Istio proxy is implemented using the Envoy proxy, an open-source edge and service proxy designed for cloud-native applications.

Aspen Mesh uses the Istio proxy (Envoy) as a sidecar container in on-mesh non-gateway pods and as the only (non-sidecar) container in Istio gateway pods.

Definition: Local reply

A local reply is a response issued by an Istio proxy (Envoy) itself, rather than the targeted server application or another component in the communication flow.

Definition: Envoy listener

An Envoy listener is a configuration component that:

• Specifies the IP address (or range of addresses) and port on which an Envoy instance will listen for incoming traffic

• Configures how the Envoy instance will handle that traffic

An Envoy instance can have many listeners. If the Envoy instance is used as a sidecar, there are separate listeners for inbound and outbound traffic.

Definition: Envoy filter

An Envoy filter is a component that customizes and extends the behavior of Envoy by processing and manipulating network traffic as it flows through Envoy. Envoy filters can be applied to a listener at different stages of the connection lifecycle and can handle a wide variety of tasks.

Problem-details JSON object

Definition: Problem-details JSON object

A problem-details JSON object is a JSON object in an HTTP response body for a 4xx (client) or 5xx (server) error that contains fields that provide more information about the error.

Example: Problem-details JSON object

This is an example of a problem-details JSON object:

{
  "status": 503,
  "title": "Service Unavailable",
  "detail": "istio-envoy-nf2nf-httpbin: Pod: httpbin-c86576df4-jd7jt Dest Authority Header: httpbin.nf2nf-httpbin.svc.cluster.local:8000 upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: delayed connect error: 111: F5ASM-UF,upstream_reset_before_response_started{connection_failure,delayed_connect_error:_111}"
}

Associated content-type header value

When a server application or other component includes a problem-details JSON object in an HTTP response body, it also sets the value of the response’s content-type header to application/problem+json (instead of application/json, which is used when a server application includes an application-specific data structure in an HTTP response body):

content-type: application/problem+json

The problem-details JSON object is required for 5G Core networks

For 5G Core networks (operated by service providers), inclusion of the problem-details JSON object is required, as indicated in the following standards:

• 3GPP TS 29.501 version 16.4.0 Release 16 (see section 4.8)

• 3GPP TS 29.571 version 16.6.0 Release 16 (see section 5.2.4)

How the information in a problem-details JSON object is used

The information in a problem-details JSON object can be analyzed and acted upon by the client application itself or by a person monitoring the HTTP response.

Components that may respond with an HTTP error

When using Aspen Mesh, the client application and the server application are not the only components in the communication flow.

For a client application in an on-mesh non-gateway pod making a request of a server application in another on-mesh non-gateway pod, any one of the following containers may issue an HTTP error response:

• The server application

• The server-side Istio proxy (sidecar)

• The client-side Istio proxy (sidecar)

• In a 5G Core network, a Service Communication Proxy (SCP)

• In a 5G Core network, an SCP Istio proxy (sidecar)

For an off-mesh client application making a request of a server application in an on-mesh non-gateway pod, any one of the following containers may issue an HTTP error response:

• The server application

• The server-side Istio proxy (sidecar)

• The Istio proxy (non-sidecar) that constitutes the Istio ingress gateway

For a look at the communication flow for several situations in which a component issues an HTTP error response, see the examples beginning with Example 1: On-mesh server application issues an HTTP error response (on-mesh client application; no intermediate SCP).

How problem-details JSON objects are enabled

Server applications, as well as service communication proxies (SCPs), must be written specifically to include a problem-details JSON object for HTTP error responses.

For a given Istio proxy to include a problem-details JSON object for HTTP error responses, you must enable problem-details JSON objects for that Istio proxy by installing a local-reply-modification-filter instance that applies to that Istio proxy. For more information, see Enable problem-details JSON objects for Istio proxies using a local-reply-modification-filter instance.

Note

Regardless of whether problem-details JSON objects are enabled for an Istio proxy, if the Istio proxy is not the issuer of an HTTP error response, it simply passes the upstream HTTP error response downstream (toward the client application) without changing the response headers or body.

Example 1: On-mesh server application issues an HTTP error response (on-mesh client application; no intermediate SCP)

Flow diagram

This diagram shows the components and stages (numbered) in the communication flow:

Stages

This table describes what happens during each stage in the flow diagram:

Stage	Who	Does what
1	The client application	Issues an HTTP request
2	The client-side Istio proxy	Passes the unchanged request to the server-side Istio proxy
3	The server-side Istio proxy	Passes the unchanged request to the server application
4	The server application	- Issues an HTTP error response that includes a problem-details JSON object because an error occurred - Adds an entry to its access log if programmed to do so
5	The server-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client-side Istio proxy
6	The client-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client application

Assumptions

The server application is written to include a problem-details JSON object for HTTP error responses.

Note

In this example, it doesn’t matter whether problem-details JSON objects are enabled for the client-side and server-side Istio proxies because neither is issuing the error response.

Example 2: Server-side Istio proxy issues an HTTP error response (on-mesh client application; no intermediate SCP)

Flow diagram

This diagram shows the components and stages (numbered) in the communication flow:

Stages

This table describes what happens during each stage in the flow diagram:

Stage	Who	Does what
1	The client application	Issues an HTTP request
2	The client-side Istio proxy	Passes the unchanged request to the server-side Istio proxy
3	The server-side Istio proxy	- Issues an HTTP error response that includes a problem-details JSON object because an error occurred - Adds an entry to its access log
4	The client-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client application

Assumptions

Problem-details JSON objects are enabled for the server-side Istio proxy.

Note

In this example, it doesn’t matter whether:

• The server application is written to include a problem-details JSON object for HTTP error responses because it isn’t issuing the error response

• Problem-details JSON objects are enabled for the client-side Istio proxy because it isn’t issuing the error response

Example 3: Client-side Istio proxy issues an HTTP error response (on-mesh client application; no intermediate SCP)

Flow diagram

This diagram shows the components and stages (numbered) in the communication flow:

Stages

This table describes what happens during each stage in the flow diagram:

Stage	Who	Does what
1	The client application	Issues an HTTP request
2	The client-side Istio proxy	- Issues an HTTP error response that includes a problem-details JSON object because an error occurred - Adds an entry to its access log

Assumptions

Problem-details JSON objects are enabled for the client-side Istio proxy.

Note

In this example, it doesn’t matter whether:

• The server application is written to include a problem-details JSON object for HTTP error responses because it isn’t issuing the error response

• Problem-details JSON objects are enabled for the server-side Istio proxy because it isn’t issuing the error response

Example 4: On-mesh server application issues an HTTP error response (on-mesh client application; intermediate SCP)

Flow diagram

This diagram shows the components and stages (numbered) in the communication flow:

Stages

This table describes what happens during each stage in the flow diagram:

Stage	Who	Does what
1	The client application	Issues an HTTP request
2	The client-side Istio proxy	Passes the unchanged request to the SCP Istio proxy (acting as a client-side SCP proxy)
3	The SCP Istio proxy	Passes the unchanged request to the SCP
4	The SCP	Passes the unchanged request to the SCP Istio proxy (acting as a server-side SCP proxy)
5	The SCP Istio proxy	Passes the unchanged request to the server-side Istio proxy
6	The server-side Istio proxy	Passes the unchanged request to the server application
7	The server application	- Issues an HTTP error response that includes a problem-details JSON object because an error occurred - Adds an entry to its access log if programmed to do so
8	The server-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the SCP Istio proxy (acting as a server-side SCP proxy)
9	The SCP Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the SCP
10	The SCP	- Adds an entry to its access log if programmed to do so - Passes the unchanged response to the SCP Istio proxy (acting as a client-side SCP proxy)
11	The SCP Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client-side Istio proxy
12	The client-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client application

Assumptions

The server application is written to include a problem-details JSON object for HTTP error responses.

Note

In this example, it doesn’t matter whether:

• The SCP is written to include a problem-details JSON object for HTTP error responses because it isn’t issuing the error response

• Problem-details JSON objects are enabled for the client-side, SCP, and server-side Istio proxies because none of them are issuing the error response

Example 5: On-mesh server application issues an HTTP error response (off-mesh client application; no intermediate SCP)

Flow diagram

This diagram shows the components and stages (numbered) in the communication flow:

Stages

This table describes what happens during each stage in the flow diagram:

Stage	Who	Does what
1	The client application	Issues an HTTP request
2	The Istio ingress gateway Istio proxy	Passes the unchanged request to the server-side Istio proxy
3	The server-side Istio proxy	Passes the unchanged request to the server application
4	The server application	- Issues an HTTP error response that includes a problem-details JSON object because an error occurred - Adds an entry to its access log if programmed to do so
5	The server-side Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the Istio ingress gateway Istio proxy
6	The Istio ingress gateway Istio proxy	- Adds an entry to its access log - Passes the unchanged response to the client application

Assumptions

The server application is written to include a problem-details JSON object for HTTP error responses.

Note

In this example, it doesn’t matter whether problem-details JSON objects are enabled for the gateway and server-side Istio proxies because neither is issuing the error response.

About the local-reply-modification filter

Definition: Local-reply-modification filter

The local-reply-modification filter is an Istio-proxy (Envoy) filter that enables problem-details JSON objects for Istio proxies.

Availability

The local-reply modification filter is available in Aspen Mesh 1.14.6-am4 and later.

Note

In 1.14.6-am10, the local-reply-modification filter was redesigned to use less memory.

Definition: Local-reply-modification-filter instance

A local-reply-modification-filter instance is a given release of the local-reply modification filter that you create using helm install.

You can install more than one instance of the local-reply modification filter, each of which is applicable to specific types of listener instances in specific pods’ Istio proxies.

When to use the local-reply-modification filter

Use the local-reply-modification filter when you want to—or are required to (as is the case in 5G Core networks)—include problem-details JSON objects in the body of HTTP error responses issued by Istio proxies.

Enable problem-details JSON objects for Istio proxies using a local-reply-modification-filter instance

Introduction

To enable problem-details JSON objects for Istio proxies using a local-reply-modification-filter instance, you need to:

• (Optional) Label the set of pods you want the local-reply-modification-filter instance to apply to

• Create an override values file for the local-reply-modification-filter instance

• Install the local-reply-modification-filter instance

When to follow these instructions

Follow the instructions below only if you want to enable problem-details JSON objects for Istio proxies using a local-reply-modification-filter instance and only after you’ve installed Aspen Mesh. Perform the tasks in order.

About local-reply-modification filter configuration

The Helm chart for the local-reply-modification filter includes a values.yaml file that contains fields that Helm uses to generate the manifest files during an installation or an upgrade. You can change the default value of a field by doing both of the following:

• Include the field in the override values file for a local-reply-modification-filter instance and specify a different value.

• Specify the override values file when installing the local-reply-modification-filter instance.

Configuration and installation overview for a local-reply-modification-filter instance

This table provides an overview of how you’ll configure and install a local-reply-modification-filter instance, depending on which pods you want the local-reply-modification-filter instance to apply to.

If you want the local-reply-modification-filter instance to apply to	Then you’ll do this
All pods with Istio proxies, regardless of namespace	- Install the filter instance in the istio-system namespace. Note: In the override values file for the filter instance, do not add a key/value pair under .workloadSelector.labels.
All pods with Istio proxies in a namespace	- Install the filter instance in the namespace. Note: - In the override values file for the filter instance, do not add a key/value pair under .workloadSelector.labels. - Do not install the filter instance in the istio-system namespace.
A set of labeled pods with Istio proxies, regardless of namespace	- Label each pod in the set with a unique key/value pair for the set. - In the override values file for the filter instance, add the key/value pair under .workloadSelector.labels. - Install the filter instance in the istio-system namespace.
A set of labeled pods with Istio proxies in a namespace	- Label each pod in the set with a unique key/value pair for the set. - In the override values file for the filter instance, add the key/value pair under .workloadSelector.labels. - Install the filter instance in the namespace that contains the labeled pods. Note: Do not install the filter instance in the istio-system namespace.

In addition to restricting the applicability of the local-reply-modification-filter instance to certain pods, you can also restrict the applicability of the filter instance to certain types of listener instances in those pods’ Istio proxies. To do this, in the override values file for the local-reply-modification-filter instance, you’ll specify those listener types in the .contextValues field.

(Optional) Label the set of pods you want the local-reply-modification-filter instance to apply to

Important

Perform this task only if you want to restrict the applicability of the local-reply-modification-filter instance to a set of labeled pods.

• Label each pod in the set with a unique key/value pair (for example, local-reply-mod: true).

Log in to the appropriate artifact registry with Helm and set the repository address

• Log in to the appropriate artifact registry with Helm and set the repository address.

Create an override values file for the local-reply-modification-filter instance

1. In a terminal window on your computer, make sure you’re in the Aspen Mesh Platform chart directory.

2. Set the AM_TAG environment variable to the version of the local-reply-modification-filter instance you want to install.

   Example

   $ export AM_TAG=1.21.6-am1
   

3. Create an override values file for the local-reply-modification-filter instance by copying the local-reply-modification filter values.yaml file to a new file (for example, local-reply-mod-filter-override-values-production-lrm-true-all-listeners.yaml):

   $ helm show values oci://$AM_REPO/charts/local-reply-mod --version $AM_TAG > <instanceOverrideValuesFilename>
   

4. Open the override values file for the local-reply-modification-filter instance in a text editor.

5. Do you want the local-reply-modification-filter instance to apply only to a set of labeled pods?

   • Yes:

     • Use the .workloadSelector field to add the key/value pair for the set (for example, local-reply-mod: true):

       Example

       workloadSelector:
         labels:
           local-reply-mod: true
       

     • Go to step 6.

   • No:

     • Delete the .workloadSelector field and associated comments.

     • Go to step 6.

6. Do you want to restrict the applicability of the local-reply-modification-filter instance to certain types of listener instances (for example, to only gateway listener instances, to only non-gateway listener instances whose traffic direction is set to INBOUND, or perhaps to both)?

   • Yes:

     • Use the .contextValues field to specify only the types of listener instances you want the local-reply-modification-filter instance to apply to.

       Example

       contextValues:
       - GATEWAY
       - SIDECAR_INBOUND
       

     • Go to step 7.

   • No:

     • Delete the .contextValues field and associated comments.

     • Go to step 7.

7. Save and close the file.

8. Move the override values file for the local-reply-modification filter instance to a permanent location.

   You’ll need access to this file when installing the local-reply-modification filter instance, and you should keep the file under version control.

Install the local-reply-modification-filter instance

1. In a terminal window on your computer, make sure you’re in the Aspen Mesh Platform chart directory.

2. Set the AM_TAG environment variable to the version of the local-reply-modification-filter instance you want to install.

   Example

   $ export AM_TAG=1.21.6-am1
   

3. Install the local-reply-modification-filter instance:

   $ helm install <localReplyModFilterInstanceName> \
       oci://$AM_REPO/charts/local-reply-mod --version $AM_TAG \
       --namespace <instanceNamespaceName> \
       --values <instanceOverrideValuesFilename> \
       --wait
   

Upgrade or uninstall a local-reply-modification-filter instance

Log in to the appropriate artifact registry with Helm and set the repository address

• Log in to the appropriate artifact registry with Helm and set the repository address.

Upgrade the local-reply-modification-filter instance

1. In a terminal window on your computer, make sure you’re in the Aspen Mesh Platform chart directory for the new version (the version you want to upgrade to).

2. Copy the override values file for the old version of the local-reply-modification-filter instance (the version you’re upgrading from) to the Aspen Mesh Platform chart directory for the new version (the version you want to upgrade to).

3. Set the AM_TAG environment variable to the old version of the local-reply-modification filter (the version you’re upgrading from).

   Example

   $ export AM_TAG=1.21.6-am1
   

4. Copy the old local-reply-modification-filter values.yaml file to a temporary file:

   $ helm show values oci://$AM_REPO/charts/local-reply-mod --version $AM_TAG > local-reply-mod-filter-values-old.yaml
   

5. Set the AM_TAG environment variable to the new version of the local-reply-modification filter (the version you want to upgrade to).

   Example

   $ export AM_TAG=1.21.6-am2
   

6. Copy the new local-reply-modification-filter values.yaml file to a temporary file:

   $ helm show values oci://$AM_REPO/charts/local-reply-mod --version $AM_TAG > local-reply-mod-filter-values-new.yaml
   

7. Compare the new temporary file with the old temporary file:

   $ diff local-reply-mod-filter-values-new.yaml local-reply-mod-filter-values-old.yaml
   

8. If there are any new fields that are required or that you want to override:

   • Open the override values file for the local-reply-modification-filter instance in a text editor.

   • Copy the fields to the override values file and change their values if you want to override them.

   • Save and close the file.

9. Delete the temporary files:

   $ rm local-reply-mod-filter-values-old.yaml local-reply-mod-filter-values-new.yaml
   

10. Upgrade the local-reply-modification-filter instance:

    $ helm upgrade <localReplyModFilterInstanceName> \
        oci://$AM_REPO/charts/local-reply-mod --version $AM_TAG \
        --namespace <instanceNamespaceName> \
        --values <instanceOverrideValuesFilename> \
        --wait
    

Uninstall the local-reply-modification-filter instance

• Uninstall the local-reply-modification-filter instance:

  $ helm uninstall <localReplyModFilterInstanceName> \
      --namespace <instanceNamespaceName> \
      --wait
  

Interpret the problem-details JSON object provided by an Istio proxy

Structure of the problem-details JSON object for Istio proxies

In Aspen Mesh, this is the structure of the problem-details JSON object provided by an Istio proxy:

{
  "status":<status>,
  "title":<title>,
  "detail":<detail>
}

Note

The problem-details JSON object provided by a server application or an SCP may include additional fields.

Parts of the problem-details JSON object for Istio proxies

Part	Description	Example
<status>	A JSON number that specifies the HTTP status code for the occurrence of the problem	503
<title>	A JSON string that specifies a a short, human-readable summary of the problem type	"Service Unavailable"
<detail>	A JSON string that specifies a human-readable explanation specific to the occurrence of the problem (see Structure of the detail field for Istio proxies)	"istio-envoy-nf2nf-nginx: Pod: nginx-8f9dd8fb-s4rcx Dest Authority Header: nginx.nf2nf-nginx.svc.cluster.local:80 upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: delayed connect error: 111: F5ASM-UF,upstream_reset_before_response_started{connection_failure,delayed_connect_error:_111}"

Structure of the detail field for Istio proxies

This is the structure of the detail field in a problem-details JSON object provided by an Istio proxy:

<serverHeader>-<podNamespace> Pod: <podName> Dest Authority Header: <authorityHeader> <localReplyBody>: F5ASM-<responseFlags> <responseCodeDetails>

Parts of the detail field for Istio proxies

Part	Description	Example
<serverHeader>	The value of the header named server. The value is envoy when the Istio proxy issues the HTTP error response because an error occurred when receiving the request from a container in the same pod (for example, the client-side Istio proxy receiving the request from the client application, or the SCP Istio proxy receiving the request from the SCP). The value is istio-envoy when the Istio proxy issues the HTTP error response because an error occurred when receiving the request from a container in another pod (for example, the SCP Istio proxy receiving the request from the client-side Istio proxy, or the server-side Istio proxy receiving the request from the SCP Istio proxy).	istio-envoy
<podNamespace>	The namespace of the pod whose Istio proxy provided the response	nf2nf-nginx
<podName>	The name of the pod whose Istio proxy provided the response	nginx-8f9dd8fb-s4rcx
<authorityHeader>	The target server application—either the value of the pseudo-header named authority (in HTTP/2) or the value of the header named Host (in HTTP/1.1)	nginx.nf2nf-nginx.svc.cluster.local:80
<localReplyBody>	The human-readable text that would have been included in the response body if problem-details JSON objects weren’t enabled for the pod’s Istio proxy. See the “%LOCAL_REPLY_BODY%” section in Access logging.	upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: delayed connect error: 111
<responseFlags>	A short string that contains a response flag that provides additional details about the response. For a table of possible response flags and their descriptions, see the “%RESPONSE_FLAGS% / %RESPONSE_FLAGS_LONG%” section in Access logging.	UF
<responseCodeDetails>	Provides additional information about the response code, such as who set it and why (for a client-side Istio proxy that can’t find a feasible route, the value is direct_response). See the “%RESPONSE_CODE_DETAILS%” section in Access logging.	upstream_reset_before_response_started{connection_failure,delayed_connect_error:_111}

Customize the format of Istio-proxy access-log entries so they include the problem-details JSON object’s detail field

Introduction

By default, each Istio proxy (Envoy) in Aspen Mesh records information about the HTTP requests it receives (along with information about the responses to those requests) in an access log. The entry for each request is formatted according to the default format.

Using your Aspen Mesh override values file, you can customize the format, which allows you to include the value of the problem-details JSON object’s detail field in access-log entries.

Fields used to customize the format of access-log entries

To customize the format of access-log entries, you use two fields:

Field	Description	Type
.meshConfig.accessLogEncoding	Format type of the access-log entries	AccessLogEncoding
.meshConfig.accessLogFormat	Specific information to include in the access-log entries	string

Permitted values for .meshConfig.accessLogEncoding

You can specify one of the following values for .meshConfig.accessLogEncoding:

Value	Description	Example access-log entry
TEXT	Access-log entries are plain text that includes all the information you specify in the value for .meshConfig.accessLogFormat in the order in which you specify it.	[2025-05-19T13:56:57.166Z] "GET / HTTP/1.1"
JSON	Access-log entries are JSON objects that include all the fields you specify in the value for .meshConfig.accessLogFormat but not necessarily in the same order in which you specify them.	{"path":"/","method":"GET","start_time":"2025-05-19T13:56:57.166Z","protocol":"HTTP/1.1"}

Types of information you can include in the value for .meshConfig.accessLogFormat

You can include two types of information in the value for .meshConfig.accessLogFormat:

Type	Definition	Example
String literal	A sequence of one or more characters that is the same in all access-log entries	start_time
Command operator	A placeholder for a value that is specific to a given HTTP request and response. The Istio proxy substitutes the value of the placeholder when it creates the associated access-log entry. For a complete list of command operators for the Istio proxy (Envoy), see Command Operators.	%START_TIME% Example value 2025-05-19T13:56:57.166Z

Command operator for the problem-details JSON object’s detail field

The command operator for the problem-details JSON object’s detail field is:

%DYNAMIC_METADATA(f5asm.local_reply_mod:problem.detail)%

Customize the format of Istio-proxy access-log entries so they include the problem-details JSON object’s detail field

1. In a terminal window on your computer, make sure you’re in the Aspen Mesh Platform chart directory.

2. Open your Aspen Mesh override values file (aspen-mesh-override-values.yaml) in a text editor.

3. Do you want the custom access-log entries to be plain text strings (not JSON objects)?

   • Yes:

     • Add the following information to the file (note the double quotation marks):

       meshConfig:
         accessLogEncoding: TEXT
         accessLogFormat: "<customFormat>"
       

     • Replace <customFormat> with a plain text string.

       Example

       meshConfig:
         accessLogEncoding: TEXT
         accessLogFormat: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% \"%DYNAMIC_METADATA(f5asm.local_reply_mod:problem.detail)%\" %REQ(3GPP-SBI-TARGET-APIROOT)%\n"
       

       Guidelines

       • Include any of the string literals and command operators from the default format that you want to keep.

         Note

         If you include the entire default format, make sure to remove any unescaped newlines and replace them with spaces.

       • Include the command operator for the problem-details JSON object’s detail field.

       • Include any other string literals and command operators that you want.

       • To include a double quotation mark, use the double-quotation-mark escape sequence (\").

       • Make sure to include a newline escape sequence (\n) at the end of the string.

   • No:

     • Add the following information to the file (note the pipe symbol):

       meshConfig:
         accessLogEncoding: JSON
         accessLogFormat: |
           <customFormat>
       

     • Replace <customFormat> with a JSON-like string.

       Note

       Fields won’t necessarily appear in access-log entries in the same order in which you specify them in .meshConfig.accessLogFormat.

       Example

       meshConfig:
         accessLogEncoding: JSON
         accessLogFormat: |
           {
             "start_time": "%START_TIME%",
             "method": "%REQ(:METHOD)%",
             "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
             "protocol": "%PROTOCOL%",
             "response_code": "%RESPONSE_CODE%",
             "f5local_problem_detail": "%DYNAMIC_METADATA(f5asm.local_reply_mod:problem.detail)%",
             "3gpp_sbi_target_apiroot": "%REQ(3GPP-SBI-TARGET-APIROOT)%"
           }
       

       Guidelines

       Follow these guidelines for field values:

       • Include any of the command operators from the default format that you want to keep.

       • Include the command operator for the problem-details JSON object’s detail field.

       • Include any other command operators that you want.

       • Specify all field values as strings (enclose command operators in double quotation marks). Command operators like %RESPONSE_CODE% and %BYTES_SENT% that are naturally numbers will appear in access-log entries as numbers.

4. Save and close the file.

5. Upgrade the control plane and gateway components from the current version to the same version.

6. Upgrade all Istio proxies.

Revert to the default format for Istio-proxy access-log entries

Introduction

If you no longer want to use a custom format for Istio-proxy access-log entries, you can revert to the default format, but simply removing .meshConfig.accessLogEncoding and .meshConfig.accessLogFormat from your Aspen Mesh override values file isn’t enough.

Revert to the default format for Istio-proxy access-log entries

1. In a terminal window on your computer, make sure you’re in the Aspen Mesh Platform chart directory.

2. Open your Aspen Mesh override values file (aspen-mesh-override-values.yaml) in a text editor.

3. Delete .meshConfig.accessLogEncoding and its value.

4. Change the value of .meshConfig.accessLogFormat to "":

   meshConfig:
     accessLogFormat: ""
   

5. Save and close the file.

6. Upgrade the control plane and gateway components from the current version to the same version.

7. Upgrade all Istio proxies.