@jetrabbits/agentic 0.0.1

package/areas/devops/networking/skills/tls-termination/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: tls-termination
+type: skill
+description: Configure TLS termination with cert-manager — Let's Encrypt, internal CA via Vault PKI, wildcard certs, mTLS between services.
+related-rules:
+  - tls-policy.md
+allowed-tools: Read, Write, Edit, Bash
+---
+
+# Skill: TLS Termination
+
+> **Expertise:** cert-manager ClusterIssuer, Let's Encrypt ACME (HTTP-01 + DNS-01), Vault PKI, cert rotation, mTLS.
+
+## When to load
+
+When setting up TLS for a new service, debugging certificate issuance, rotating certificates, or implementing mTLS.
+
+## cert-manager: Let's Encrypt (HTTP-01)
+
+```yaml
+# ClusterIssuer — Let's Encrypt production
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: letsencrypt-prod
+spec:
+  acme:
+    server: https://acme-v02.api.letsencrypt.org/directory
+    email: ops@example.com
+    privateKeySecretRef:
+      name: letsencrypt-prod-key
+    solvers:
+      - http01:
+          ingress:
+            class: nginx    # must match ingressClassName in Ingress
+
+---
+# Staging issuer (for testing — no rate limits)
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: letsencrypt-staging
+spec:
+  acme:
+    server: https://acme-staging-v02.api.letsencrypt.org/directory
+    email: ops@example.com
+    privateKeySecretRef:
+      name: letsencrypt-staging-key
+    solvers:
+      - http01:
+          ingress:
+            class: nginx
+```
+
+## cert-manager: Let's Encrypt (DNS-01 — for wildcard certs)
+
+```yaml
+# Requires DNS provider API credentials
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: letsencrypt-dns
+spec:
+  acme:
+    server: https://acme-v02.api.letsencrypt.org/directory
+    email: ops@example.com
+    privateKeySecretRef:
+      name: letsencrypt-dns-key
+    solvers:
+      - dns01:
+          cloudflare:
+            email: ops@example.com
+            apiTokenSecretRef:
+              name: cloudflare-api-token
+              key: api-token
+
+---
+# Wildcard certificate
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: wildcard-example-com
+  namespace: production
+spec:
+  secretName: wildcard-example-com-tls
+  issuerRef:
+    name: letsencrypt-dns
+    kind: ClusterIssuer
+  dnsNames:
+    - "*.example.com"
+    - "example.com"
+```
+
+## cert-manager: Internal CA via Vault PKI
+
+```yaml
+# ClusterIssuer backed by HashiCorp Vault
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: vault-pki
+spec:
+  vault:
+    server: https://vault.infra.svc.cluster.local:8200
+    path: pki/sign/internal-services
+    auth:
+      kubernetes:
+        mountPath: /v1/auth/kubernetes
+        role: cert-manager
+        secretRef:
+          name: cert-manager-vault-token
+          key: token
+
+---
+# Internal service certificate (short-lived, auto-rotated)
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: payment-service-tls
+  namespace: production
+spec:
+  secretName: payment-service-tls
+  issuerRef:
+    name: vault-pki
+    kind: ClusterIssuer
+  duration: 24h        # short-lived internal certs
+  renewBefore: 8h      # renew 8h before expiry
+  dnsNames:
+    - payment-service.production.svc.cluster.local
+    - payment-service.production
+```
+
+## Certificate Debugging
+
+```bash
+# Check certificate status
+kubectl get certificate -A
+kubectl describe certificate <name> -n <ns>
+# Look for: Conditions: Ready=True / reason for failure in Events
+
+# Check CertificateRequest and Order (debugging ACME)
+kubectl get certificaterequest -n <ns>
+kubectl describe certificaterequest <n> -n <ns>
+kubectl get order -n <ns>
+kubectl describe order <n> -n <ns>
+
+# Test ACME challenge reachability
+curl -v http://<domain>/.well-known/acme-challenge/test
+
+# Check TLS certificate details
+echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
+  | openssl x509 -noout -text | grep -E "Subject:|DNS:|Not After"
+
+# Check cert expiry for all ingresses
+kubectl get secret -A -o json | jq -r '
+  .items[] | select(.type == "kubernetes.io/tls") |
+  "\(.metadata.namespace)/\(.metadata.name)"' | while read secret; do
+  ns=$(echo $secret | cut -d/ -f1)
+  name=$(echo $secret | cut -d/ -f2)
+  kubectl get secret $name -n $ns -o jsonpath='{.data.tls\.crt}' | \
+    base64 -d | openssl x509 -noout -enddate -subject 2>/dev/null | \
+    awk -v s="$secret" '{print s": "$0}'
+done
+```
+
+## mTLS (service-to-service with cert-manager)
+
+```yaml
+# Each service gets a client cert for mTLS
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: order-service-client-cert
+  namespace: production
+spec:
+  secretName: order-service-client-tls
+  issuerRef:
+    name: vault-pki
+    kind: ClusterIssuer
+  duration: 24h
+  usages:
+    - client auth    # mTLS client usage
+    - digital signature
+  subject:
+    organizations: [mycompany]
+  commonName: order-service.production
+```
+
+```python
+# Python: use client cert for mTLS call to upstream
+import httpx
+
+client = httpx.Client(
+    cert=("/var/run/secrets/tls/tls.crt", "/var/run/secrets/tls/tls.key"),
+    verify="/var/run/secrets/ca/ca.crt",   # internal CA bundle
+)
+response = client.get("https://payment-service.production.svc.cluster.local:8443/charge")
+```

package/areas/devops/networking/skills/vpc-design/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: vpc-design
+type: skill
+description: Design cloud-agnostic private networks — subnet layout, CIDR allocation, zone redundancy, routing, and bare-metal equivalent.
+related-rules:
+  - network-segmentation.md
+allowed-tools: Read, Write, Edit
+---
+
+# Skill: VPC / Network Design
+
+> **Expertise:** CIDR planning, zone-redundant subnets, routing tables, NAT, VPN/peering — AWS, GCP, Hetzner, and bare-metal.
+
+## When to load
+
+When designing a new network for a cloud environment or bare-metal cluster, planning subnets, or diagnosing routing issues.
+
+## CIDR Allocation Strategy
+
+```
+Organization supernet: 10.0.0.0/8
+
+Environment blocks:
+  production:  10.10.0.0/16  (65,534 addresses)
+  staging:     10.20.0.0/16
+  dev:         10.30.0.0/16
+
+Per-environment subnet layout (/16 → four /18 zones):
+  Zone A (eu-west-1a): 10.10.0.0/18   (16,382 IPs)
+    Public subnet:     10.10.0.0/20   (4,094 IPs — load balancers, NAT GW)
+    App subnet:        10.10.16.0/20  (4,094 IPs — K8s nodes)
+    Data subnet:       10.10.32.0/20  (4,094 IPs — databases, Redis)
+
+  Zone B (eu-west-1b): 10.10.64.0/18
+    (same subdivision pattern)
+
+  Zone C (eu-west-1c): 10.10.128.0/18
+    (same subdivision pattern)
+
+  Reserved / Management: 10.10.192.0/18
+    Management subnet: 10.10.192.0/24  (jump hosts, CI runners)
+    Future expansion:  10.10.193.0/18
+```
+
+## Terraform: AWS VPC Module
+
+```hcl
+module "vpc" {
+  source  = "git::https://git.example.com/infra/modules//vpc?ref=v2.1.0"
+
+  project     = var.project
+  environment = var.environment
+  cidr        = "10.10.0.0/16"
+
+  azs              = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
+  public_subnets   = ["10.10.0.0/20",  "10.10.64.0/20",  "10.10.128.0/20"]
+  private_subnets  = ["10.10.16.0/20", "10.10.80.0/20",  "10.10.144.0/20"]
+  database_subnets = ["10.10.32.0/20", "10.10.96.0/20",  "10.10.160.0/20"]
+
+  enable_nat_gateway = true
+  single_nat_gateway = var.environment != "production"  # save cost in non-prod
+
+  # K8s tags (required for AWS Load Balancer Controller)
+  private_subnet_tags = {
+    "kubernetes.io/role/internal-elb" = "1"
+    "kubernetes.io/cluster/${local.cluster_name}" = "owned"
+  }
+  public_subnet_tags = {
+    "kubernetes.io/role/elb" = "1"
+  }
+}
+```
+
+## Terraform: Hetzner Network
+
+```hcl
+resource "hcloud_network" "main" {
+  name     = "${var.project}-${var.environment}"
+  ip_range = "10.10.0.0/16"
+}
+
+resource "hcloud_network_subnet" "k8s_nodes" {
+  network_id   = hcloud_network.main.id
+  type         = "cloud"
+  network_zone = "eu-central"
+  ip_range     = "10.10.16.0/20"
+}
+
+resource "hcloud_network_subnet" "databases" {
+  network_id   = hcloud_network.main.id
+  type         = "cloud"
+  network_zone = "eu-central"
+  ip_range     = "10.10.32.0/20"
+}
+
+# Attach servers to subnets
+resource "hcloud_server_network" "worker" {
+  for_each  = var.worker_servers
+  server_id = each.value.id
+  network_id = hcloud_network.main.id
+  ip         = each.value.private_ip
+}
+```
+
+## Bare-Metal Network Design
+
+```
+Physical topology:
+  - 2× top-of-rack switches (bonded for HA)
+  - Each server: 2× 10GbE NICs (bonded: active-backup or LACP)
+
+VLAN layout:
+  VLAN 10 (management): 192.168.10.0/24  — IPMI, switch mgmt
+  VLAN 20 (K8s nodes):  10.10.16.0/20   — kubelet, pod CIDR routed
+  VLAN 30 (storage):    10.10.32.0/24   — Longhorn/Ceph replication
+  VLAN 40 (public):     203.0.113.0/28  — load balancer IPs (MetalLB pool)
+
+Routing:
+  - Default GW on VLAN 20 → firewall → internet (via NAT for egress)
+  - VLAN 30 (storage) — no routing outside rack (isolated L2)
+  - VLAN 40 — router sends public IPs to MetalLB L2 advertisement
+```
+
+## Network Security Design Checklist
+
+- [ ] Data subnets have no route to internet (no NAT GW for DB subnet)
+- [ ] Management access via VPN or jump host only (no public SSH)
+- [ ] NAT Gateway in each AZ (not single NAT — single point of failure)
+- [ ] VPC Flow Logs enabled (30-day retention)
+- [ ] Security groups default-deny; rules documented with justification
+- [ ] Subnet CIDR does not overlap with on-prem or peered VPCs
+- [ ] IPv6 considered (especially for K8s pod addressing at scale)

package/areas/devops/networking/workflows/onboard-ingress.md

@@ -0,0 +1,64 @@
+---
+name: onboard-ingress
+type: workflow
+trigger: /onboard-ingress
+description: Expose a Kubernetes service externally — Ingress, TLS, rate limiting, MetalLB (bare-metal).
+inputs:
+  - service_name
+  - hostname
+  - tls_source (letsencrypt|internal-ca|manual)
+outputs:
+  - ingress_resource
+  - tls_certificate_issued
+  - service_accessible
+roles:
+  - devops-engineer
+execution:
+  initiator: developer
+related-rules:
+  - ingress-standards.md
+  - tls-policy.md
+uses-skills:
+  - ingress-patterns
+  - tls-termination
+quality-gates:
+  - TLS certificate issued (not just pending)
+  - HTTPS accessible; HTTP redirects
+  - Rate limiting verified with load test
+---
+
+## Steps
+
+### 1. Write Ingress Manifest — `@devops-engineer`
+- Include all mandatory annotations (ssl-redirect, rate-limit, security headers, timeouts)
+- Set cert-manager annotation matching chosen issuer
+- **Done when:** `kubectl apply --dry-run=server` passes
+
+### 2. Apply & Wait for Certificate — `@devops-engineer`
+```bash
+kubectl apply -f ingress.yaml
+# Watch certificate issuance (Let's Encrypt: up to 2 min; internal CA: < 30s)
+kubectl get certificate -n <ns> -w
+kubectl describe certificate <cert-name> -n <ns>   # check events if stuck
+```
+
+### 3. Verify HTTPS — `@devops-engineer`
+```bash
+curl -v https://<hostname>/health
+# Check: TLS version, cipher, cert expiry, HSTS header
+```
+
+### 4. Verify Rate Limiting — `@devops-engineer`
+```bash
+# Quick rate limit test (expect 429 after N requests)
+for i in $(seq 1 200); do
+  curl -s -o /dev/null -w "%{http_code}\n" https://<hostname>/health
+done | sort | uniq -c
+```
+
+### 5. DNS (if needed) — `@devops-engineer`
+- Point hostname to MetalLB external IP: `kubectl get svc -n ingress-nginx`
+- Add A record in DNS provider or internal CoreDNS
+
+## Exit
+HTTPS accessible + cert issued + security headers present + rate limit verified = ingress onboarded.

package/areas/devops/networking/workflows/service-mesh-onboard.md

@@ -0,0 +1,122 @@
+---
+name: service-mesh-onboard
+type: workflow
+trigger: /service-mesh-onboard
+description: Onboard a service to Linkerd or Istio service mesh — inject sidecar, validate mTLS, configure retry/timeout policies.
+inputs:
+  - service_name
+  - namespace
+  - mesh (linkerd|istio)
+outputs:
+  - service_meshed
+  - mtls_verified
+  - policies_applied
+roles:
+  - devops-engineer
+execution:
+  initiator: developer
+related-rules:
+  - network-segmentation.md
+  - tls-policy.md
+uses-skills:
+  - service-mesh
+  - ingress-patterns
+quality-gates:
+  - mTLS verified between service and at least one upstream/downstream
+  - no plaintext traffic visible in mesh telemetry
+  - retry/timeout policy applied for critical paths
+---
+
+## Steps
+
+### 1. Pre-Check Mesh Health — `@devops-engineer`
+```bash
+# Linkerd
+linkerd check
+linkerd viz stat ns/default   # verify mesh is processing traffic
+
+# Istio
+istioctl check-inject -n ${NAMESPACE}
+istioctl analyze -n ${NAMESPACE}
+```
+- **Done when:** mesh healthy with no data plane issues
+
+### 2. Enable Injection — `@devops-engineer`
+```bash
+# Linkerd: annotate namespace (all new pods get sidecar)
+kubectl annotate namespace ${NAMESPACE} linkerd.io/inject=enabled
+
+# Istio: label namespace
+kubectl label namespace ${NAMESPACE} istio-injection=enabled
+
+# Restart pods to inject sidecar into existing pods
+kubectl rollout restart deployment/${SERVICE} -n ${NAMESPACE}
+```
+- **Done when:** `kubectl get pods -n ${NAMESPACE}` shows 2/2 (or 3/3 for Istio) containers
+
+### 3. Verify mTLS — `@devops-engineer`
+```bash
+# Linkerd: check edges (shows whether traffic is mTLS)
+linkerd viz edges deployment/${SERVICE} -n ${NAMESPACE}
+# Look for: SECURED column = true
+
+linkerd viz tap deployment/${SERVICE} -n ${NAMESPACE} \
+  | grep -E "tls|secure"
+
+# Istio: verify PeerAuthentication is enforced
+kubectl get peerauthentication -n ${NAMESPACE}
+# If no PeerAuthentication: all traffic still accepted (PERMISSIVE)
+# Apply STRICT mode after all services in namespace are meshed:
+kubectl apply -f - << 'YAML'
+apiVersion: security.istio.io/v1beta1
+kind: PeerAuthentication
+metadata:
+  name: default
+  namespace: ${NAMESPACE}
+spec:
+  mtls:
+    mode: STRICT
+YAML
+```
+- **Done when:** `linkerd viz edges` shows SECURED=true or Istio PeerAuthentication=STRICT
+
+### 4. Apply Traffic Policies — `@devops-engineer`
+```bash
+# Linkerd ServiceProfile: retries + timeouts
+kubectl apply -f - << 'YAML'
+apiVersion: linkerd.io/v1alpha2
+kind: ServiceProfile
+metadata:
+  name: ${SERVICE}.${NAMESPACE}.svc.cluster.local
+  namespace: ${NAMESPACE}
+spec:
+  routes:
+    - name: POST /api/orders
+      condition:
+        method: POST
+        pathRegex: /api/orders
+      timeout: 10s
+      retryBudget:
+        retryRatio: 0.2
+        minRetriesPerSecond: 5
+        ttl: 10s
+YAML
+```
+
+### 5. Validate in Mesh Dashboard — `@devops-engineer`
+```bash
+# Linkerd: open viz dashboard
+linkerd viz dashboard &
+
+# Check for:
+# - Success rate > 99% on meshed routes
+# - Latency histograms visible
+# - No "naked" (unmeshed) traffic sources reaching the service
+
+# Istio: check Kiali or Grafana Istio dashboards
+kubectl -n istio-system port-forward svc/kiali 20001:20001 &
+```
+- **Done when:** service visible in mesh dashboard; no unmeshed traffic warnings
+
+## Exit
+Sidecar injected + mTLS verified + policies applied + dashboard shows service = onboarded.

package/areas/devops/observability/AGENTS.md

@@ -0,0 +1,48 @@
+# Observability — guidance index
+
+## What this area covers
+
+Platform observability: Prometheus metrics and Alertmanager rules, Loki log aggregation, Tempo distributed tracing, Grafana dashboards, SLO implementation, and service monitoring onboarding.
+
+## Guidance chain
+
+1. Project `.agent/` baseline
+2. `observability/rules/*` — load all
+3. `observability/skills/*/SKILL.md` — load only the skill matching the current task
+4. `observability/workflows/*` — load the workflow matching the triggered command
+
+## Cross-cutting constraints
+
+- **Golden signals first** — every new service exposes latency, traffic, errors, and saturation before any custom metrics.
+- **Alert on symptoms, not causes** — page on user-facing impact; use dashboards for internal diagnosis.
+- **Data retention is policy, not default** — all retention periods must be explicitly configured and justified.
+- **No alert without runbook** — every firing alert must link to a documented investigation path.
+
+## Spec map
+
+```text
+observability/
+├── rules/
+│   ├── golden-signals.md        ← required metrics per service, naming conventions
+│   ├── alerting-standards.md    ← severity levels, routing, inhibition, runbook requirement
+│   └── data-retention.md        ← retention tiers, cost caps, compliance minimums
+├── skills/
+│   ├── prometheus-alertmanager/SKILL.md  ← PromQL, recording rules, alert routing
+│   ├── grafana-dashboards/SKILL.md       ← dashboard-as-code, variable design, panels
+│   ├── log-aggregation/SKILL.md          ← LogQL, structured logging, label design
+│   ├── distributed-tracing/SKILL.md      ← trace propagation, sampling, span attributes
+│   └── slo-implementation/SKILL.md       ← burn-rate alerts, error budget dashboards
+├── workflows/
+│   ├── observability-stack-setup.md       ← /observability-stack-setup
+│   ├── onboard-service-monitoring.md      ← /onboard-service-monitoring
+│   └── alert-investigation.md             ← /alert-investigation
+└── prompts/
+    └── *.md
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`
+- `prompts/*.md`

package/areas/devops/observability/prompts/alert-investigation.md

@@ -0,0 +1,117 @@
+---
+workflow: alert-investigation
+---
+
+# Prompt: `/alert-investigation`
+
+Use when: investigating a firing alert, burn-rate anomaly, or correlated trace/log signal to determine root cause and mitigation.
+
+---
+
+## Example 1 — HighErrorRate firing in production
+
+**EN:**
+```
+/alert-investigation
+
+Alert: HighErrorRate / Service: payment-service / Namespace: production
+Fired at: 2024-11-15 03:42 UTC / Current error rate: 4.2% (threshold: 1%)
+Error type: HTTP 502 (Bad Gateway from upstream)
+Available data:
+  - Prometheus: http_requests_total labels available
+  - Logs: Loki, JSON structured, trace_id present
+  - Traces: Tempo available
+  - Recent changes: payment-service v2.4.1 deployed 20 min ago
+Investigation steps:
+  1. Identify which endpoint(s) are erroring (PromQL breakdown by path)
+  2. Correlate with deployment time
+  3. Check logs for upstream call errors (trace_id → Tempo for full trace)
+  4. Determine: rollback v2.4.0 or hotfix?
+```
+
+**RU:**
+```
+/alert-investigation
+
+Алерт: HighErrorRate / Сервис: payment-service / Namespace: production
+Сработал: 2024-11-15 03:42 UTC / Текущий error rate: 4.2% (порог: 1%)
+Тип ошибок: HTTP 502 (Bad Gateway от upstream)
+Доступные данные:
+  - Prometheus: метрики http_requests_total с labels
+  - Логи: Loki, JSON, trace_id присутствует
+  - Трейсы: Tempo доступен
+  - Последние изменения: payment-service v2.4.1 задеплоен 20 мин назад
+Шаги расследования:
+  1. Определить какие endpoint(ы) ошибаются (PromQL разбивка по path)
+  2. Сопоставить со временем деплоя
+  3. Проверить логи на ошибки вызова upstream (trace_id → Tempo для полного трейса)
+  4. Решить: откатить до v2.4.0 или сделать hotfix?
+```
+
+---
+
+## Example 2 — Alert fatigue investigation (too many false positives)
+
+**EN:**
+```
+/alert-investigation
+
+Problem: PodMemoryPressure alert fires 8-12 times per week for ml-worker pods but engineers stop acting on it
+Current threshold: memory > 85% for 5m
+Context: ml-worker has bursty memory usage (spikes to 90% during batch, then drops)
+Goal: reduce false positive rate without missing real OOM risk
+Analysis needed:
+  1. Query actual OOMKill events in last 30 days (kube_pod_container_status_last_terminated_reason)
+  2. Correlate memory spike timing with batch job schedule
+  3. Propose new threshold or alerting strategy (e.g. rate-of-change instead of absolute)
+  4. Update PrometheusRule + runbook
+```
+
+**RU:**
+```
+/alert-investigation
+
+Проблема: алерт PodMemoryPressure срабатывает 8-12 раз в неделю для ml-worker подов, но инженеры перестали реагировать
+Текущий порог: memory > 85% в течение 5м
+Контекст: ml-worker имеет взрывное использование памяти (пики до 90% во время batch, потом падает)
+Цель: снизить число false positive без пропуска реального риска OOM
+Необходимый анализ:
+  1. Запросить реальные события OOMKill за последние 30 дней (kube_pod_container_status_last_terminated_reason)
+  2. Сопоставить время пиков памяти с расписанием batch job
+  3. Предложить новый порог или стратегию алертинга (например, rate-of-change вместо абсолютного значения)
+  4. Обновить PrometheusRule + runbook
+```
+
+---
+
+## Example 3 — Trace slow checkout (multi-service waterfall)
+
+**EN:**
+```
+/alert-investigation
+
+Symptom: checkout p99 latency = 3.2s; SLO threshold = 500ms
+Trace available: trace_id=abc123def456 (found in Loki error log, captured during slow request)
+Services in trace: api-gateway → checkout-service → payment-service → order-service → postgres
+Goal:
+  1. Open trace in Tempo; identify which span is slow
+  2. Check for: sequential calls that could be parallelised, N+1 DB queries, missing DB indexes
+  3. If DB span is slow: correlate with postgres slow query log (Loki query by trace_id)
+  4. Output: root cause span + recommended fix (code change or index)
+Tempo URL: https://tempo.monitoring.internal
+```
+
+**RU:**
+```
+/alert-investigation
+
+Симптом: checkout p99 latency = 3.2s; порог SLO = 500ms
+Трейс доступен: trace_id=abc123def456 (найден в Loki error log, захвачен во время медленного запроса)
+Сервисы в трейсе: api-gateway → checkout-service → payment-service → order-service → postgres
+Цель:
+  1. Открыть трейс в Tempo; определить какой span медленный
+  2. Проверить: последовательные вызовы которые можно распараллелить, N+1 DB запросы, отсутствующие индексы
+  3. Если медленный DB span: сопоставить с postgres slow query log (запрос Loki по trace_id)
+  4. Результат: корневой медленный span + рекомендуемое исправление (изменение кода или индекс)
+Tempo URL: https://tempo.monitoring.internal
+```