Obserwowalność aplikacji

Dostępność

API obserwowalności jest częściowo zaimplementowane. Dziś przydatne są dwa źródła danych:

append-only, ręcznie uzupełniana oś czasu zdarzeń; oraz
bieżąca alokacja zasobów VM raportowana przez libvirt.

Poniższe elementy to wyłącznie podglądy kontraktu:

request analytics zwraca pustą listę rollup, bo ingestion logów dostępu nie działa;
konfiguracja uptime-probe jest zapisywana, ale żaden scheduler nie wykonuje kontroli HTTP;
próbki zasobów są puste, bo sampler nie działa; oraz
strumieniowanie logów aplikacji nie jest zaimplementowane.

Nie ma gotowego panelu obserwowalności. Zapisana konfiguracja probe nie dowodzi, że endpoint został sprawdzony.

Obecna powierzchnia REST

Trasy leżą pod /api/app-gateway.

Method	Path	Co to dziś potwierdza
`GET`	`/analytics/{slug}?days=7`	Kontrakt jest osiągalny; oczekuje się pustego `rollups`.
`PUT`	`/probes/{slug}`	Konfiguracja probe została zwalidowana i zapisana.
`GET`	`/probes/{slug}`	Zapisaną konfigurację można odczytać. Status runtime pozostaje unset.
`DELETE`	`/probes/{slug}`	Zapisana konfiguracja została usunięta.
`POST`	`/events/{slug}`	Zdarzenie dostarczone przez wywołującego zostało dopisane.
`GET`	`/events/{slug}?limit=100`	Zapisane zdarzenia można czytać od najnowszych.
`GET`	`/metrics/{slug}?vm_name={name}`	Można zwrócić bieżącą alokację; `samples` jest puste.

Konfiguracja probe


PUT /api/app-gateway/probes/my-app
Content-Type: application/json
 
{
  "path": "/healthz",
  "interval_s": 60,
  "expected_status": 200,
  "timeout_s": 5,
  "enabled": true
}

Odczyt wygląda obecnie tak:


{
  "config": {
    "path": "/healthz",
    "interval_s": 60,
    "expected_status": 200,
    "timeout_s": 5,
    "enabled": true
  },
  "last_run_at": null,
  "last_status": null,
  "last_http_status": null,
  "consecutive_failures": 0
}

Pola runtime z wartością null to ważny sygnał: żadna kontrola nie została uruchomiona. Do alertów dostępności używaj zewnętrznego monitora, dopóki scheduler nie zostanie wdrożony.

Zdarzenia

Zdarzenia to trwałe wpisy zapisywane przez API, a nie automatycznie kompletny audit trail. Hooki deployment, checkpoint, domain i walker są nadal w toku, więc wywołujący nie powinni zakładać, że te aktywności pojawią się bez jawnego append.

Traktuj metadane zdarzeń jako dane dostarczone przez wywołującego. Nie umieszczaj w nich secretów.

Alokacja zasobów

Trasa metrics może raportować przypisane vCPU, pamięć i dyski, gdy libvirt udostępnia pasującą VM. Nie raportuje jeszcze szeregu czasowego ani health na poziomie aplikacji. Alokacja to konfiguracja pojemności, a nie dowód, że aplikacja wykorzystała lub przetrwała tę pojemność.

Wskazówki operacyjne

Dopóki ingestion i pętle worker nie są wdrożone:

używaj zewnętrznego monitora HTTP do uptime;
zbieraj logi aplikacji mechanizmem zarządzanym przez operatora;
używaj libvirt lub telemetrii hosta do rzeczywistego wykorzystania; oraz
dołączaj znaczniki czasu i dowody źródłowe do rekordów incydentów zamiast polegać wyłącznie na podglądowej liście zdarzeń.

Funkcję można przedstawiać jako gotową dopiero po przejściu przez testy awarii i odzyskiwania end-to-end przez restart-safe workerów ingest, probe, sampling i log-stream.