diff --git a/cloudhub-2/modules/ROOT/pages/ch2-integrate-log-system.adoc b/cloudhub-2/modules/ROOT/pages/ch2-integrate-log-system.adoc index fb15a374..c9d400a5 100644 --- a/cloudhub-2/modules/ROOT/pages/ch2-integrate-log-system.adoc +++ b/cloudhub-2/modules/ROOT/pages/ch2-integrate-log-system.adoc @@ -15,6 +15,7 @@ You can use only asynchronous log appenders. * File appenders, such as FileAppender, RollingFileAppender, AnypointMonitoringFileAppender, and RandomAccessFileAppender, are removed automatically. * When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Runtime Manager. * You can forward tracing module logs using only third-party appenders. You cannot update the logging patterns to send them to Anypoint Monitoring. +* Console logging is disabled by default in CloudHub 2.0. If you change log levels or appenders in a custom `log4j2.xml` and don't see the changes in the logs, use an appender that CloudHub 2.0 collects, such as a third-party appender that streams to your logging system. Log output from a Console appender alone doesn't appear in Runtime Manager. You can use any Log4j appender. @@ -23,6 +24,11 @@ https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSynt == Example: Create a Log4j Configuration Using Splunk +[IMPORTANT] +==== +Console logging is disabled by default in CloudHub 2.0. If you rely only on a Console appender, changes to log levels or appenders in your custom log4j2.xml might not appear in the logs in Runtime Manager. To apply your custom Log4j configuration, use an appender that streams logs to an external system, such as Splunk, or enable log integration for your deployment to collect console output. +==== + For logs to be viewable in CloudHub 2.0 and flow to Splunk, configure the `SplunkHttp` Log4j appender. diff --git a/cloudhub-2/modules/ROOT/pages/ps-config-advanced.adoc b/cloudhub-2/modules/ROOT/pages/ps-config-advanced.adoc index e956b7ed..c43bdef2 100644 --- a/cloudhub-2/modules/ROOT/pages/ps-config-advanced.adoc +++ b/cloudhub-2/modules/ROOT/pages/ps-config-advanced.adoc @@ -9,7 +9,7 @@ This value is the amount of time the CloudHub 2.0 ingress controller waits to re + [IMPORTANT] ==== -This timeout setting is separate from the read-request timeout, which controls how long the CloudHub 2.0 ingress controller waits to receive the full request from the client. The read-request timeout is hardcoded to 300 seconds, and you can't configure it. If your client takes longer than 300 seconds to send the complete request (for example, when uploading large files), CloudHub 2.0 drops the connection even if you have configured a longer read-response timeout. +This timeout setting is separate from the read-request timeout, which controls how long the CloudHub 2.0 ingress controller waits to receive the full request from the client. The read-request timeout is hardcoded to 300 seconds and isn't configurable. If your client takes longer than 300 seconds to send the complete request, for example, when uploading large files, CloudHub 2.0 drops the connection even if you configure a longer read-response timeout. For data transfers that exceed 300 seconds, consider breaking the request into smaller chunks or implementing asynchronous processing patterns. ==== @@ -60,7 +60,7 @@ Read Request Timeout (hardcoded at 300 seconds):: The time the CloudHub 2.0 ingress controller waits to receive the complete request from the client. If the client takes longer than 300 seconds to send the entire request payload (for example, uploading a large CSV file), CloudHub 2.0 drops the connection. This timeout is not user-configurable and applies to both shared and private spaces. Read Response Timeout (user-configurable):: -The time the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after the request has been forwarded. You can configure this timeout in the *Advanced* tab of your private space settings. This setting controls how long your Mule application has to process the request and begin sending a response. +The time the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after the request has been forwarded. Configure this timeout in the *Advanced* tab of your private space settings. This setting controls how long your Mule application takes to process the request and begin sending a response. Connection Idle Timeout (hardcoded at 15 seconds):: The time the CloudHub 2.0 ingress controller waits before closing an idle connection when no data is being transferred. @@ -77,7 +77,7 @@ For long-running operations that exceed these timeout limits, consider implement CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for all apps deployed to the private space. [IMPORTANT] -More verbose log levels might affect performance. +More verbose log levels affect performance. // SELECT PRIVATE SPACE SHARED include::partial$select-private-space.adoc[tag=selectPrivateSpace] @@ -92,7 +92,7 @@ include::partial$select-private-space.adoc[tag=clickAdvanced] CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for specific IP addresses, for example, for troubleshooting. [IMPORTANT] -More verbose log levels might affect performance. +More verbose log levels affect performance. // SELECT PRIVATE SPACE SHARED include::partial$select-private-space.adoc[tag=selectPrivateSpace] @@ -149,7 +149,7 @@ include::partial$select-private-space.adoc[tag=clickAdvanced] [[configure-aws-role]] == Configure AWS Service Role -If you have identity and access management (IAM) roles configured in AWS, you can associate the role with your private space. The private space receives the permissions from the IAM role in AWS and can access AWS resources. To configure this feature in AWS: +If you have identity and access management (IAM) roles configured in AWS, associate the role with your private space. The private space receives the permissions from the IAM role in AWS and accesses AWS resources. To configure this feature in AWS: * Use the unique AWS IAM role name that Anypoint Platform generates. * Use the organization ID for the organization in which the private space was configured. @@ -164,33 +164,11 @@ include::partial$select-private-space.adoc[tag=clickAdvanced] . Click *Enable AWS Service Role*. . Click *Save Changes* or *Discard changes*. + -A unique service role name is generated, and you can use this role to configure identity and access management for AWS. Role generation takes a few minutes. If the role name doesn't appear, refresh the page. +A unique service role name is generated. Use this role to configure identity and access management for AWS. Role generation takes a few minutes. If the role name doesn't appear, refresh the page. [NOTE] Each private space supports only one AWS service role. -[[aws-iam-role-sts-s3-connector-conflict]] -=== IAM Roles and AWS S3 Connector: STS Endpoint Behavior - -When you enable the AWS service role for a private space, the EKS cluster injects environment variables such as `AWS_STS_REGIONAL_ENDPOINTS=regional`. The AWS SDK credential provider that this setup uses, WebIdentityTokenFileCredentialsProvider, ignores any custom `endpointOverride` or STS endpoint settings in your Mule application and always uses the default regional STS endpoint. - -[IMPORTANT] -==== -When you enable a Private Space IAM role, the AWS SDK ignores custom STS endpoints in your Mule code and uses the public regional STS endpoint. If your network firewall or application-level egress rules don't allow outbound traffic to that STS endpoint, connectivity tests for the AWS S3 Connector and other AWS SDK-based connectors fail and applications hang or stop progressing. Allow the public regional STS endpoint, such as `sts.{region}.amazonaws.com`, in your private space firewall rules and, if you use them, in your application-level egress rules. -==== - -To allow connectivity, allow outbound HTTPS on port 443 to the regional STS endpoint for the region where your private space runs. Configure this in xref:ps-config-fw-rules.adoc[] and, when using app-level egress, in xref:ps-config-app-level-egress.adoc[]. - -If allowlisting isn't possible, set the `AWS_ENDPOINT_URL` environment variable for your application to the desired STS endpoint URL so the SDK uses it instead of the default regional endpoint. - -To apply the workaround: - -. In Runtime Manager, open your application and go to the *Settings* > *Properties* tab. -. Add an application property or environment variable that sets `AWS_ENDPOINT_URL` to your STS endpoint URL, for example `https://sts.{region}.amazonaws.com` or your custom endpoint. -. Apply the changes and redeploy or restart the application, so the runtime uses the new value. - -For more information about setting environment variables or properties for your application, see xref:ch2-manage-props.adoc#example-using-properties-to-set-environment-variables[Example: Using Properties to Set Environment Variables]. - == See Also * xref:ps-config-fw-rules.adoc[]