You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Zhou Jiang (Jira)" <ji...@apache.org> on 2022/11/09 00:05:00 UTC

[jira] [Created] (FLINK-29939) Add metrics for Kubernetes Client Response 5xx count and rate

Zhou Jiang created FLINK-29939:
----------------------------------

             Summary: Add metrics for Kubernetes Client Response 5xx count and rate
                 Key: FLINK-29939
                 URL: https://issues.apache.org/jira/browse/FLINK-29939
             Project: Flink
          Issue Type: Improvement
          Components: Kubernetes Operator
    Affects Versions: kubernetes-operator-1.3.0
            Reporter: Zhou Jiang


Operator now publishes k8s client response count by response code. In addition to the accumulative count, adding rate for k8s client error responses could help to setup alerts detect underlying cluster API server status proactively. This is for enhancement of metrics when Flink Operator is deployed to shared / multi-tenant k8s clusters. 

 

Why is rate needed for certain response codes?

To detect issues proactively by setting up alerts in certain cases. It could not the total number but the rate indicates the start / end of unavailability issue.

 

Why do some 4xx matter in prod?

For example - noisy neighbor issue may happen at random time in shared clusters, and operator may start to see increased number of 429 if cluster does not have fairness in rate limiting. Another example is about churn: when the cluster has namespaces quota defined and namespace is under pod churn, there could be increasing number of 409. In these cases, metrics and alerting on count / rate of certain 4xx is critical to understand start / end of prod outage.

 

Why is 5xx needed ?

For faster identify infrastructure issue. With 5xx response count + rate, It's more straightforward than enumerating possible 5xx codes.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)