hubble is a free, open source monitoring & observability project written in Makefile and released under Apache-2.0. It has 4,332 GitHub stars, 300 forks and 44 open issues, and was last pushed 3 days ago. On this registry it ranks #75 of 97 tracked projects in Monitoring & Observability, with 5 head-to-head comparisons available. It gained 5 stars over the last 3 tracked days.

What is hubble?

What it is

Hubble is fully distributed networking and security observability platform for cloud native workloads. It lives in Kubernetes ecosystem, built on Cilium and eBPF. It gives transparent visibility into service communication, service behavior, and networking infrastructure.

It solves problem of limited visibility into Kubernetes network and security behavior without application changes. It answers questions about service dependencies, HTTP calls, Kafka topics, failed communication, DNS problems, TCP interruptions, connection timeouts, unanswered TCP SYN requests, HTTP error rates, latency percentiles, blocked network policy connections, outside cluster access, and DNS resolution.

Key capabilities

  • Maps service dependencies and communication, including which services communicate, how often, and resulting service dependency graph.
  • Captures application-layer visibility for HTTP calls and Kafka topic consumption or production.
  • Detects operational network failures, including DNS resolution problems, interrupted TCP connections, connection timeouts, and unanswered TCP SYN requests.
  • Measures application health with HTTP 4xx and 5xx response rates and 95th and 99th percentile HTTP request-response latency.
  • Supports security observability by showing connections blocked by network policy, services accessed from outside cluster, and services that resolved DNS name.
  • Uses eBPF through Cilium for programmable visibility without requiring application changes.
  • Provides stable core components: Hubble CLI, Hubble Server, Hubble Metrics, and Hubble Relay, while Hubble UI is beta.

Who uses it and how

  • In Kubernetes environments, it is used to inspect service-to-service communication and build service dependency maps.
  • For network and security observability, it is used to trace failed communication across DNS, TCP, and HTTP layers.
  • For application monitoring, it is used to review HTTP error rates, latency percentiles, and inter-service latency.
  • For security review, it is used to identify connections blocked by network policy and services accessed from outside cluster.
  • For multi-node deployments, Hubble Relay is used, while Hubble UI provides beta user interface.

Getting started

README points users to Introduction to Cilium and Hubble and Networking and Security Observability with Hubble for getting started, and it notes Hubble CLI is backward compatible with supported Cilium releases, while only latest Hubble CLI version is maintained. It does not list Docker image names, package managers, or hosted option.

When to use it — and when not to

Use it when Kubernetes workloads already use Cilium and eBPF-based visibility without changing applications is needed. Avoid it or be cautious when relying on Hubble UI, because that component is beta, and when provided README is only source for setup, because it gives documentation links but no concrete install or deployment method. Facts do not list paid products replaced, nor required database, storage, or SMTP operations.

project readme (upstream, from github) — read inline
Hubble Logo

License


Network, Service & Security Observability for Kubernetes

What is Hubble?

Hubble is a fully distributed networking and security observability platform for cloud native workloads. It is built on top of [Cilium] and [eBPF] to enable deep visibility into the communication and behavior of services as well as the networking infrastructure in a completely transparent manner.

Hubble can answer questions such as:

Service dependencies & communication map:

  • What services are communicating with each other? How frequently? What does the service dependency graph look like?
  • What HTTP calls are being made? What Kafka topics does a service consume from or produce to?

Operational monitoring & alerting:

  • Is any network communication failing? Why is communication failing? Is it DNS? Is it an application or network problem? Is the communication broken on layer 4 (TCP) or layer 7 (HTTP)?
  • Which services have experienced a DNS resolution problems in the last 5 minutes? Which services have experienced an interrupted TCP connection recently or have seen connections timing out? What is the rate of unanswered TCP SYN requests?

Application monitoring:

  • What is the rate of 5xx or 4xx HTTP response codes for a particular service or across all clusters?
  • What is the 95th and 99th percentile latency between HTTP requests and responses in my cluster? Which services are performing the worst? What is the latency between two services?

Security observability:

  • Which services had connections blocked due to network policy? What services have been accessed from outside the cluster? Which services have resolved a particular DNS name?

Why Hubble?

The Linux kernel technology [eBPF] is enabling visibility into systems and applications at a granularity and efficiency that was not possible before. It does so in a completely transparent way, without requiring the application to change or for the application to hide information. By building on top of [Cilium], Hubble can leverage [eBPF] for visibility. By leveraging [eBPF], all visibility is programmable and allows for a dynamic approach that minimizes overhead while providing deep and detailed insight where required. Hubble has been created and specifically designed to make best use of these new [eBPF] powers.

Releases

The Hubble CLI is backward compatible with all supported Cilium releases. For this reason, only the latest Hubble CLI version is maintained.

Version Release Date Maintained Supported Cilium Version Artifacts
v1.19 2026-06-04 (v1.19.4) Yes Cilium 1.19 and older GitHub Release

Component Stability

Hubble project consists of several components (see Architecture section).

While the core Hubble components have been running in production in multiple environments, new components continue to emerge as the project grows and expands in scope.

Some components, due to their relatively young age, are still considered beta and have to be used with caution in critical production workloads.

Component Area State
Hubble CLI Core Stable
Hubble Server Core Stable
Hubble Metrics Core Stable
Hubble Relay Multinode Stable
Hubble UI UI Beta

Architecture

Hubble Architecture

Getting Started

Features

Service Dependency Graph

Troubleshooting microservices application connectivity is a challenging task. Simply looking at "kubectl get pods" does not indicate dependencies between each service or external APIs or databases.

Hubble enables zero-effort automatic discovery of the service dependency graph for Kubernetes Clusters at L3/L4 and even L7, allowing user-friendly visualization and filtering of those dataflows as a Service Map.

See Hubble Service Map Tutorial for more examples.

Service Map

Metrics & Monitoring

The metrics and monitoring functionality provides an overview of the state of systems and allow to recognize patterns indicating failure and other scenarios that require action. The following is a short list of example metrics, for a more detailed list of examples, see the Metrics Documentation.

Networking Behavior

Networking

Network Policy Observation

Network Policy

HTTP Request/Response Rate & Latency

HTTP

DNS Request/Response Monitoring

DNS

Flow Visibility

Flow visibility provides visibility into flow information on the network and application protocol level. This enables visibility into individual TCP connections, DNS queries, HTTP requests, Kafka communication, and much more.

DNS Resolution

Identifying pods which have received DNS response indicating failure:

hubble observe --since=1m -t l7 -o json \
   | jq 'select(.l7.dns.rcode==3) | .destination.namespace + "/" + .destination.pod_name' \
   | sort | uniq -c | sort -r
  42 "starwars/jar-jar-binks-6f5847c97c-qmggv"

Successful query & response:

starwars/x-wing-bd86d75c5-njv8k            kube-system/coredns-5c98db65d4-twwdg      DNS Query deathstar.starwars.svc.cluster.local. A
kube-system/coredns-5c98db65d4-twwdg       starwars/x-wing-bd86d75c5-njv8k           DNS Answer "10.110.126.213" TTL: 3 (Query deathstar.starwars.svc.cluster.local. A)

Non-existent domain:

starwars/jar-jar-binks-789c4b695d-ltrzm    kube-system/coredns-5c98db65d4-f4m8n      DNS Query unknown-galaxy.svc.cluster.local. A
starwars/jar-jar-binks-789c4b695d-ltrzm    kube-system/coredns-5c98db65d4-f4m8n      DNS Query unknown-galaxy.svc.cluster.local. AAAA
kube-system/coredns-5c98db65d4-twwdg       starwars/jar-jar-binks-789c4b695d-ltrzm   DNS Answer RCode: Non-Existent Domain TTL: 4294967295 (Query unknown-galaxy.starwars.svc.cluster.local. A)
kube-system/coredns-5c98db65d4-twwdg       starwars/jar-jar-binks-789c4b695d-ltrzm   DNS Answer RCode: Non-Existent Domain TTL: 4294967295 (Query unknown-galaxy.starwars.svc.cluster.local. AAAA)

HTTP Protocol

Successful request & response with latency information:

starwars/x-wing-bd86d75c5-njv8k:53410      starwars/deathstar-695d8f7ddc-lvj84:80    HTTP/1.1 GET http://deathstar/
starwars/deathstar-695d8f7ddc-lvj84:80     starwars/x-wing-bd86d75c5-njv8k:53410     HTTP/1.1 200 1ms (GET http://deathstar/)

TCP/UDP Packets

Successful TCP connection:

starwars/x-wing-bd86d75c5-njv8k:53410      starwars/deathstar-695d8f7ddc-lvj84:80    TCP Flags: SYN
deathstar.starwars.svc.cluster.local:80    starwars/x-wing-bd86d75c5-njv8k:53410     TCP Flags: SYN, ACK
starwars/x-wing-bd86d75c5-njv8k:53410      starwars/deathstar-695d8f7ddc-lvj84:80    TCP Flags: ACK, FIN
deathstar.starwars.svc.cluster.local:80    starwars/x-wing-bd86d75c5-njv8k:53410     TCP Flags: ACK, FIN

Connection timeout:

starwars/r2d2-6694d57947-xwhtz:60948   deathstar.starwars.svc.cluster.local:8080     TCP Flags: SYN
starwars/r2d2-6694d57947-xwhtz:60948   deathstar.starwars.svc.cluster.local:8080     TCP Flags: SYN
starwars/r2d2-6694d57947-xwhtz:60948   deathstar.starwars.svc.cluster.local:8080     TCP Flags: SYN

Network Policy Behavior

Denied connection attempt:

starwars/enterprise-577

readme truncated — read the full docs on github

Frequently asked questions

Is hubble free to use?

hubble is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does hubble do?

Hubble - Network, Service & Security Observability for Kubernetes using eBPF

What is hubble written in?

hubble is primarily written in Makefile. Its source is publicly available at https://github.com/cilium/hubble, and it has 4,332 GitHub stars.