Ееее 😎

Примеры алертов для Prometheus
https://awesome-prometheus-alerts.grep.to/rules

Поздравляю всех с наступающим (для кого-то, возможно, уже наступившим) Новым годом!

Пусть все ваши начинания обязательно заканчиваются успехом. Счастья и здоровья вам и вашим семьям.
Пусть Новый год для вас станет годом, в котором вы сможете реализовать все ваши мечты и воплотить в жизнь то, что раньше считали невозможным. Всем добра! Увидимся в следующем году! 💥💥💥

https://zelark.github.io/exploring-query-locks-in-postgres/
Десерт в конце - запрос для создания view lock_monitor, что позволяет в удобном виде смотреть блокировки и видеть, какой запрос все поломал.

Файл конфигурации Docker-демона со всеми возможными параметрами.
Чтобы не гуглить и не искать ответы на других сайтах, а сразу смотреть в официальной документации.
https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file

Вжух, и часть тарифов пропали
https://habr.com/ru/news/t/539498/

Большая карта навыков и компетенций для тимлидов. С подробным объяснением и дополнительными ссылками для изучения.
Пригодится не только тимлидам.
https://tlroadmap.io/

Дампим все чувствительные данные из Jenkins
https://www.codurance.com/publications/2019/05/30/accessing-and-dumping-jenkins-credentials

Часть 2. TTL vs Persistent/Eviction policies (maxmemory-policy)

Концепция Redis предполагает, что данные в нем с течением временем могут становиться неактуальными (устаревать), а потом удаляться. Для указания времени жизни ключа в Redis используется команда EXPIRE, который задает интервал времени, после которого ключ будет не будет доступен (удаление происходит не сразу, так как Redis использует механизм отложенного удаления данных. Подробнее). Время жизни ключа можно узнать командой TTL или PTTL.

Также в Redis можно хранить данные без указания TTL - такие данные считаются persistent и удаляются самим Redis только при установке нужной Eviction Policy (об этом позже). Для подобных случаев Redis рекомендует использовать отдельный инстанс для постоянных данных и инстанс для данных с TTL.

При использовании Redis в качестве кэша, рекомендуется дать ему возможность самостоятельно заниматься вытеснять (удалять) старые данные при добавлении новых. До Redis 4.0 LRU (Least Recently Used) являлся единственным поддерживаемым методом вытеснение (eviction). После версии 4.0 появился механизм LFU (Least Frequently Used).

Корректное вытеснение данных возможно только при указании корректных значений директивы maxmemory, которая максимальное количество памяти для хранимых данных. Для 64-битных версий Redis нет ограничений по количеству памяти (maxmemory 0), для 32-битных версий - 3 ГБ. При достижении лимита по памяти срабатывает указанная политика вытеснения (Eviction Policy или директива maxmemory-policy в конфигурации).

Существует следующий набор политик (не перевожу на русский, чтобы не менять смысл):

* noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).

* allkeys-lru: evict keys by trying to remove the less recently used (LRU) keys first, in order to make space for the new data added.

* volatile-lru: evict keys by trying to remove the less recently used (LRU) keys first, but only among keys that have an expire set, in order to make space for the new data added.

* allkeys-random: evict keys randomly in order to make space for the new data added.

* volatile-random: evict keys randomly in order to make space for the new data added, but only evict keys with an expire set.

* volatile-ttl: evict keys with an expire set, and try to evict keys with a shorter time to live (TTL) first, in order to make space for the new data added.

The policies volatile-lru, volatile-random and volatile-ttl behave like noeviction if there are no keys to evict matching the prerequisites.

Соответственно, каждая политика подходит под свою ситуацию и её всегда можно поменять на уже запущенном инстансе. Рекомендации от Redis Labs:
Соответственно, каждая политика подходит под свою ситуацию и её всегда можно поменять на уже запущенном инстансе. Рекомендации от Redis Labs:

* Use the allkeys-lru policy when you expect a power-law distribution in the popularity of your requests, that is, you expect that a subset of elements will be accessed far more often than the rest. This is a good pick if you are unsure.

* Use the allkeys-random if you have a cyclic access where all the keys are scanned continuously, or when you expect the distribution to be uniform (all elements likely accessed with the same probability).

* Use the volatile-ttl if you want to be able to provide hints to Redis about what are good candidate for expiration by using different TTL values when you create your cache objects.

The volatile-lru and volatile-random policies are mainly useful when you want to use a single instance for both caching and to have a set of persistent keys. However it is usually a better idea to run two Redis instances to solve such a problem.

It is also worth noting that setting an expire to a key costs memory, so using a policy like allkeys-lru is more memory efficient since there is no need to set an expire for the key to be evicted under memory pressure.

Полезные ссылки:
EXPIRE
Using Redis as an LRU cache

Название статьи говорит само за себя
https://www.redhat.com/sysadmin/beginners-guide-network-troubleshooting-linux

Набор полезных команд для PostgreSQL

Просмотр текущих запросов в БД

\x
select * from pg_stat_activity;

Проверка статуса репликации на мастере

select * from pg_stat_replication;

Проверка статуса репликации на реплике

select * from pg_stat_wal_receiver;

Посмотреть привилегии для пользователя

SELECT grantor, grantee, table_schema, table_name, privilege_type
FROM information_schema.table_privileges
WHERE grantee = 'username';

Проверка лага репликации (выполнять только на реплике)

select now() - pg_last_xact_replay_timestamp() AS replication_delay;

Получить список блокировок Lock_Monitoring

select relation::regclass, * from pg_locks where not granted;

Создать представление lock_monitor для просмотра списка блокировок
Исследуем блокировки в PostgreSQL

create view lock_monitor as (
  select
    coalesce(bgl.relation::regclass::text, bgl.locktype) as locked_item,
    now() - bda.query_start as waiting_duration,
    bda.pid as blocked_pid,
    bda.query as blocked_query,
    bdl.mode as blocked_mode,
    bga.pid as blocking_pid,
    bga.query as blocking_query,
    bgl.mode as blocking_mode
  from pg_catalog.pg_locks bdl
    join pg_stat_activity bda
      on bda.pid = bdl.pid
    join pg_catalog.pg_locks bgl
      on bgl.pid != bdl.pid
      and (bgl.transactionid = bdl.transactionid
        or bgl.relation = bdl.relation and bgl.locktype = bdl.locktype)
    join pg_stat_activity bga
      on bga.pid = bgl.pid
      and bga.datid = bda.datid
  where not bdl.granted
    and bga.datname = current_database()
);

Получить блокировки из представления lock_monitor

select * from lock_monitor;

Завершить запрос (gracefully)

SELECT pg_cancel_backend(PID);

Завершить процесс (non-gracefully)

SELECT pg_terminate_backend(PID);

Перечитать файлы конфигурации PostgreSQL

SELECT pg_reload_conf();

Получить текущий уровень изоляции транзакций в БД

SELECT current_setting('transaction_isolation');

Прибить все локи в БД
DO $$
DECLARE
r RECORD;
BEGIN
FOR r IN
SELECT blocking_pid FROM lock_monitor
LOOP
EXECUTE 'SELECT pg_terminate_backend('|| r.blocking_pid ||')';
END LOOP;
END $$;

С 1 по 3 марта пройдет бесплатная конференция PGConf 2021 https://pgconf.ru/2021
Программа конференции https://pgconf.ru/2021/program
Советую посмотреть хотя бы несколько выступлений

Kali Linux для маленьких хакеров 🤓
https://kids.kali.org/

NPM-пакет с Prometheus-экспортером для PM2. Дашборда для Grafana в github-репе (почти готовая, надо допиливать)
https://www.npmjs.com/package/pm2-metrics
https://github.com/saikatharryc/pm2-prometheus-exporter
Если запускаете в докере, то лучше ставить через npm install или добавить пакет в package.json
и привести ecosystem.config.js к виду, пригодному для запуска 2-х приложений.
Пример файла

module.exports = {
  apps: [
    {
      name: 'Your App',
      script: 'app',
      args: 'start',
      exec_mode: 'cluster',
      watch: false,
    },
    {
      name: 'PM2 Exporter',
      script: './node_modules/pm2-metrics/exporter.js',
      instances: '1',
      exec_mode: 'fork',
      autorestart: true,
      watch: false,
      max_memory_restart: '100M',
      env: {
        NODE_ENV: 'production',
      },
    },
  ],
};