Vectorizer

Every minute, InfraSage condenses each service's behavior into a compact fingerprint: how busy it is, how it fails, how slow it is, how its logs and traffic look, and the business metrics you care about. Fingerprints are what let InfraSage notice an unusual combination of signals that are each normal on their own (slightly more CPU, slightly more errors, slightly more latency, all at once), and find past incidents that looked like the one in front of you.

Most teams never touch it. The defaults cover the common signals of every service. The Vectorizer page is for telling InfraSage which of your own metrics matter.

Choosing what describes a service

By default every service is described by the same general signals. You can change that per service, in the console (Vectorizer page) or through the API.

Mode	Behavior
auto	InfraSage picks the metrics that tell the most about this service, from its recent history
manual	You choose the metrics
disabled	The service is left out

Auto

Preview what InfraSage would pick for a service before switching it on:

GET /api/v1/embedding/config/payment-service/auto-preview

The response lists the candidate metrics, the ones that would be chosen, and a suggested ceiling for each.

Manual

curl -X PUT https://api.infrasage.dev/api/v1/embedding/config/payment-service \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "manual",
    "slots": [
      { "label": "checkout_errors",  "metrics": ["checkout_error_rate"],   "ceiling": 1 },
      { "label": "payment_latency",  "metrics": ["payment_p99_ms"],        "ceiling": 3000 },
      { "label": "cart_volume",      "metrics": ["cart_events_total"],      "ceiling": 0 }
    ]
  }'

The ceiling is the value you consider the top of the metric's normal range; 0 means "work it out from history".

Business metrics for every service

You can add a few of your own metrics to the fingerprint of every service that has no per-service configuration, for example a cache latency or a checkout success rate that many services influence. Up to 8 by default.

# List current assignments
GET /api/v1/embedding/global-slots

# Add a metric
PUT /api/v1/embedding/global-slots
{
  "slots": [
    { "index": 0, "label": "redis_latency_ms", "metrics": ["redis_cmd_duration_p99"], "ceiling": 500 }
  ]
}

Coverage

GET /api/v1/vectorizer/stats

returns how many services are covered, when the last minute was processed, and how many services have their own configuration.

The Vectorizer page

Vectorizer in the sidebar (operator role required) shows coverage, every service's configuration and mode, and the fleet-wide business metrics. From the configuration dialog you can switch a service's mode and preview what auto would choose.

Troubleshooting

Coverage is 0 or lower than expected. Check that the services are sending telemetry: a service is only described for minutes in which it sent something.

A new service shows nothing unusual for its first half hour. Expected: a service needs some history before its behavior can be called unusual, and new services are marked warming_up meanwhile.

A service always looks unusual. Its normal may have been learned during an incident. Contact support to have that service's history relearned.