Why Qpoint?
Modern applications rely heavily on a wide array of external services, which introduces a host of new operational challenges:
- Reliability of platforms and core applications now hinges on the health of these external dependencies. An issue with a vendor's API may become your outage.
- Troubleshooting the root cause of an issue has become significantly more complex.
- Limited visibility into external requests and payloads which may contain sensitive information poses a serious data governance risk.
Qpoint addresses these challenges with a novel approach to egress observability that leverages eBPF technology and a next generation middleware framework to provide unparalleled visibility into the traffic flows between your applications and their external dependencies - without requiring code changes.
How does Qpoint work?
At the heart of Qpoint’s technology is an eBPF probe (Qtap) that runs in the data plane on your application hosts. Qtap operates on outbound application traffic (out-of-band) at the kernel level before encryption, providing access to the payloads while avoiding the need to manage certificates.
Qpoint's middleware subsystem further enables an operations team to seamlessly inject custom functions and execute complex traffic manipulations.
Our cloud control plane serves as the central nervous system for Qpoint by providing a graphical interface for users to monitor the status of endpoints, browse audit logs, configure alerting, and manage the fleet of eBPF probes deployed on the data plane.
Will our data leave our network?
The short answer: only if you explicitly choose to use Qpoint’s managed service for monitoring and analytics.
A Qpoint installation can generate two types of data:
- Logs: Logs contain metadata about the connection, the request, or the error, but do not contain payload information of any kind. Logs can be shipped to any log ingestion service.
- Snapshots: Conditionally generated snapshots are the actual request/response headers and bodies. Snapshots are submitted to S3 compatible endpoints (optionally encrypted).
For production deployments and highly-regulated environments, we strongly recommend using your own S3-compatible endpoint running within your own environment. You can also optionally run our custom monitoring and analytics service (Pulse) within your environment.
We offer the option of using Qpoint's fully managed Pulse service for operational simplicity, but no data will leave your network unless you explicitly choose to use this service.
Which programming languages are supported?
Qtap provides native TLS introspection into most languages, including the following that are confirmed to work: Ruby, Python, Nodejs and Golang. Any utility that uses OpenSSL is also supported. Languages that do not currently support native TLS introspection are Java, .NET, and Erlang (but support is coming soon).
Will there be a performance impact?
Qtap accesses the kernel via eBPF and also runs a user space application. The impact on CPU and memory is highly dependent on both the size and number of services running on the host.
Getting started with endpoint discovery, basic monitoring, and audit logging will have a minimal impact on system resources.
The impact of running more advanced middleware will depend on the nature of the functions that are running and how much of the overall traffic has middleware applied.