If your model is missing endpoints that you expect to be there, or is completely empty, it may be because you are trying to observe your API at a point where it is encrypted. In the Akita console, you can visit “Diagnostics > Traffic” and click on one of the client reports listed there. This will indicate whether Akita saw any traffic encrypted with TLS.

If this is the case for you, you can still potentially use Akita in other ways, or by changing where you run Akita.

Akita has built a Chrome extension that captures API requests and responses live in your browser as you’re using a web site: Akita OpenAPI Spec Generator. You can try this first to get a sense of how Akita will work, before attempting a deeper integration into your production systems.

The normal onboarding instructions connect Akita to a host network. If the traffic from the outside world goes through a service mesh or reverse proxy, then the unencrypted traffic from that proxy to your application goes over network local to the container or pod.

Instead, you can deploy Akita as a sidecar to your application’s container, so that it can see that unencrypted stream of traffic.

For Kubernetes, see Single-service Kubernetes or Kubernetes with Istio/Envoy in the Akita docs.

For other Docker platforms, see Docker Run for instructions on attaching Akita to a specific container’s network stack.

This technique will not work if traffic between the proxy or service mesh goes over a Unix Domain Socket (a named socket) instead of the local network. It is meant for configurations where your application is listening for unencrypted traffic on a network port, but communication from the outside world is handled by other software.

If HTTPS currently terminates at your application, then Akita will not be able to see the unencrypted version of your data. You could reconfigure your deployment to permit Akita to see the unencrypted data by adding a reverse proxy to serve as the HTTPS endpoint.

See Reverse Proxy for instructions on setting up NGINX, a popular open-source web server, as a reverse proxy. This reverse proxy can be set up as part of your container image, or run as a sidecar.

The reverse proxy, when configured with your certificate, will accept the HTTPS connection from clients, decrypt the data, and then send the unencrypted data to your application. The unencrypted data can be observed by the Akita agent on the local network. The easiest way to get started with this configuration is to have both NGINX and Akita configured as sidecars to your application container.

If you are using a load balancer, and your security policy permits it, you could have the load balancer terminate HTTPS, and communicate to the application via unencrypted HTTP. Amazon’s Application Load Balancer supports using either HTTP or HTTPS as a target, but only HTTP will be visible to the Akita agent.

Feel free to reach out to us through the Intercom chat or through the Akita Community Slack.