Yet another cloud platform exporter for resource|cost management. This time for Koyeb with Koyeb Exporter.

Deploying resources to cloud platforms generally incurs cost based on the number of resources deployed, the time each resource is deployed and the cost (per period of time) that the resource is deployed. It is useful to be able to automatically measure and alert on all the resources deployed on all the platforms that you’re using and this is an intent of these exporters.

Responded to Get Custom K8s Resource using Python and found the CustomObjectsApi documentation unclear.

If you have a cluster and a kubeconfig file with a correctly configured current-context, so that you can successfully:

PLURAL="checks"

kubectl get ${PLURAL} \
--all-namespaces

NOTE I’m using Ackal’s CRDs in these examples.

Then you can use the following code to access the cluster’s REST API server to enumerate its CRDs:

main.py:

from __future__ import print_function
from kubernetes import client, config
from kubernetes.client.rest import ApiException

config.load_kube_config()
api = client.CustomObjectsApi()

# Ackal's Group|Version and some Kinds
group = 'ack.al'
version = 'v1'
plurals = ['checks','customers']

for plural in plurals:
    try:
        resp = api.list_cluster_custom_object(
            group,
            version,
            plural,
        )

        for item in resp["items"]:
            spec = item["spec"]
            print(spec)
    except ApiException as e:
        print(e)

python3 -m venv venv
source venv/bin/activate
python3 -m pip install kubernetes==26.1.0
python3 main.py

That’s all!

Thanks to Joe Mooring for his solution to my question as to how to do this.

I’ve decided to ditch Google Analytics and am evaluating using GoatCounter with Hugo with Ananke theme.

This was the layout of the site:

.
├── archetypes
├── content
│   └── posts
├── go.mod
├── go.sum
├── hugo.toml
├── layouts
├── public
└── static

This is the structure (of layouts) with the necessary changes:

.
├── archetypes
├── content
│   └── posts
├── go.mod
├── go.sum
├── hugo.toml
├── layouts
│   ├── _default
│   │   └── baseof.html
│   └── partials
│       └── analytics.html
├── public
└── static

I copied /layouts/_default/baseof.html from the gohugo-ananke-theme repo into my site’s|repo’s /layouts/_default/baseof.html.

Python’s Protocol Buffers code-generation using protoc has had significant changes that can cause developers… “challenges”. This post summarizes my experience of these mostly to save me from repreatedly recreating this history for myself when I forget it.

• Version change
• Generated code change
• Implementation Backends

I’ll use this summarized table of proto and the Pypi library’s history in this post. protoc refers to the compiler that supports code-generation in multiple languages. protobuf refers to the corresponding Python (runtime) library on Pypi:

Google announced Firestore … integration with Eventarc. Ackal uses Firestore to persist Customer and Check information and it uses Google Cloud Firestore Triggers to handle events on these document types.

Eventarc feels like the strategic future of eventing in Google Cloud and I’ve been concerned since adopting the technology that Google would abandon Google Cloud Firestore Triggers.

For this reason, when I saw last week’s announcement, I thought I should evaluate the mechanism and this blog post is a summary of that work.

I’ve been running a DigitalOcean Apps static site for Hugo using the Hugo Buildpack.

I’ve migrated a set of Hugo sites to use Hugo Modules which includes the addition of go.mod (and go.sum) files to the Hugo project in order to manage e.g. themes.

Unfortunately, the Hugo Buildpack used by DigitalOcean Apps does not support Hugo Modules. DigitalOcean support recommended that I switch to use a build with a Dockerfile. Unfortunately (!) the recommended Hugo container image (klakegg/hugo) is outdated (0.107.0). The current version is 0.111.3.

I’ve been spending time recently optimizing Ackal’s use of Google Cloud Logging and Cloud Monitoring in posts:

• Filtering metrics w/ Google Managed Prometheus
• Kubernetes metrics, metrics everywhere
• Google Metric Diagnostics and Metric Data Ingested

Yesterday, I read that Robusta has a new open source project Kubernetes Resource Recommendations (KRR) so I took some time to evaluate it.

This post describes the changes I had to make to get KRR working with Google Managed Prometheus (GMP):

I’ve been on an efficiency drive with Cloud Logging and Cloud Monitoring.

With regards Cloud Logging, I’m contemplating (!) eliminating almost all log storage. As it is I’ve buzz cut log storage with a _Default sink that has comprehensive sets of NOT LOG_ID(X) inclusion and exclusion filters. As I was doing so, I began to wonder why I need to pay for the storage of much logging. There’s the comfort from knowing that everything you may ever need is being logged (at least for 30 days) but there’s also the costs that that entails. I use logs exclusively for debugging which got me thinking, couldn’t I just capture logs when I’m debugging (rather thna all the time?). I’ve not taken that leap yet but I’m noodling on it.

I’ve written Prometheus Exporters for various cloud platforms. My motivation for writing these Exporters is that I want a unified mechanism to track my usage of these platform’s services. It’s easy to deploy a service on a platform and inadvertently leave it running (up a bill). The set of exporters is:

• Prometheus Exporter for Azure
• Prometheus Exporter for Fly.io
• Prometheus Exporter for GCP
• Prometheus Exporter for Linode
• Prometheus Exporter for Vultr

This post describes the recently-added Azure Exporter which only provides metrics for Container Apps and Resource Groups.

I’ve been tinkering with ways to “unit-test” my assumptions when using cloud platforms. I recently wrote about good posts by Google describing achieving cost savings with Cloud Monitoring and Cloud Logging:

• How to identify and reduce costs of your Google Cloud observability in Cloud Monitoring
• Cloud Logging pricing for Cloud Admins: How to approach it & save cost

With Cloud Monitoring, I’ve restricted the prometheus.googleapis.com metrics that are being ingested but realized I wanted to track the number of Pods (and Containers) deployed to a GKE cluster.