Вольный перевод статьи.

Как метрики определили DevOps

начало положила команда DevOps Research and Assessment (DORA), Они выделили четыре ключевых метрики, которые являются основой для измерения успеха

Deployment Frequency: (частота развертывания) относится к частоте успешных выпусков программного обеспечения в производство. Этот показатель измеряет, как часто команда выпускает и успешно разворачивает новые версии программного обеспечения в рабочей среде. Высокая частота развертывания может указывать на более частые итерации разработки и доставки, что в свою очередь способствует более быстрой реакции на изменения и потребности пользователей, а также улучшению общей эффективности процессов DevOps.

Lead Time for Changes: (время выполнения изменений) измеряет время, прошедшее с момента фиксации изменения кода (например, коммита) до того момента, когда это изменение становится готовым для развертывания (в развертываемом состоянии). Этот показатель позволяет оценить, насколько быстро команда может превратить кодовое изменение в рабочее приложение, готовое к развертыванию в производственной среде. Уменьшение времени выполнения изменений обычно способствует более быстрой и эффективной разработке и доставке программного обеспечения.

Mean Time to Recovery: Среднее время восстановления (Mean Time to Recovery, MTTR) измеряет время, прошедшее с момента возникновения прерывания из-за развертывания или сбоя системы до полного восстановления работы системы. Этот показатель помогает определить, насколько быстро команда может восстановить работоспособность системы после возникновения проблемы или сбоя. MTTR является важной метрикой для оценки эффективности инцидентного управления и улучшения процессов восстановления.

Change Failure Rate: Показатель частоты неудач при изменениях (Change Failure Rate) указывает, насколько часто изменения или исправления (hotfixes), внесенные командой, приводят к сбоям или отказам после развертывания кода в производственной среде. Этот показатель является важной метрикой в контексте DevOps и оценивает надежность и стабильность процесса развертывания и обновления программного обеспечения.

Больше информации тут:

С момента публикации книги “Accelerate” команда LinearB увидела, как работа DORA преобразила область DevOps. Однако вскоре стало понятно, что четыре ключевых метрики DORA в одиночку недостаточно для измерения разнообразных и растущих организаций, практикующих DevOps.

DORA helped DevOps move from “darkness to visibility.” But once there’s full illumination, leaders need a full understanding of what makes one team more effective than another — and what characterizes the top tier of development teams that are truly elite.

LinearB co-founder and CEO Ori Keren

Что не так с DORA метриками ?

• DORA являются отстающими индикаторами, проще и более эффективно выявлять тенденции и предпринимать превентивные действия, чем спешить исправлять ошибки после неудачных итераций.

• Метрики DORA не точно измеряют бизнес-влияние. В пример приводится супер заряженная машина, которая идеально работает, но едет в другом направлении. Некоторые метрики, такие как время цикла и частота развертывания, важны для внутренней команды, но не имеют смысла для бизнеса в целом. Разработчики заботятся о относительной скорости разделов кода (как бы маленьких они ни были), чтобы обеспечивать плавную работу своего пайплайна, но руководители бизнеса хотят видеть всю функциональность – постоянно и как можно чаще. Скорость не имеет значения, если нет согласования с остальным бизнесом и команда не предоставляет то, что сделает клиентов счастливыми.
• Метрики DORA являются важными показателями текущего состояния, но они не являются планами изменений; они являются отправной точкой.

The New Metrics

Для того чтобы внести изменения в инженерные команды, исследование от LinearB выявило 10 метрик внутри 3 групп, которые имеют наибольшее значение в современной методологии DevOps.

• Жизненный цикл доставки ( Delivery Lifecycle Metrics )
• Рабочий процесс разработчиков ( Developer Workflow Metrics )
• Согласованность с бизнесом ( Business Alignment Metrics )

Delivery Lifecycle Metrics

1. Время цикла (Cycle time)

Время цикла (часто синоним Lead Time изменений ) является одной из четырех ключевых метрик DORA. Оно представляет собой время, прошедшее с момента первого коммита до момента, когда изменение достигает пользователей, охватывая время написания кода, время подбора задачи, время ревью и время на деплой.

Эффективное время цикла для элитных команд составляет менее 42 часов.

2. Время кодирования (Coding time)

Эта метрика измеряет время, затраченное с момента начала первого коммита до выдачи запроса на слияние (pull request, PR).

Для элитных команд время кодирования – менее 30 минут.

3. Время подбора (Pickup time)

Это время начинается после выдачи запроса на слияние (PR) и заканчивается после того, как будет оставлен первый комментарий.

Для элитных команд время подбора составляет менее 1 часа.

4. Время рецензии (Review time)

Эта метрика охватывает процесс рецензии кода и слияния PR, начиная с первого комментария и заканчивая моментом, когда изменения объединяются с основной веткой кода.

Для элитных команд время рецензии составляет менее 1 часа

5. Время развертывания (Deploy time)

Это измерение времени с момента слияния ветки (branch merge) до момента выпуска кода.

Для элитных команд время развертывания составляет менее 1 часа

Developer Workflow Metrics & How Elite Teams Perform

6. Частота развертывания (Deploy frequency)

Эта метрика измеряет, насколько часто код выпускается в производство. Она выше, когда время развертывания (deploy time) ниже. Ее также можно рассматривать как функцию времени цикла (cycle time).

Элитные команды делают деплой кода ежедневно.

7. Размер пул реквеста (PR)

Это, безусловно, один из наиболее важных ведущих индикаторов здоровой разработки. Меньшие PR = более быстрое восприятие, более быстрые и более глубокие рецензии, более быстрые слияния и более высокая частота развертывания.

В элитных командах в среднем менее 105 изменений кода в их PR.

8. Уровень “брака” (Rework rate)

Эта метрика измеряет уровень изменений в коде (code churn). Переделывание относится к изменениям в коде, возникшим в коде, который старше 21 дня. Более высокие уровни переделывания могут быть индикаторами проблем с качеством.

У элитных команд уровень переделывания составляет менее 2%.

Business Alignment Metrics

9. Точность планирования (Planning accuracy)

Эта метрика определяет, насколько точно выполнено планирование, то есть насколько совпадает то, что было запланировано, с тем, что было фактически доставлено.

Элитные команды имеют точность планирования 80% и более.

10. Точность определения объема (Capacity Accuracy)

Точность определения объема показывает, берут ли ваши команды “правильное” количество работы. Эта метрика измеряет соотношение всех завершенных (запланированных и незапланированных) задач к запланированной работе.

Элитные команды имеют точность определения объема более 85%.

Это означает, что они эффективно управляют рабочей нагрузкой, беря на себя необходимое количество работы и успешно завершая ее.

PS: остаток статьи маркетинг

PPS: Accelerate State of DevOps 2021

Типовые моменты которые стоит отработать на берегу

1. Прояснить требования к роли
2. Дать четкие, измеримые задачи на первые пару месяцев
3. Постепенное продвижение в сложные задачи
4. Не бросать одного, выстроить связь с остальной командой
5. Дать понимание о команде в целом, выстроить связь со смежными подразделениями

Теперь пройдемся по каждому пункту поподробнее

SRE – это широкая и разносторонняя роль.

Ваше определение SRE может отличаться от определения этой роли в других компаниях, где работал ваш новый сотрудник. Или вы вообще не определила четкие цели для SRE. Это может привести к неясному представлению о работе, которую нужно выполнять. В итоге, роли, на которые вы нанимаете сотрудников, становятся менее четкими.

Новые сотрудники могут быть эффективными только в той степени, в которой им известно, что нужно делать.

Постепенное продвижение в сложные задачи

Существует старая поговорка, которая гласит, что нельзя бежать, не научившись сначала ходить.

Это справедливо и в контексте обеспечения эффективности новых сотрудников в долгосрочной перспективе.

Знаю примеры когда руководители поступают следующим образом: предоставляют срок адаптации в 4-6 недель с ненапряжными заданиями, а затем бросают нового сотрудника “под Сталингад”.

Такой подход не всегда применим..

Дать конкретные, измеримые задачи в первые несколько месяцев

Важно предоставить новым сотрудникам конкретные и измеримые задачи в первые несколько месяцев работы. Если этого не делать, это может привести к недоиспользованию их потенциала, неопределенности и, как следствие, снижению продуктивности. Ниже представлены некоторые возможные шаги, которые помогут решить эту проблему:

1. Разработайте план адаптации: Создайте структурированный план адаптации для новых сотрудников, который включает в себя конкретные цели и задачи на первые несколько месяцев.
2. Установите ожидания: Объясните новым сотрудникам, какие результаты от них ожидаются в течение первых нескольких месяцев, и как они будут измеряться.
3. Прозрачность в задачах: Предоставьте им четкий список задач, которые они должны выполнять, и определите приоритеты.
4. Регулярные обзоры: Устраивайте регулярные обзоры прогресса, чтобы убедиться, что новые сотрудники понимают, как идет выполнение задач, и чтобы у них была возможность задавать вопросы и получать обратную связь.
5. Определите ключевые метрики успеха: Определите ключевые показатели, которые помогут измерить успех выполнения задач и оценить производительность новых сотрудников.
6. Дайте возможность для обучения: Предоставьте новым сотрудникам ресурсы и поддержку для обучения и развития, чтобы они могли успешно выполнять свои задачи.

Обеспечивая новым сотрудникам конкретные и измеримые задачи, вы помогаете им быстрее адаптироваться и стать более продуктивными членами команды.

Отсутствие конкретных, измеримых задач в первые месяцы работы

Это связано с недостатком ясности в роли.

Если у вас есть ясное представление о том, что должен делать ваш новый сотрудник, гораздо легче установить измеримые цели для того, на чем следует сосредоточить его внимание.

Это бывает сложно, если вы не знаете, с чего начать адаптацию нового сотрудника.

Некоторые конкретные и измеримые виды работы могут включать в себя:

• Наблюдение за работой других SRE при реагировании на инциденты (измеряется числом инцидентов).
• Написание отчетов об инцидентах (измеряется числом отчетов и выводами).
• Документирование процессов по мере их изучения (измеряется числом процессов).
• Написание кода для улучшения инструментов (измеряется количеством строк и коммитов).

Это может показаться банальным, но это конкретно и измеримо. Установка таких задач поможет не только новым сотрудникам ориентироваться, но и обеспечит более ясное представление о том, каким образом их работа будет измеряться и оцениваться.

Выстроить связи с остальной командой SRE

Это может сильно зависеть от того, где находится команда – в офисе, гибридно или полностью удаленно.

Это также может изменяться в зависимости от наличия у вас инициатив по созданию командного духа.

Ключевым моментом является создание эмоциональной связи между новым сотрудником и работой/командой.

Вот 3 способа, как вы можете усилить эмоциональную связь с вашей командой:

1. Программы ротации “бадди”. Соединение новых сотрудников с “бадди” (наставником) полезно, но один “бадди” означает одну сильную связь. Поворачивайте “бадди” в команде через разумное время, например, каждые 4 недели, чтобы распространить “рабочее дружеское чувство”.
2. Участие в совместных проектах. Вовлекайте новых сотрудников в проекты или активности, в которых участвуют несколько членов вашей команды. Это может включать проекты, такие как планирование ресурсов под новую систему, создание нового протокола реагирования на инциденты.
3. Регулярные встречи с руководителем. Это должно быть само собой разумеющимся, но, каюсь, сам оправдываю себя что постоянно занят и забываю о том, что недавно нанял новых сотрудников. Разумно заранее назначать расписание для очень коротких встреч.

Идеальный режим: проводить устные встречи в назначенные интервалы.

Режим “автопилота”: написать заранее электронные письма для отправки в назначенные интервалы.

Внесение ясности в то, как SRE вписывается в общую организацию

Последнее, чего хочет новый сотрудник, – это наступать на чужие ноги, особенно на ноги людей за пределами вашей команды SRE. Это может произойти, если вы не четко определите конкретную роль SRE в организации.

Что рекомендуется?

Явно донести до нового сотрудника, как функция SRE поддерживает более широкую инженерную функцию, включая:

1. Что разработчики несут ответственность за, например, “вы сами создаете, вы сами управляете” (“you build it, you run it”) или “мы управляем этим для вас” (“we run it for you”), или это гибридная модель.
2. Если другие функции обладают типичной способностью SRE, например, отдельная команда мониторинга, работающая независимо от команды SRE.
3. Сколько помощи нужно другим функциям, например, нужна ли помощь команде по безопасности при работе с сервисами во время инцидента? Нужна ли поддержка разработчикам во время инцидента?

Ясное и явное общение по этим вопросам поможет новому сотруднику лучше понять, как его работа вписывается в общую картину организации и какие ожидания у него есть по отношению к другим функциям и командам. Это поможет избежать недоразумений и конфликтов.

i’ll skip part with docker installation and put here only config files

[root@prod-oracle-rac grafana]# tree
.
├── 1.sh
├── alertmanager
│   ├── alert.tmpl
│   ├── config.yml
│   └── data
│   ├── nflog
│   └── silences
├── docker-compose.yaml
├── grafana
│   ├── alerting
│   │   └── 1
│   │   └── default.tmpl
│   ├── csv
│   ├── file-collections
│   ├── grafana.db
│   ├── plugins
│   ├── png
│   └── provisioning
├── oracledbexporter
│   └── custom-metrics.toml
└── prometheus
├── alert_rules.yml
└── prometheus.yml

version: '3.3'
services:

  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/:/etc/prometheus/
    container_name: prometheus
    hostname: prometheus
    command: ["--config.file=/etc/prometheus/prometheus.yml", "--log.level=debug"]
#command:
#      - --config.file=/etc/prometheus/prometheus.yml
#      - --LOG_LEVEL=debug
    links:
      - alertmanager:alertmanager
    ports:
      - 9090:9090
    restart: unless-stopped
    environment:
      TZ: "Europe/Moscow"
    networks:
      - default
    depends_on:
      - alertmanager
  node-exporter:
    image: prom/node-exporter
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    container_name: exporter
    hostname: exporter
    command:
      - --path.procfs=/host/proc
      - --path.sysfs=/host/sys
      - --collector.filesystem.ignored-mount-points
      - ^/(sys|proc|dev|host|etc|rootfs/var/lib/docker/containers|rootfs/var/lib/docker/overlay2|rootfs/run/docker/netns|rootfs/var/lib/docker/aufs)($$|/)
    ports:
      - 9100:9100
    restart: unless-stopped
    environment:
      TZ: "Europe/Moscow"
    networks:
      - default

  grafana:
    image: grafana/grafana
    restart: always
    user: root
    depends_on:
      - prometheus
    ports:
      - 3000:3000
    volumes:
      - ./grafana:/var/lib/grafana
      - ./grafana/provisioning/:/etc/grafana/provisioning/
    container_name: grafana
    hostname: grafana
    restart: unless-stopped
    environment:
      TZ: "Europe/Moscow"
    networks:
      - default

  alertmanager:
    image: prom/alertmanager:latest
    user: root
    ports:
      - 127.0.0.1:9093:9093
    volumes:
      - ./alertmanager/:/etc/alertmanager/
    container_name: alertmanager
    hostname: alertmanager
    environment:
      TZ: "Europe/Moscow"
    restart: unless-stopped
    command:
      - '--config.file=/etc/alertmanager/config.yml'
      - '--storage.path=/etc/alertmanager/data'
    networks:
      - default


  oracledbexporter:
    image: iamseth/oracledb_exporter
    volumes:
      - ./oracledbexporter:/etc/oracledb_exporter
    environment:
      - 'NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1'
      - 'DATA_SOURCE_NAME=username/userpass@10.100.18.11:1521/a49prm'
      - 'CUSTOM_METRICS=/etc/oracledb_exporter/custom-metrics.toml'
    restart: unless-stopped
    expose:
      -  9161
    network_mode: host

networks:
  default:
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/16

alertmanager config.yaml

# Отсюда читаем все шаблоны:
templates:
  - '/etc/alertmanager/template/*.tmpl'
route:
  # Группировка алертов
  group_by: ['alertname', 'cluster', 'service']
  # время ожидания перед отправкой уведомления для группы
  group_wait: 30s
  # время отправки повторного сообщения для группы
  group_interval: 5m
  # время до отправки повторного сообщения
  repeat_interval: 30m
  receiver: 'telega'
receivers:
  - name: 'telega'
    telegram_configs:
    - bot_token: 'xxxx:xxxxxxxxxxx'
      chat_id: -xxxxxxxxxxxxxx
      api_url: 'https://api.telegram.org'
      message:  "Alertname: {{ .GroupLabels.alertname }}\n Severity: {{ .CommonLabels.severity }}\n {{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"
      parse_mode: ''
      send_resolved: true

prometheus prometheus.yml

scrape_configs:
  - job_name: oracle_rac
    scrape_interval: 5s
    static_configs:
    - targets: ['node-exporter:9100']
  - job_name: oracle_db12
    scrape_interval: 5s
    static_configs:
    - targets: ['10.100.18.12:9100']
  - job_name: oracle_db11
    scrape_interval: 5s
    static_configs:
    - targets: ['10.100.18.11:9100']
  - job_name: 'oracle-exporter'
    scrape_interval: 10s
    scrape_timeout: 8s
    static_configs:
    - targets: ['10.100.18.10:9161']

rule_files:
  - alert_rules.yml
alerting:
  alertmanagers:
    - static_configs:
      - targets: ["alertmanager:9093"]

prometheus alert_rules.yml

groups:
  - name: nodeexporter
    rules:
    - alert: HostOutOfMemory
      expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host out of memory (instance {{ $labels.instance }})
        description: "Node memory is filling up (< 10% left)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostMemoryUnderMemoryPressure
      expr: rate(node_vmstat_pgmajfault[1m]) > 1000
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host memory under memory pressure (instance {{ $labels.instance }})
        description: "The node is under heavy memory pressure. High rate of major page faults\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualNetworkThroughputIn
      expr: sum by (instance) (rate(node_network_receive_bytes_total[2m])) / 1024 / 1024 > 100
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: Host unusual network throughput in (instance {{ $labels.instance }})
        description: "Host network interfaces are probably receiving too much data (> 100 MB/s)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualNetworkThroughputOut
      expr: sum by (instance) (rate(node_network_transmit_bytes_total[2m])) / 1024 / 1024 > 100
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: Host unusual network throughput out (instance {{ $labels.instance }})
        description: "Host network interfaces are probably sending too much data (> 100 MB/s)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualDiskReadRate
      expr: sum by (instance) (rate(node_disk_read_bytes_total[2m])) / 1024 / 1024 > 400
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: Host unusual disk read rate (instance {{ $labels.instance }})
        description: "Disk is probably reading too much data (>400 MB/s)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualDiskWriteRate
      expr: sum by (instance) (rate(node_disk_written_bytes_total[2m])) / 1024 / 1024 > 400
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host unusual disk write rate (instance {{ $labels.instance }})
        description: "Disk is probably writing too much data (>400 MB/s)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    # Please add ignored mountpoints in node_exporter parameters like
    # "--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|run)($|/)".
    # Same rule using "node_filesystem_free_bytes" will fire when disk fills for non-root users.
    - alert: HostOutOfDiskSpace
      expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 10 and ON (instance, device, mountpoint) node_filesystem_readonly == 0
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: Host out of disk space (instance {{ $labels.instance }})
        description: "Disk is almost full (< 10% left)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    # Please add ignored mountpoints in node_exporter parameters like
    # "--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|run)($|/)".
    # Same rule using "node_filesystem_free_bytes" will fire when disk fills for non-root users.
    - alert: HostDiskWillFillIn24Hours
      expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 10 and ON (instance, device, mountpoint) predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs"}[1h], 24 * 3600) < 0 and ON (instance, device, mountpoint) node_filesystem_readonly == 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host disk will fill in 24 hours (instance {{ $labels.instance }})
        description: "Filesystem is predicted to run out of space within the next 24 hours at current write rate\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostOutOfInodes
      expr: node_filesystem_files_free{mountpoint ="/rootfs"} / node_filesystem_files{mountpoint="/rootfs"} * 100 < 10 and ON (instance, device, mountpoint) node_filesystem_readonly{mountpoint="/rootfs"} == 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host out of inodes (instance {{ $labels.instance }})
        description: "Disk is almost running out of available inodes (< 10% left)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostInodesWillFillIn24Hours
      expr: node_filesystem_files_free{mountpoint ="/rootfs"} / node_filesystem_files{mountpoint="/rootfs"} * 100 < 10 and predict_linear(node_filesystem_files_free{mountpoint="/rootfs"}[1h], 24 * 3600) < 0 and ON (instance, device, mountpoint) node_filesystem_readonly{mountpoint="/rootfs"} == 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host inodes will fill in 24 hours (instance {{ $labels.instance }})
        description: "Filesystem is predicted to run out of inodes within the next 24 hours at current write rate\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualDiskReadLatency
      expr: rate(node_disk_read_time_seconds_total[1m]) / rate(node_disk_reads_completed_total[1m]) > 0.01 and rate(node_disk_reads_completed_total[1m]) > 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host unusual disk read latency (instance {{ $labels.instance }})
        description: "Disk latency is growing (read operations > 10ms)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostUnusualDiskWriteLatency
      expr: rate(node_disk_write_time_seconds_total[1m]) / rate(node_disk_writes_completed_total[1m]) > 0.01 and rate(node_disk_writes_completed_total[1m]) > 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host unusual disk write latency (instance {{ $labels.instance }})
        description: "Disk latency is growing (write operations > 10ms)\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostHighCpuLoad
      expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: Host high CPU load (instance {{ $labels.instance }})
        description: "CPU load is > 80%\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostCpuStealNoisyNeighbor
      expr: avg by(instance) (rate(node_cpu_seconds_total{mode="steal"}[5m])) * 100 > 10
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: Host CPU steal noisy neighbor (instance {{ $labels.instance }})
        description: "CPU steal is > 10%. A noisy neighbor is killing VM performances or a spot instance may be out of credit.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"


    - alert: HostSystemdServiceCrashed
      expr: node_systemd_unit_state{state="failed"} == 1
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: Host systemd service crashed (instance {{ $labels.instance }})
        description: "systemd service crashed\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"



    - alert: HostOomKillDetected
      expr: increase(node_vmstat_oom_kill[1m]) > 0
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: Host OOM kill detected (instance {{ $labels.instance }})
        description: "OOM kill detected\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostEdacCorrectableErrorsDetected
      expr: increase(node_edac_correctable_errors_total[1m]) > 0
      for: 0m
      labels:
        severity: info
      annotations:
        summary: Host EDAC Correctable Errors detected (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} has had {{ printf \"%.0f\" $value }} correctable memory errors reported by EDAC in the last 5 minutes.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostEdacUncorrectableErrorsDetected
      expr: node_edac_uncorrectable_errors_total > 0
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: Host EDAC Uncorrectable Errors detected (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} has had {{ printf \"%.0f\" $value }} uncorrectable memory errors reported by EDAC in the last 5 minutes.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostNetworkReceiveErrors
      expr: rate(node_network_receive_errs_total[2m]) / rate(node_network_receive_packets_total[2m]) > 0.01
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host Network Receive Errors (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} interface {{ $labels.device }} has encountered {{ printf \"%.0f\" $value }} receive errors in the last two minutes.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostNetworkTransmitErrors
      expr: rate(node_network_transmit_errs_total[2m]) / rate(node_network_transmit_packets_total[2m]) > 0.01
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host Network Transmit Errors (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} interface {{ $labels.device }} has encountered {{ printf \"%.0f\" $value }} transmit errors in the last two minutes.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostNetworkInterfaceSaturated
      expr: (rate(node_network_receive_bytes_total{device!~"^tap.*"}[1m]) + rate(node_network_transmit_bytes_total{device!~"^tap.*"}[1m])) / node_network_speed_bytes{device!~"^tap.*"} > 0.8 < 10000
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: Host Network Interface Saturated (instance {{ $labels.instance }})
        description: "The network interface \"{{ $labels.device }}\" on \"{{ $labels.instance }}\" is getting overloaded.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostNetworkBondDegraded
      expr: (node_bonding_active - node_bonding_slaves) != 0
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host Network Bond Degraded (instance {{ $labels.instance }})
        description: "Bond \"{{ $labels.device }}\" degraded on \"{{ $labels.instance }}\".\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostConntrackLimit
      expr: node_nf_conntrack_entries / node_nf_conntrack_entries_limit > 0.8
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: Host conntrack limit (instance {{ $labels.instance }})
        description: "The number of conntrack is approaching limit\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostClockSkew
      expr: (node_timex_offset_seconds > 0.05 and deriv(node_timex_offset_seconds[5m]) >= 0) or (node_timex_offset_seconds < -0.05 and deriv(node_timex_offset_seconds[5m]) <= 0)
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host clock skew (instance {{ $labels.instance }})
        description: "Clock skew detected. Clock is out of sync. Ensure NTP is configured correctly on this host.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostClockNotSynchronising
      expr: min_over_time(node_timex_sync_status[1m]) == 0 and node_timex_maxerror_seconds >= 16
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: Host clock not synchronising (instance {{ $labels.instance }})
        description: "Clock not synchronising. Ensure NTP is configured on this host.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: HostRequiresReboot
      expr: node_reboot_required > 0
      for: 4h
      labels:
        severity: info
      annotations:
        summary: Host requires reboot (instance {{ $labels.instance }})
        description: "{{ $labels.instance }} requires a reboot.\n  VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: RmanBackupFailed
      expr: oracledb_rman_backup_status_value > 3
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: oracle db backup failed  (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} has encountered error during backup \n VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

    - alert: instance_down
      expr: oracledb_up{instance="10.100.18.10:9161"} <1
      for: 0m
      labels:
        severity: critical
      annotations:
        summary: oracle db Down failed  (instance {{ $labels.instance }})
        description: "Host {{ $labels.instance }} unreacheable \n VALUE = {{ $value }}\n  LABELS = {{ $labels }}"

oracledbexporter custom-metrics.toml

[[metric]]
context = "system"
request = "select count(*) as session_count from v$session where username is not null and type = 'USER' and con_id = sys_context('userenv','con_id')"
metricsdesc = { session_count = "Current session count." }

[[metric]]
context = "system"
request = "select count(*) as active_sessions from v$session where username is not null and type = 'USER' and status = 'ACTIVE' and con_id = sys_context('userenv','con_id')"
metricsdesc = { active_sessions = "Active sessions." }

[[metric]]
context = "system"
request = "select (c.session_count - a.active_sessions) as inactive_sessions from (select count(*) as session_count from v$session where username is not null and type = 'USER' and con_id = sys_context('userenv','con_id')) c, (select count(*) as active_sessions from v$session where username is not null and type = 'USER' and status = 'ACTIVE' and con_id = sys_context('userenv','con_id')) a"
metricsdesc = { inactive_sessions = "Inactive sessions." }

[[metric]]
context = "system"
request = "select b.session_count as blocked_sessions from (select count(*) as session_count from v$session where username is not null and type = 'USER' and blocking_session_status = 'VALID' and con_id = sys_context('userenv','con_id')) b"
metricsdesc = { blocked_sessions = "Blocked sessions." }

[[metric]]
context = "rman_backup_status"
labels = [ "start_time", "input_type" ]
metricsdesc = { value="Gauge metric with rman backup status (5:FAILED; 4:RUNNING WITH ERRORS; 3:COMPLETED WITH ERRORS; 2:RUNNING WITH WARNINGS; 1:COMPLETED WITH WARNINGS; 0:COMPLETED)." }
request = '''
SELECT to_char(start_time, 'yyyy-mm-dd hh24:mi:ss') as start_time
,      input_type
,      cast( decode(status, 'FAILED', 5, 'RUNNING WITH ERRORS', 4, 'COMPLETED WITH ERRORS', 3, 'RUNNING WITH WARNINGS', 2, 'COMPLETED WITH WARNINGS', 1, 0) as integer) as value
FROM v$rman_backup_job_details
WHERE start_time = (SELECT max(start_time) FROM v$rman_backup_job_details)
'''

on target oracle host

wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz
724 28/03/23 08:15:16 ll /usr/local/bin/node_exporter
725 28/03/23 08:15:23 tar -xzvf node_exporter-1.5.0.linux-amd64.tar.gz
726 28/03/23 08:15:33 mv node_exporter-1.5.0.linux-amd64/node_exporter /usr/local/bin/

[root@prod-db1 ~]# cat /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
EnvironmentFile=/etc/sysconfig/node_exporter
ExecStart=/usr/local/bin/node_exporter $OPTIONS
[Install]
WantedBy=multi-user.target

727 28/03/23 08:15:44 systemctl status node_exporter
728 28/03/23 08:15:48 systemctl start node_exporter
729 28/03/23 08:15:50 systemctl status node_exporter

result

Usefull links

For some reason the Steam Client won’t work on case sensitive file system on Mac OS..

What happens is that you start steam and your screen may flicker and then steam will exit.

You can verify any issues with steam by checking the logs in:

~/Library/Application\ Support/Steam/logs/

# and most probably
~/Library/Application\ Support/Steam/logs/bootstrap_log.txt

A way to fix the issue is to create a case-insensitive volume and move steam there.

diskutil apfs addVolume disk1 APFS Steam
mv /Applications/Steam.app /Volumes/Steam/Steam.app
ln -s /Volumes/Steam/Steam.app /Applications/Steam.app
mv ~/Library/Application\ Support/Steam /Volumes/Steam/Library
ln -s /Volumes/Steam/Library ~/Library/Application\ Support/Steam

https://bliof.github.io/en/2019/01/26/steam-on-mac-case-sensitive-issue/

Вечер пятницы – самое время для новой статьи

Решил что просто смотреть лекции неэффективно. Материалы надо использовать в работе, а чтобы лучше запомнить можно оставить для себя заметки

1 Школа менеджмента Yandex— лекция 11. Ненасильственное управление. Григорий Бакунов
​

2 Важное качество хорошего родителя – демонстрировать стабильность.
Творческим специалистам важно ощущать, что вы как руководитель защищаете их от внешних воздействий.
Чем больше стабильности вы демонстрируйте , тем лучше – даже в таких глупых примерах как приходить в одно и время на работу  или приходить в одинаковой одежде ( одной цветовой гамме )

Демонстрируйте то, что вы защищаете своих коллег от внешних воздействий.

Человек который чувствует себя увереннее – работает более продуктивно

3 Вопросы, которые задают – это способ проверить авторитет.

Научитесь программировать.

Читайте новости о технологиях.

Вы должны быть хотя бы в курсе.

4 Нужно создавать позитив от совместной работы. Используйте методики повышения мотивации.

Важно, чтобы награда переходила только к достойным.

 “Кнут не вкусный, пряником быть бесполезно “.

ИТшники очень остро воспринимают несправедливость.

Менеджер приходит раньше основной массы сотрудников и уходит после.

5 Шок как средство для возвращения в сознание.

Требуется остановить истерику любым путем.

6 Знай все о каждом.

Это поможет лучше их понять и разрешить конфликты или стрессовые ситуации.

7 Коллектив – это экосистема, в которой не все работают эффективно. Но нельзя просто взять и уволить остальных. Тогда коллектив распадется.

8 Если вы что-то обещаете – делайте это. Используйте те формулировки, которые позволят потом вам объяснить, почему что-то не произошло. Могут быть внешние обстоятельства, а виноватым будете вы.
Помните, у вас тоже есть босс.

Если вы понимаете как добиться ваших целей без управления – бросайте управление.

Цели которые вам требуется достичь – должны быть невыполнимыми в одиночку.

Управление не должно быть самоцелью, в противном случае вы будете плохим управленцем.

 
with ash_fts as (
select u.username, ash.sql_id,ash.sql_plan_hash_value,ash.sql_plan_line_id from v$active_session_history ash
    join dba_users u  on ash.user_id=u.user_id
    where ash.sql_plan_operation='TABLE ACCESS' and ash.sql_plan_options='FULL' and ash.sample_time> sysdate-1/24  
    group by u.username, ash.sql_id,ash.sql_plan_hash_value,ash.sql_plan_line_id) --- ищем фулсканы таблиц за последний час, если убрать условие, то будет за весь период который храниться в ASH (глубина зависит от нагрузки на базу, от часов до дней )
 
 
    ,big_tables as (  select round (dt.num_rows*dt.avg_row_len/1024/1024/1024) table_size_gb,table_name,owner From dba_tables dt
where round (dt.num_rows*dt.avg_row_len/1024/1024/1024) > 2)    -- переписал на получение информации из статистики, ищем таблицы больше 2 гб
 
 
select ash.sql_id,b.owner, hsp.object_name from dba_hist_sql_plan hsp
    join ash_fts ash on ash.sql_plan_line_id=hsp.id and ash.sql_id=hsp.sql_id and ash.sql_plan_hash_value=hsp.plan_hash_value
    join big_tables b on b.table_name=hsp.object_name;
 

в результате увидим sql_id запроса и большую таблицу на которую идет фулскан

SQL_ID        | OWNER                          | OBJECT_NAME
------------- | ------------------------------ | -------------------------------
f9j0hsaz7h9y8 | LK                             | CALENDAR
 

select 'alter database drop logfile member '''|| member ||''';' from ( select rank ()over ( partition by  group# order by member) as rnk ,member from v$logfile ) where rnk=2 ;

valid for standby database:

alter system set standby_file_management=manual;

alter database add logfile thread 1
group 11 ('+REDO') size 1G,
group 12 ('+REDO') size 1G,
group 13 ('+REDO') size 1G,
group 14 ('+REDO') size 1G,
group 15 ('+REDO') size 1G;

alter database add logfile thread 2
group 21 ('+REDO') size 1G,
group 22 ('+REDO') size 1G,
group 23 ('+REDO') size 1G,
group 24 ('+REDO') size 1G,
group 25 ('+REDO') size 1G;

alter database add logfile thread 3
group 31 ('+REDO') size 1G,
group 32 ('+REDO') size 1G,
group 33 ('+REDO') size 1G,
group 34 ('+REDO') size 1G,
group 35 ('+REDO') size 1G;


alter database add standby logfile thread 1
group 111 ('+REDO') size 1G,
group 112 ('+REDO') size 1G,
group 113 ('+REDO') size 1G,
group 114 ('+REDO') size 1G,
group 115 ('+REDO') size 1G,
group 116 ('+REDO') size 1G;

alter database add standby logfile thread 2
group 121 ('+REDO') size 1G,
group 122 ('+REDO') size 1G,
group 123 ('+REDO') size 1G,
group 124 ('+REDO') size 1G,
group 125 ('+REDO') size 1G,
group 126 ('+REDO') size 1G;

alter database add standby logfile thread 3
group 131 ('+REDO') size 1G,
group 132 ('+REDO') size 1G,
group 133 ('+REDO') size 1G,
group 134 ('+REDO') size 1G,
group 135 ('+REDO') size 1G,
group 136 ('+REDO') size 1G;

valid for standby database:

alter system set standby_file_management=auto;

every time it tooks about 15 minutes to find out how to find queries with full scan… time to save it to my blog

 @http://blog.tanelpoder.com/files/scripts/ash/ashtop.sql sql_id,u.username,event "sql_plan_operation='TABLE ACCESS' and sql_plan_options='FULL'" sysdate-1/24 sysdate

    Total |         |         |               |                      |                                          |                      |                      |   Distinct
  Seconds |     AAS | %This   | SQL_ID        | USERNAME             | EVENT                                    | FIRST_SEEN           | LAST_SEEN            | Execs Seen
--------- | ------- | ------- | ------------- | -------------------- | ---------------------------------------- | -------------------- | -------------------- | ----------
      124 |      .0 |   27% | | 4ztz048yfq32s | DBSNMP               | direct path read                         | 2017-11-27 11:17:15  | 2017-11-27 11:48:41  |          2
       58 |      .0 |   13% | | 27mg3w92ah9fx | PATROL               | <NULL>                                   | 2017-11-27 11:18:28  | 2017-11-27 11:52:26  |         33
       48 |      .0 |   11% | | 4ztz048yfq32s | DBSNMP               | <NULL>                                   | 2017-11-27 11:17:29  | 2017-11-27 11:48:35  |          2
       28 |      .0 |    6% | | dwz7dgfp7k41u | XXX                  | <NULL>                                   | 2017-11-27 10:53:20  | 2017-11-27 11:52:38  |         28
       27 |      .0 |    6% | | 8576v2udda8xd | PATROL               | <NULL>                                   | 2017-11-27 11:18:28  | 2017-11-27 11:51:50  |         27
       17 |      .0 |    4% | | cv8umnmuc8kc8 | XXX                  | <NULL>                                   | 2017-11-27 10:53:53  | 2017-11-27 11:50:26  |         17
       16 |      .0 |    4% | | 297hq9h6h9mgt | PATROL               | <NULL>                                   | 2017-11-27 10:56:51  | 2017-11-27 11:45:34  |         16
       15 |      .0 |    3% | | 5ypmtb01t0bpf | NSI                  | <NULL>                                   | 2017-11-27 10:53:26  | 2017-11-27 11:49:35  |         15
       13 |      .0 |    3% | | 68q8jd8rj7fjp | XXXXLOGS             | <NULL>                                   | 2017-11-27 11:06:25  | 2017-11-27 11:07:14  |         13
       10 |      .0 |    2% | | 9g6pyx7qz035v | XXXXAUDIT            | <NULL>                                   | 2017-11-27 10:59:31  | 2017-11-27 11:45:06  |         10
        9 |      .0 |    2% | | 9q00wxqqzqjdg | SYS                  | db file scattered read                   | 2017-11-27 11:08:02  | 2017-11-27 11:08:16  |          1
        7 |      .0 |    2% | | 98uu7x2kgw9f7 | SYS                  | db file scattered read                   | 2017-11-27 11:08:18  | 2017-11-27 11:08:30  |          1
        4 |      .0 |    1% | | 98uu7x2kgw9f7 | SYS                  | <NULL>                                   | 2017-11-27 11:08:20  | 2017-11-27 11:08:28  |          1
        4 |      .0 |    1% | | 9q00wxqqzqjdg | SYS                  | gc cr multi block request                | 2017-11-27 11:08:01  | 2017-11-27 11:08:15  |          1
        4 |      .0 |    1% | | 9q00wxqqzqjdg | SYS                  | <NULL>                                   | 2017-11-27 11:08:03  | 2017-11-27 11:08:17  |          1