microservices

kong latency

techhadoop , ,

Short answer: there isn’t a single built-in “average response time” value for Kong. You measure it from Kong’s latency telemetry and then compute the average. Kong exposes three latencies:

  • Request latency (a.k.a. total): time from first byte in to last byte out.
  • Upstream latency: time the upstream took to start responding.
  • Kong latency: time spent inside Kong (routing + plugins). (Kong Docs)

Below are the quickest ways to get the average.

Option 1 — Prometheus plugin (fastest for averages/percentiles)

Enable the Prometheus plugin with config.latency_metrics=true. It exposes histograms:

  • kong_request_latency_ms_* (total)
  • kong_upstream_latency_ms_*
  • kong_kong_latency_ms_* (Kong Docs)

PromQL examples (last 5 minutes):

# Average total response time
sum(rate(kong_request_latency_ms_sum[5m]))
/
sum(rate(kong_request_latency_ms_count[5m]))

# Average per service
sum by (service) (rate(kong_request_latency_ms_sum[5m]))
/
sum by (service) (rate(kong_request_latency_ms_count[5m]))

# p95 latency (total)
histogram_quantile(
  0.95,
  sum by (le) (rate(kong_request_latency_ms_bucket[5m]))
)

Swap request for upstream or kong in the metric names to break the average down by where time is spent. (Kong Docs)

Option 2 — ELK/Kibana (since you’re using ELK)

Use a log plugin (e.g., File Log or HTTP Log) and ship the JSON to Elasticsearch. Each log line contains:

"latencies": {
  "request": <total_ms>,
  "proxy":   <upstream_ms>,
  "kong":    <kong_ms>
}

In Kibana → Discover/Lens, set Average over latencies.request (or latencies.proxy / latencies.kong) to see the mean response time. (Kong Docs)

Option 3 — Quick curl check (headers)

Kong can add latency headers:

  • X-Kong-Proxy-Latency (≈ Kong time)
  • X-Kong-Upstream-Latency (≈ upstream time)
  • X-Kong-Total-Latency (total; with advanced tokens)

Enable with KONG_HEADERS=latency_tokens (or advanced_latency_tokens) and inspect with curl -i. (Kong Docs)

What’s a “good” number?

It’s workload-specific. Treat Kong latency as your gateway overhead (aim for low single-digit ms) and focus tuning on upstream latency (usually the dominant share). Use p95/p99 alongside the average to catch tail latency. (Kong Docs)

If you want, I can drop a Grafana panel (PromQL prewired) and a Kibana Lens example targeting latencies.request so you can paste them into your stack.

Kong – no suitable authorization credentials were provided

techhadoop , , ,

The error “no suitable authorization credentials were provided” usually means Kong (or an upstream service) expected authentication information, but it either:

  • Didn’t receive it at all
  • Received it in the wrong format
  • Received it in the wrong location (header vs. query parameter)
  • Couldn’t match it to any configured credentials

Here’s how to troubleshoot it step-by-step:

1. Identify which plugin or service is throwing the error

  • Kong Plugin Layer – Often caused by key-auth, jwt, or openid-connect plugin when no valid credential is passed.
  • Upstream Service Layer – Could be from the API/backend if Kong passed the request without credentials.
  • Load Balancer / F5 – Sometimes strips or alters headers, so credentials never reach Kong.

2. Check the authentication type you’re using

  • API Key (key-auth plugin)
    • Expected: apikey in ?query or apikey in header (apikey: <key>).
    • Verify: curl -H "apikey: YOUR_API_KEY" https://your-kong-endpoint/your-api
  • JWT Plugin
    • Expected: Authorization: Bearer <jwt_token> header.
    • Token must be valid and match a configured consumer.
  • OpenID Connect (openid-connect plugin)
    • Expected: Valid ID/Access token, usually Authorization: Bearer <access_token>.
    • Token must be signed by a trusted issuer in plugin config.

3. Verify headers are not stripped

If you have F5 / Nginx / Apache in front of Kong:

  • Check that Authorization headers are forwarded.
  • In F5, enable HTTP::header Authorization forwarding.
  • In Nginx, ensure: proxy_set_header Authorization $http_authorization;

4. Check Kong logs for details

Run Kong in debug mode temporarily:

KONG_LOG_LEVEL=debug kong restart
tail -f /usr/local/kong/logs/error.log

Look for:

  • plugin=... lines showing missing credentials
  • no credentials found for given consumer/issuer

5. Confirm consumer mapping

For jwt or oidc:

  • The public key / JWKS URL must be correct.
  • The iss (issuer) in token must match plugin config.
  • The consumer must be linked to the credential.

💡 Common causes I’ve seen in your past scenarios with F5 + Kong + Ping Identity:

  • F5 stripping Authorization header before reaching Kong.
  • Wrong token type (ID token instead of Access token) in OIDC flow.
  • Consumer not mapped in Kong for the provided JWT/OIDC token.
  • client_id and client_secret missing in a token request.

If you want, I can draw you a flow diagram for Kong + Ping Identity showing exactly where the credential might be getting lost in your setup with F5 in the middle. That would make pinpointing the issue much faster.

Kong error

techhadoop , , ,

The error:

no credentials found for given iss

in the Kong OIDC plugin means:

Kong received a token or request with an issuer (iss) claim, but it cannot find a matching configuration for that issuer.

🔍 Why This Happens

This usually occurs in one of these scenarios:

1. Missing or Incorrect config.issuer in the OIDC plugin

  • You did not set the exact issuer URL from Ping Identity in the plugin config.
  • Or you set it, but it’s spelled or formatted differently than what’s in the JWT’s iss claim.

Example:
If the token contains:

"iss": "https://auth.pingone.com/12345/as"

Then your OIDC plugin must be configured with:

config.issuer=https://auth.pingone.com/12345/as

2. Wrong Discovery Document

Kong uses the issuer to retrieve:

<issuer>/.well-known/openid-configuration

If the URL is incorrect or inaccessible, it can’t discover metadata and fails.

3. Token Issuer Doesn’t Match Plugin Config

  • You’re sending a JWT token manually (e.g., in Authorization: Bearer) and it’s not issued by the issuer you configured.
  • Kong expects the iss claim to match the config.issuer.

✅ Fix Steps

Step 1: Extract the Token’s Issuer

Run:

jwt decode <your-token>

Or paste the JWT into jwt.io and check the iss field.

Step 2: Update Plugin Config

Ensure the OIDC plugin config matches the exact iss value:

curl -X PATCH http://localhost:8001/plugins/<plugin-id> \
  --data "config.issuer=https://auth.pingone.com/12345/as"

Or if creating fresh:

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=openid-connect" \
  --data "config.issuer=https://auth.pingone.com/12345/as" \
  ...

🧪 Test Again

Once updated:

  1. Clear browser session or test in Postman
  2. Trigger the login flow again
  3. Ensure Kong receives a token from Ping with matching iss

Would you like help decoding the token or verifying your current plugin setup? You can paste the token header (without the signature) and I’ll check it.