Polycrate API 0.11.17

Release-Datum: 20. Januar 2026
Typ: Debugging & Bugfix

Highlights

🔍 Timeline Chart Debugging - Verbesserte Diagnose für leere Timeline-Charts
🔧 Parse-Error-Tracking - Sichtbare Zählung von Parsing-Fehlern
📊 RAW Response Speicherung - Debug-Daten im Django Admin für Analyse
🕐 Timezone-Fix - UTC-Timezone für LoadBalancer Timeline

Artefakte

Docker Images

docker pull cargo.ayedo.cloud/polycrate/polycrate-api:0.11.17

Installation

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-api
polycrate run polycrate-api install

Problem: Leere Timeline Charts

In 0.11.16 wurde beobachtet, dass die Timeline-Charts in S3 Bucket Detail und LoadBalancer Instance Detail keine Daten anzeigen, obwohl die aggregierten Werte (Average, Max, Current) korrekt berechnet werden.

Symptom im Django Admin / Browser Console:

{
  "storage": {
    "1h_average": 11916034689.076923,  // ✅ Korrekt
    "1h_max": 12078286911.0             // ✅ Korrekt
  },
  "storage_timeline": {
    "1h": [],   // ❌ Leer!
    "24h": [],
    "30d": []
  }
}

Das Paradox: _calculate_average_from_metrics() funktioniert mit derselben Response, aber _extract_storage_timeline() liefert eine leere Liste.

Implementierte Debugging-Features

1. Konsistentes Tuple-Unpacking

Die Timeline-Extraktion verwendet jetzt exakt dieselbe Syntax wie die funktionierende _calculate_average_from_metrics():

# Bewährte Syntax (wie in _calculate_average_from_metrics)
for timestamp_raw, value_str in result["values"]:
    timestamp = int(float(timestamp_raw))
    value = float(value_str)

2. Parse-Error-Zählung

Fehler beim Parsing werden jetzt gezählt und geloggt:

Timeline extraction: 0/13 parse errors
Timeline extraction: 13 data points from 13 values

Bei Fehlern erscheint eine Warning:

Timeline extraction: 5/13 parse errors

3. RAW Response Speicherung

Wenn die Timeline leer ist aber Average > 0, wird die RAW VictoriaMetrics Response gespeichert:

{
  "queries": {
    "1h": {
      "debug_response_sample": [
        {
          "metric": {},
          "values_sample": [[1737363600, "12078286911"], ...],
          "values_count": 13
        }
      ]
    }
  }
}

So prüfen Sie die Debug-Daten:

S3 Bucket/LoadBalancer im Django Admin öffnen
metrics_data Feld inspizieren
queries.1h.debug_response_sample enthält die ersten 5 Werte der Response

Bugfixes

UTC-Timezone für LoadBalancer Timeline

Die datetime.fromtimestamp() Konvertierung nutzt jetzt explizit UTC-Timezone für Konsistenz:

# Vorher (lokale Timezone)
datetime.datetime.fromtimestamp(timestamp).isoformat()

# Nachher (explizit UTC)
datetime.datetime.fromtimestamp(timestamp, tz=django_timezone.utc).isoformat()

Debugging nach Deploy

1. Objekt reconcilen

Klicken Sie den Reconcile Button auf dem S3 Bucket oder LoadBalancer.

2. Logs prüfen

grep -E "Timeline|parse errors" <logs>

Erwartete Ausgabe bei Erfolg:

Timeline extraction: 13 data points from 13 values
Period 1h: storage=12078286911 bytes, objects=5468, timeline_points=13

Ausgabe bei leerem Timeline:

Period 1h: Timeline empty but average=11916034689! Storing raw response for debugging.

3. Django Admin prüfen

Öffnen Sie das Objekt im Admin und prüfen Sie metrics_data.queries.1h.debug_response_sample.

Changelog

Datei	Änderung
`src/s3/models.py`	`_extract_storage_timeline()` - Konsistentes Tuple-Unpacking, Error-Counting
`src/s3/models.py`	`_fetch_metrics_data()` - Debug-Response bei leerem Timeline
`src/loadbalancers/models.py`	`_extract_bandwidth_timeline()` - Error-Counting, UTC-Timezone

Migration

Keine Datenbank-Migration erforderlich.

Nach Deploy: S3 Buckets und LoadBalancer reconcilen um die verbesserte Timeline-Extraktion zu nutzen.

Block-Version

# block.poly
name: cargo.ayedo.cloud/ayedo/k8s/polycrate-api
version: 0.5.21
app_version: "0.11.17"

Spezifikationen

Die detaillierten Implementierungs-Spezifikationen finden sich in .specs/0.11.17/:

index.md - Übersicht
timeline-chart-debugging.md - Detaillierte Analyse und Lösung