The purpose of the assessment is to help determine a candidates capabilities in the following areas: Cloud-native ecosystem, Software development practices and capabilities, SDK ingestion, API interaction. To test these areas we will ask a candidate to participate in either a “take-home” or working session assessment. The take-home, would allow them to complete the assessment on their own time, with their own tools. The working session would be 1 1/2 hours, working with a Kasten engineer, to address the same assessment. This allows the candidate flexibility, but still allows the Kasten team to perceive a candidates capabilities.
Task: Build an application to expose metrics, from a Kubernetes cluster, using the Prometheus SDK.
Prometheus is a metric and alerting open source solution. You can use Prometheus to capture metrics from many different sources and coalesce them together. Unlike an agent based monitoring solution, Prometheus does not live where you want to pull metrics from. You run a Prometheus server to “scrape” different endpoints that are using the Prometheus Exposition Format. These endpoints are web services that are accessible over HTTP protocols. This allows Prometheus to extract data while maintaining a minimal footprint, and allows the developer to use the tools of their choice to expose these metrics.
This is what we will be doing for this assessment. Using the Prometheus SDK (a.k.a. Client Libraries). This documentation will help guide you to use a client library that produces an HTTP endpoint in the Prometheus Exposition Format. You will be collecting metrics from a Kubernetes cluster that is already running (information to this cluster will be provided). You will be able to “scrape” your own endpoint either through navigating to it via a web browser, or using a tool such as cURL.
The first metric to gather is the number of pods running in the cluster. This is a Gauge Prometheus primitive, and should be simple to collect using the Kubernetes API.
The next metric to gather will be a Prometheus Counter primitive. A counter is used to represent a monotonically increasing number. The counter for this assessment will be the number of times an endpoint of the application is accessed. This endpoint can be specific for this counter, or it can be the endpoint that the metrics will be exposed on. This endpoint needs to store the counter value in memory or to a file, this can be volatile; it can be reset when the application restarts.
All metrics gathered must be presented and exposed on the /metrics path. Accessing this path will provide the metrics in the Prometheus Exposition Format.
Please refer to the documentation found here, Access Cluster API. TOKEN and APISERVER will be provided for you to access a Kubernetes cluster. Then reference Using the API Server and API Concepts to understand the API paths.
run a local Prometheus server and scrape your /metrics endpoint. Finally, view the metrics you’ve exposed using the Prometheus expression browser, which is available via /graph on the Prometheus server.
Respond to the Kasten team with a link to a repository where your work can be seen. We can provide a repository for you if needed. Thank you for taking the time to work on this assessment and for your interest in joining the Kasten team!