u/ban_rakash

https://preview.redd.it/bhyfdt5t9pgh1.png?width=1920&format=png&auto=webp&s=e13f6a15dac958b9f4dbcf651a8ef954cf940098

A production server rebooted after an unattended kernel update, which made me rethink how Linux patching should work in production.

Rather than just disabling unattended-upgrades, I designed a patch management system around controlled promotion and governance.

The approach uses:

• Aptly for internal package mirrors and immutable snapshots
• PostgreSQL to enforce promotion gates and maintain an audit trail
• Grafana for fleet health and CVE visibility
• Two-phase rollback to revert both the repository and client packages

I wrote a detailed article covering the architecture, design decisions, and trade-offs:

BLOG: 2ssk.medium.com/patch-management

REPO: 2SSK/patchops

I'm curious how others handle patch governance.

Do you use internal mirrors, Landscape, Satellite, Foreman, Custom tooling, or something else? What has worked well (or poorly) in your environment?

[AI has been used in drafting this post]

I just wrote up a detailed comparison of these two approaches, specifically for the case where you run multiple Temporal workers on the same host (bare metal, PM2, systemd).

The core issue is that the Prometheus exporter starts an in-process HTTP server. Scale to 2+ workers on the same machine → every worker tries to bind:9464 → EADDRINUSE. You can assign unique ports per worker, but now your Prometheus scrape config is tightly coupled to your process management.

The alternative: OTLP push to a shared OpenTelemetry Collector. All workers push to grpc://localhost:4317; the collector aggregates and serves Prometheus text format on:9464. One scrape target regardless of worker count—no port management.

The post includes:

\- Working OTel Collector config (OTLP receiver → batch processor → Prometheus exporter)

\- Docker Compose with proper resource limits

\- PM2 ecosystem config with per-worker service names

\- Startup guard script so the collector doesn't fail silently

\- Honest discussion about metrics loss when the collector is down

\- Comparison table of both approaches

[https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5\](https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5)

Would be interested to hear what others are using. I know K8s changes the equation since each worker is its own pod with its own port — Prometheus operator handles that well. But for bare metal / PM2 users, OTLP has been a big improvement.

TLDR: Prometheus exporter for single workers/Docker/K8s, OTLP for multi-worker on same host.

(GPT has been used to write this body.)

A practical example of using the OpenTelemetry Collector as an intermediary for Temporal SDK metrics.

The Temporal SDK supports both the Prometheus exporter (pull) and OTLP (push). If you're running multiple workers on the same host, the Prometheus exporter causes port conflicts. Switching to OTLP lets all workers push to a single collector, which then serves Prometheus HTTP for scraping.

https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5

Would love feedback on the OTel collector config — any improvements for production?

I just wrote up a detailed comparison of these two approaches, specifically for the case where you run multiple Temporal workers on the same host (bare metal, PM2, systemd).

The core issue is that the Prometheus exporter starts an in-process HTTP server. Scale to 2+ workers on the same machine → every worker tries to bind:9464 → EADDRINUSE. You can assign unique ports per worker, but now your Prometheus scrape config is tightly coupled to your process management.

The alternative: OTLP push to a shared OpenTelemetry Collector. All workers push to grpc://localhost:4317; the collector aggregates and serves Prometheus text format on:9464. One scrape target regardless of worker count—no port management.

The post includes:

- Working OTel Collector config (OTLP receiver → batch processor → Prometheus exporter)

- Docker Compose with proper resource limits

- PM2 ecosystem config with per-worker service names

- Startup guard script so the collector doesn't fail silently

- Honest discussion about metrics loss when the collector is down

- Comparison table of both approaches

https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5

Would be interested to hear what others are using. I know K8s changes the equation since each worker is its own pod with its own port — Prometheus operator handles that well. But for bare metal / PM2 users, OTLP has been a big improvement.

TLDR: Prometheus exporter for single workers/Docker/K8s, OTLP for multi-worker on same host.

(GPT has been used to write this body.)

I recently went through a fairly painful PostgreSQL 17 migration involving async replication, WAL retention issues, replica rebuilds, and long-running restore operations getting interrupted by timeout/configuration problems.

I wrote a detailed postmortem covering:

• how replication lag gradually snowballed
• WAL recycling failure modes
• why conservative Docker/container limits backfired
• timeout settings that caused silent failures
• recovery/rebuild strategy
• and the operational lessons I took away from it

Would genuinely appreciate feedback from people with more PostgreSQL operational experience.

Specifically interested in:

• what you would have done differently
• better approaches for large migrations with replicas
• WAL retention/replay best practices
• whether my diagnosis and conclusions make sense
• and any obvious mistakes in the migration strategy

Blog:
https://2ssk.medium.com/a-postgresql-17-migration-postmortem-wal-recycling-silent-timeouts-and-the-false-economy-of-73fcf6cdd704

Would love to hear perspectives from people who run PostgreSQL at larger scale or have dealt with similar replication incidents.

Hi fellow Neovim users,

The title says it all. Can you share your workflow for resolving git conflicts in Neovim?

Thanks.