https://github.com/wavefronthq/wavefront-kubernetes
Kubernetes definitions and templates for Wavefront
https://github.com/wavefronthq/wavefront-kubernetes
kubernetes monitoring wavefront
Last synced: 3 months ago
JSON representation
Kubernetes definitions and templates for Wavefront
- Host: GitHub
- URL: https://github.com/wavefronthq/wavefront-kubernetes
- Owner: wavefrontHQ
- License: apache-2.0
- Created: 2018-06-27T19:24:36.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2023-10-25T10:43:07.000Z (over 2 years ago)
- Last Synced: 2025-04-11T05:07:14.647Z (about 1 year ago)
- Topics: kubernetes, monitoring, wavefront
- Language: HCL
- Homepage:
- Size: 74.2 KB
- Stars: 9
- Watchers: 27
- Forks: 8
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# wavefront-kubernetes
This repository contains definitions and templates for monitoring Kubernetes using Wavefront.
## Wavefront Proxy (required)
1. Deploy a [Wavefront Proxy](wavefront-proxy/)
- Update `YOUR_CLUSTER` and `YOUR_API_TOKEN` according to your instance of Wavefront
## Kubernetes system metrics
Refer to the [Wavefront Kubernetes Integration](https://docs.wavefront.com/kubernetes.html) for core Kubernetes monitoring.
## Pod monitoring
### Config Map
Config Maps allow for easy management and standardization of monitoring configuration and settings for any application and service.
Some sample config maps are provided, and can be expanded upon. The sample deployment definitions for monitoring will reference these
config maps, which are all Telegraf plugin configuration snippets.
Sample [Telegraf Config Maps](telegraf-config-maps/)
### Usage: Sidecar container
Use the [Telegraf Sidecar container template](telegraf-sidecar/) to add Telegraf as a sidecar to your existing pod definitions
- Change references to `APPLICATION` to match your application name
- Optionally update the `METRIC_SOURCE_NAME` environment variable to specify a metric source (default is to use Node name)
- Update the config map reference to match the approrpriate deployed config map
- `:alpine` tag for the image can also be used (other version tags also supported)
### Usage: Standalone pod
When sidecar monitoring is not practical, use the standard [Telegraf Deployment template](telegraf/) to monitor the service.
Prometheus endpoints can be scraped using this method.
- Change references to `APPLICATION` to match your application name
- Optionally update the `METRIC_SOURCE_NAME` environment variable to specify a metric source (default is to use Node name)
- Update the config map reference to match the approrpriate deployed config map
- `:alpine` tag for the image can also be used (other version tags also supported)
### Usage: Prometheus scraping over a Kubernetes service
You may have want to monitor all individual endpoints (pods) associated with a given Kubernetes service that emit Prometheus metrics.
Because the name, and number of endpoints can change this needs to be dynamic. The Telegraf Prometheus plugin, can be used in this situation
with the following configuration setup.
- Create a new [Headless service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) in Kubernetes where you expose your Prometheus http-metrics port
- `clusterIP` needs to be set to `None`
- `type` should not be specified
- make sure your service selector will select the required pods
- you only need to expose the Prometheus http-metrics port to be scraped
Sample service definition:
```yaml
kind: Service
apiVersion: v1
metadata:
name: my-service-metrics
spec:
selector:
app: MyApp
clusterIp: None
ports:
- name: http-metrics
port: 8080
```