I’ve spent a few days exploring [Google Fit SDK] as I try to wean myself from my obsession with metrics (of all forms). A quick Googling got me to Robert’s Exporter Google Fit Daily Steps, Weight and Distance to a Google Sheet. This works and is probably where I should have stopped… avoiding the rabbit hole that I’ve been down… I threw together a simple Golang implementation of the SDK using Google’s Golang API Client Library.

I’m obsessing over Prometheus exporters. First came Linode Exporter, then GCP Exporter and, on Sunday, I stumbled upon a reverse-engineered API for Google Home devices and so wrote a very basic Google Home SDK and a similarly basic Google Home Exporter: The SDK only implements /setup/eureka_info and then only some of the returned properties. There’s not a lot of metric-like data to use besides SignalLevel (signal_level) and NoiseLevel (noise_level). I’m not clear on the meaning of some of the properties.

I think (!?) this interesting learning experience started with Envoy Go Extensions. IIUC, Cilium contributed this mechanism (Envoy Go Extensions) by which it’s possible to extend Envoy using Golang. The documentation references BPF. Cilium and BNF were both unfamiliar technologies to me and so began my learning. This part of the journey concludes with Weave Scope. I learned that Cilium is a CNI implementation that may be used with Kubernetes. GKE defaults (but is not limited to) to Google’s own CNI implementation (link).

Earlier this week I discussed a Linode Prometheus Exporter. I added metrics for Digital Ocean’s Managed Kubernetes service to @metalmatze’s Digital Ocean Exporter. This left, metrics for Google Cloud Platform (GCP) which has, for many years, been my primary cloud platform. So, today I wrote Prometheus Exporter for Google Cloud Platform. All 3 of these exporters follow the template laid down by @metalmatze and, because each of these services has a well-written Golang SDK, it’s straightforward to implement an exporter for each of them.

Yesterday I discussed a Linode Prometheus Exporter and tantalized use of Prometheus AlertManager. Success: Configure The process is straightforward although I found the Prometheus (config) documentation slightly unwieldy to navigate :-( The overall process is documented. Here are the steps I took: Configure Prometheus Configure AlertManager Revise Docker Compose Configure Prometheus Added the following to prometheus.yml: rule_files: - "/etc/alertmanager/rules/linode.yml" alerting: alertmanagers: - scheme: http static_configs: - targets: - "alertmanager:9093" Rules must be defined in separate rules files.

I enjoy using Prometheus and have toyed around with it for some time particularly in combination with Kubernetes. I signed up with Linode [referral] compelled by the addition of a managed Kubernetes service called Linode Kubernetes Engine (LKE). I have an anxiety that I’ll inadvertently leave resources running (unused) on a cloud platform. Instead of refreshing the relevant billing page, it struck me that Prometheus may (not yet proven) help.

I’ve written a couple of deployment options (Google Compute Engine; Kubernetes) for an open-source project. The Kubernetes deployment provides NodePort and (TCP) LoadBalancer options and I’ve been trying (unsuccessfully) to add HTTPS Load-balancing. I should (!) try to deploy to Google Kubernetes Engine (GKE) but I’ve been using microk8s, Digital Ocean Managed Kubernetes and the Linode LKE Beta. Each of these requires an implementation of Ingress controller. For GKE, GCP’s HTTP/S Load-balancer (GCLB) is used.

I’ve finally being able to hack my way through to a working Rust gRPC client (for PyPi Transparency). It’s not very good: poorly structured, hacky etc. but it serves the purpose of giving me a foothold into Rust development so that I can evolve it as I learn the language and its practices. There are several Rust crates (SDK) for gRPC. There’s no sanctioned SDK for Rust on grpc.io. I chose stepancheg’s grpc-rust because it’s a pure Rust implementation (not built atop the C implementation).

I’ve been noodling around with another Trillian personality. Another in a theme that interests me in providing tamperproof logs for the packages in the popular package management registries. The Golang team recently announced Go Module Mirror which is built atop Trillian. It seems to me that all the package registries (Go Modules, npm, Maven, NuGet etc.) would benefit from tamperproof logs hosted by a trusted 3rd-party. As you may have guessed, PyPi Transparency is a log for PyPi packages.

cAdvisor has long been a favorite monitoring tool of mine. I’m using Docker Compose for local testing and have begun including a cAdvisor in my docker-compose.yaml files. cadvisor: restart: always image: google/cadvisor:${CADVISOR_VERSION} container_name: cadvisor # command: # - --prometheus_endpoint="/metrics" # Default volumes: - "/:/rootfs:ro" - "/var/run:/var/run:rw" - "/sys:/sys:ro" - "/var/snap/docker/current:/var/lib/docker:ro" #- "/var/lib/docker/:/var/lib/docker:ro" expose: - "8080" ports: - 8080:8080 I’d not realized until recently, that cAdvisor also surfaces a Prometheus metrics endpoint and so, if you do follow this path and you’re also using Prometheus, don’t forget to add cAdvisor to your Prometheus targets.