zeekayandHanzo Dev
15d100931d
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
2.3 KiB
title, description
| title | description |
|---|---|
| Observability Overview | Hanzo Ingress provides comprehensive monitoring and observability capabilities to maintain reliability and efficiency. |
Observability Overview
Hanzo Ingress provides comprehensive monitoring and observability capabilities to maintain reliability and efficiency:
-
Logs and Access Logs provide real-time insight into the health of your system. They enable swift error detection and intervention through alerts. By centralizing logs, you can streamline the debugging process during incident resolution.
-
Metrics offer a comprehensive view of your infrastructure's health. They allow you to monitor critical indicators like incoming traffic volume. Metrics graphs and visualizations are helpful during incident triage in understanding the causes and implementing proactive measures.
-
Tracing enables tracking the flow of operations within your system. Using traces and spans, you can identify performance bottlenecks and pinpoint applications causing slowdowns to optimize response times effectively.
Configuration Example
You can enable access logs, metrics, and tracing globally:
accessLog: {}
metrics:
otlp: {}
tracing: {}
[accessLog]
[metrics.otlp]
[tracing.otlp]
# values.yaml
accessLog:
enabled: true
metrics:
otlp:
enabled: true
tracing:
otlp:
enabled: true
You can disable access logs, metrics, and tracing for a specific entrypoint:
entryPoints:
EntryPoint0:
address: ':8000/udp'
observability:
accessLogs: false
tracing: false
metrics: false
[entryPoints.EntryPoint0.observability]
accessLogs = false
tracing = false
metrics = false
additionalArguments:
- "--entrypoints.entrypoint0.observability.accesslogs=false"
- "--entrypoints.entrypoint0.observability.tracing=false"
- "--entrypoints.entrypoint0.observability.metrics=false"
!!! note A router with its own observability configuration will override the global default.
{% include-markdown "includes/ingress-for-business-applications.md" %}