Skip to main content

Documentation Index

Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

The previous steps explain how to install Arize AX and access the UI with a local port-forward. However, to expose Arize AX to the broader organization, a secure HTTPs endpoint must be created.
HostPrefixServiceTarget Port
arize-app.<my-organization-domain>/internalendpoints-app443

​
Ingress Endpoints with GCP

First review the Terraform documentation in ./terraform/README.md as it includes parameters required to create static IP addresses. Re-apply Terraform if you change those resources. Static IP addresses are preferred as they allow a future rebuild of the cluster without impacting DNS entries. Make a copy of the example file below. 
$ cp ./examples/endpoints/gcp/app-services.yaml my-app-services.yaml
Review the following annotation to confirm that they align with the desired static IPs. If you use the Terraform modules from the distribution, these names already align with the values in Terraform outputs. 
annotations:
  kubernetes.io/ingress.global-static-ip-name: arize-app-services
Replace the placeholder hostname/domain name with the domain available in your organization. This domain name must be added to your DNS server and map to the static IP addresses mentioned above. 
'{{CUSTOMER_APP_DOMAIN}}' --> 'arize-app.<my-organization-domain>'
If configured correctly, the DNS server will resolve the domain to the correct IP address. Use nslookup to verify. 
$ nslookup arize-app.<my-organization-domain>'
Apply the manifest. 
$ kubectl -n arize apply -f my-app-services.yaml
Wait for a few minutes and verify the state of the ingress. 
$ kubectl -n arize describe ingress arize-app-services
The ingressMode parameter may need to be set correctly in values.yaml in order to work with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in the Ingress Controllers section. From a web browser enter https://arize-app.<my-organization-domain> to verify the access. Note that GCP may initially return an SSL error until the HTTPs certificate has been validated. If that is the case, check back 30 minutes later. Make sure to add these parameters tovalues.yaml and apply the changes. 
appBaseUrl: "https://arize-app.<my-organization-domain>"
expBaseUrl: "arize-app.<my-organization-domain>"

​
Ingress Endpoints with AWS

Since TLS termination is required, a Layer 7 ALB is the recommended option for AWS. The ALB can be created automatically by AWS when a Kubernetes Ingress resource is created and the AWS Load Balancer Controller is deployed. If you use the Terraform modules from the distribution, review the Terraform options to enable the Web Identity role and deploy the AWS Load Balancer Controller. Otherwise, refer to this page to manually deploy the AWS Load Balancer Controller: Installing the AWS Load Balancer Controller A few notes about the AWS Load Balancer Controller:
  • It requires public networks, Internet Gateway and routes in order to get an external IP.
  • Private subnets need the label “kubernetes.io/role/internal-elb” for subnet discovery
  • Public subnets need the label “kubernetes.io/role/elb” for subnet discovery
Make a copy of the example file below. 
$ cp ./examples/endpoints/aws/app-services.yaml my-app-services.yaml
Edit the following annotations. For a public endpoint use “internet-facing”. Change the certificate annotation to point to a valid certificate. 
annotations:
  ...
  alb.ingress.kubernetes.io/scheme: "internal" # Use "internet-facing" for public endpoint
  alb.ingress.kubernetes.io/certificate-arn: "<certificate-arn>"
Apply the manifest. 
$ kubectl -n arize apply -f my-app-services.yaml
Wait for a few minutes and verify the state of the ingress. 
$ kubectl -n arize describe ingress arize-app-services
The ingressMode parameter may need to be set correctly in values.yaml in order to work with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in the Ingress Controllers section. In some environments the external-dns.alpha.kubernetes.io/hostname annotation can be used to automatically create a DNS entry in Route 53. If another DNS system is used, collect the elb address from the ingress resource and request a DNS entry to be added mapping arize-app.<my-organization-domain> to the elb address. If configured correctly, the DNS server will resolve the domain to the correct IP address. Use nslookup to verify. 
$ nslookup arize-app.<my-organization-domain>'
From a web browser enter https://arize-app.<my-organization-domain> to verify the access. Make sure to add these parameters to values.yaml and apply the changes. 
appBaseUrl: "https://arize-app.<my-organization-domain>"
expBaseUrl: "arize-app.<my-organization-domain>"

​
Ingress Endpoints with Azure

The Azure AGIC does not currently support GRPC. For this reason Arize AI recommends using a Network Load Balancer and terminate TLS at the Arize AX pods. Make a copy of the example files below and review its content. 
$ cp ./examples/endpoints/azure/app-services.yaml my-app-services.yaml
Apply the manifest. 
$ kubectl -n arize apply -f my-app-services.yaml
Wait for a few minutes and verify the state of the service. 
$ kubectl -n arize describe service arize-app-services
Create a DNS entry pointing your desired domain/hostname (example: arize-app.<my-organization-domain>) to the IP address of the Network Load Balancer. If using self-signed certificates or a certificate is not available, create a certificate corresponding to your domain using: 
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out app-tls.crt \
    -keyout app-tls.key \
    -subj "/CN=arize-app.<my-organization-domain>/O=<company-name>" -addext "subjectAltName = DNS:arize-app.<my-organization-domain>"
Load the signed or self-signed certificate into Arize AX by updating values.yaml: 
internalEndpointsAppTlsCert: '<base64 encoded contents of TLS certificate file>'
internalEndpointsAppTlsKey: '<base64 encoded contents of TLS private key file>'
The ingressMode parameter may need to be set correctly in values.yaml in order to work with certain ingress controllers or if a user desires to port-forward to the service for testing. Further details can be found in the Ingress Controllers section. From a web browser enter https://arize-app.<my-organization-domain> to verify the access. Make sure to add these parameters to values.yaml and apply the changes. 
appBaseUrl: "https://arize-app.<my-organization-domain>"
expBaseUrl: "arize-app.<my-organization-domain>"

​
Ingress Endpoints with Traefik

Traefik can terminate TLS in front of the unified internalendpoints-app service (HTTP, REST, gRPC, OTLP, and Flight). For that pattern, Arize AX must be deployed with TLS off on the pod-facing path and HTTP/2 cleartext (h2c) from the ingress to the service. In values.yaml, set: 
ingressMode: "notls"
Make a copy of the example manifest. 
$ cp ./examples/endpoints/traefik/app-services.yaml my-app-services.yaml
Edit hostnames, TLS secrets, Traefik entry points (websecure in the sample), and optional IngressRoute / TLSStore resources to match your cluster. If you only need one routing mechanism, you may remove either the standard Ingress or the IngressRoute to avoid duplicate routes. The sample TLSStore and default-ingress-cert Secret use kube-system; if Traefik is installed in another namespace, put those resources (or equivalents) there, or omit them if you do not need a Traefik default certificate. Apply the manifest after the Arize AX services exist. 
$ kubectl -n arize apply -f my-app-services.yaml
Verify DNS resolves to your Traefik load balancer. 
$ nslookup arize-app.<my-organization-domain>'
Open https://arize-app.<my-organization-domain> in a browser. Add URL parameters to values.yaml if they are not already set: 
appBaseUrl: "https://arize-app.<my-organization-domain>"
expBaseUrl: "arize-app.<my-organization-domain>"

​
Ingress Endpoints with OpenShift

The OpenShift ingress controller configures an underlying HAProxy component. For proper GRPC operation certain settings on the OpenShift routes are required. Additionally, to enable HTTP/2 support, the following command should be executed for the target Ingress Controller (either a specific one or the default). This annotation can also be applied via the console UI’s under Administration -> CustomResourceDefinitions -> IngressController -> Instances -> default. If HTTP/2 is not enabled, gRPC clients may encounter errors such as: Cannot check peer: missing selected ALPN property* or *Selected ALPN Protocol: None. 
oc -n openshift-ingress-operator annotate ingresscontrollers/default ingress.operator.openshift.io/default-enable-http2=true
In the values.yaml file, the Arize AX ingressMode should be set to openshift. Important: This configuration must be applied before creating any routes, as OpenShift references the resulting appProtocol on the Arize AX ports during route creation. Specifically, for internal HTTP/2 ports, the appProtocol is set to h2c, indicating the use of HTTP/2 without TLS. 
ingressMode: 'openshift'
From the OpenShift console UI as an Administrator use Create Route from the Networking/Routes panel and enter the following data in the arize namespace Project to create the endpoints. Use Secure Route enabled and TLS termination Edge on each route. OpenShift does not allow a wildcard certificate with GRPC/HTTP2 protocols and therefore it is recommend to create a non-wildcard certificate on the arize-app route or to create second arize-api for API functions.
HostPrefixServiceTarget PortCertificate
arize-app.<my-organization-domain>/internalendpoints-app443Wildcard or non-wildcard
arize-api.<my-organization-domain>/internalendpoints-app443Non-wildcard
The arize-app (or arize-api) route is then edited to add a non-wildcard Certificate and Key matching the Host field from the route. This per route certificate is mentioned in Enabling HTTP/2 to allow GRPC traffic to transit the controller. The certificate can be created using openssl as shown below: 
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out app-tls.crt \
    -keyout app-tls.key \
    -subj "/CN=arize-app.<my-organization-domain>/O=<company-name>" -addext "subjectAltName = DNS:arize-app.<my-organization-domain>"
If using TLS termination Edge is not an option, a fallback method is to use a single passthrough route and mount the certificate at the pods using these parameters: 
ingressMode: 'tls'
internalEndpointsAppTlsCert: '<base64 encoded contents of TLS certificate file>'
internalEndpointsAppTlsKey: '<base64 encoded contents of TLS private key file>'

​
Ingress Controllers

For GRPC protocols like OTLP and flightserver, the ingressMode parameter may need to be set correctly in values.yaml in order to work with certain ingress controllers or if a user desires to port-forward to the service for testing. Here are the recommended settings:
Controller / Load BalanceringressModeinternalEndpointsAppTlsCert / internalEndpointsAppTlsKey
GCPtls (default)N/A
AWS ALBtls (default)N/A
Azure NLBtls (default)Custom certificate
Nginxtls (default)N/A
Kongtls (default)N/A
TraefiknotlsN/A
IstioistioN/A
OpenShift - EdgeopenshiftN/A
OpenShift - Pass-throughtlsCustom certificate
Local port-forwardnotlsN/A
TLS Termination at Arize AX Pods (NLB)tlsCustom certificate
More details on working with an OpenShift ingress controller are found in the OpenShift sections.