Установка Okagent

Документация по установке будет доступна после создания проекта.

Встроенные плагины

• CPU usage
• Load average
• Memory
• Swap: утилизация, I/O
• Disks: утилизация, I/O
• По всем процессам: CPU, RAM, SWAP, Disk I/O, open files
• TCP соединения: states, ACK backlog, RTT
• Memcached
• Redis
• NGINX Access Log
• Raid
• Zookeeper

Настройка NGINX

• Добавьте: log_format (или измените существующий) в /etc/nginx/nginx.conf:

http {
        ...
        log_format combined_plus '$remote_addr - $remote_user [$time_local]'
                                 ' "$request" $status $body_bytes_sent "$http_referer"'
                                 ' "$http_user_agent" $request_time $upstream_cache_status'
                                 ' [$upstream_response_time]';
        ...
}           

• Используйте этот формат для каждой директивы access_log в конфигурационных файлах NGINX.
  Как правило, изменения достаточно внести только в /etc/nginx/nginx.conf:

http {
        ...
        access_log /var/log/nginx/access.log combined_plus;
        ...
}           

• Перезапустите NGINX: sudo /etc/init.d/nginx reload

PostgreSQL

$ sudo su postgres -c "psql -d postgres"

CREATE ROLE okagent WITH LOGIN PASSWORD 'EXAMPLE_PASSWORD_DONT_USE_THAT_please_!)';
CREATE SCHEMA okmeter;
GRANT USAGE ON SCHEMA okmeter TO okagent;
CREATE OR REPLACE FUNCTION okmeter.pg_stats(text)
RETURNS SETOF RECORD AS
$$
DECLARE r record;
BEGIN
    FOR r IN EXECUTE 'SELECT r FROM pg_' || $1 || ' r' LOOP RETURN NEXT r;  -- To get pg_settings, pg_stat_activity etc.
    END loop;
    RETURN;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

host all okagent 127.0.0.1/32 md5
local all okagent md5 

$ sudo su postgres -c "psql -d postgres"

SELECT pg_reload_conf();

Статистка запросов PostgreSQL

shared_preload_libraries = 'pg_stat_statements'   # change requires DB restart.
pg_stat_statements.max = 500
pg_stat_statements.track = top
pg_stat_statements.track_utility = true
pg_stat_statements.save = false
        

track_io_timing = on

$ sudo /etc/init.d/postgresql restart

$ sudo su postgres -c "psql -d postgres"

CREATE EXTENSION pg_stat_statements;

PgBouncer

"okagent" "EXAMPLE_PASSWORD_DONT_USE_THAT_please_!)"

"okagent" "EXAMPLE_PASSWORD_DONT_USE_THAT_please_!)"

; comma-separated list of users who are just allowed to use SHOW command
stats_users = okagent

/etc/init.d/pgbouncer reload

JVM

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.host=127.0.0.1 -Djava.rmi.server.hostname=127.0.0.1 -Dcom.sun.management.jmxremote.port=9099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false 

Php-fpm

pm.status_path = /status ;you can use /status or any other url, okagent will work with that

RabbitMQ

rabbitmq-plugins enable rabbitmq_management
rabbitmqctl add_user okagent EXAMPLE_PASSWORD_DONT_USE_THAT_please_!)
rabbitmqctl set_user_tags okagent monitoring

rabbitmqctl set_permissions -p / okagent ".*" ".*" ".*"
rabbitmqctl set_permissions -p /vhost1 okagent ".*" ".*" ".*"

rabbitmqctl list_vhosts

Mysql

CREATE USER 'okagent'@'%' IDENTIFIED BY 'EXAMPLE_PASSWORD_DONT_USE_THAT_please_!)';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'okagent'@'%';
GRANT SELECT ON `performance_schema`.* TO 'okagent'@'%';
FLUSH PRIVILEGES;

mysql> SELECT 'OK' FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='performance_schema' AND TABLE_NAME='events_statements_summary_by_digest';
+----+
| OK |
+----+
| OK |
+----+

mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

[mysqld]
performance_schema=ON

Внешние и облачные базы данных

Для мониторинга облачных и внешних баз данных (т.е. баз данных, которые находятся на хостах, на которых не установлен Okagent), можно установить Okagent на отдельный хост и настроить его соответствующим образом.

На настоящий момент поддерживаются следующие внешние и облачные базы данных: ElasticSearch, Redis, MySQL, PostgreSQL

На хосте, на котором установлен Okagent и у которого есть сетевой доступ к базе данных, необходимо для каждого инстанса базы данных создать конфигурационный файл в директории /usr/local/okagent/etc/config.d/ (например /usr/local/okagent/etc/config.d/remote_db.yaml) со следующим содержимым:

Для базы данных MySQL или PostgreSQL:

plugin: postgresql # или mysql
config:
  host: db_ip # замените на IP удаленного инстанса БД или endpoint кластера
  #port: db_port # раскомментируйте и замените на порт удаленного инстанса БД, если тот нестандартный
  user: db_user # замените на имя мониторинг-пользователя удаленного инстанса БД
  password: db_password # замените на пароль мониторинг-пользователя удаленного инстанса БД
  #database: mydb # замените на имя базы данных, которую вы подключили при создании схемы okmeter, пользователя и функции в PostgreSQL, если оно отличается от "postgres" 

Для базы данных Redis:

plugin: redis
config:
  host: db_ip # замените на IP удаленного инстанса БД или endpoint кластера 
  #port: db_port # раскомментируйте и замените на порт удаленного инстанса БД, если тот нестандартный
  #password: db_password # раскомментируйте и замените на пароль мониторинг-пользователя удаленного инстанса БД

Для базы данных ElasticSearch

plugin: elasticsearch
config:
  host: elasticserch_ip # замените на IP Elasticsearch в формате: xx.xx.xx.xx
  #port: db_port # раскомментируйте и замените на порт удаленного инстанса Elasticsearch, если тот нестандартный (9200)
  #user: db_user # раскомментируйте и замените на имя мониторинг-пользователя удаленного инстанса Elasticsearch
  #password: db_password # раскомментируйте и замените на пароль мониторинг-пользователя удаленного инстанса Elasticsearch
  #insecureTls: true # раскомментируйте, если Elasticsearch настроена на использование самоподписанного сертификата

Для применения настроек перезапустите Okagent: $ sudo /etc/init.d/okagent restart (или $ sudo systemctl restart okagent.service).

Убедитесь, что для базы данных произведены все необходимые дополнительные настройки (см. документацию Mysql или Postgresql).

Zookeeper

4lw.commands.whitelist=stat, mntr

Пользовательские метрики

В дополнение к встроенным метрикам Okagent может отправлять кастомные метрики. Есть несколько способов генерации таких метрик :

• Написать SQL запрос, который возвращает цифровые значения, воспользовавшись плагином SQL query.
• Производить парсинг файлов логов с помощью плагина Logparser.
• Написать скрипт, который генерирует метрики, и вызывать его с помощью плагина Execute.
• Производить парсинг ответа на HTTP-запрос с помощью плагина HTTP.
• Генерировать метрики на основе вывода Redis-команд, воспользовавшись плагином Redis query.
• Собирать метрики с приложения с помощью Statsd.
• Собирать метрики с Promethus-совместимых экспортеров, воспользовавшись плагином Prometheus

Эти плагины требуют дополнительной настройки с помощью конфигурационных файлов. Okagent при запуске читает все конфигурационные файлы в каталоге /usr/local/okagent/etc/config.d/. Имя конфигурационного файла может быть любым, расширения всегда должно быть .yaml, формат файла — YAML.

Проверка конфигурационных файлов | режим dry run

Синтаксис кофигурационного файла можно проверить с помощью следующей команды (замените PLUGIN_CONFIG_FILE на свой файл):

$ /usr/local/okagent/okagent -dry-run=/usr/local/okagent/etc/config.d/PLUGIN_CONFIG_FILE

Если в результате выполения комманды не возникло ошибок, примените конфигурационный файл, перезапустив Okagent: $ sudo /etc/init.d/okagent restart (или $ sudo systemctl restart okagent.service).

plugin: execute
config:
  command: 'du /var/log/app/main.log'
  regexp: '(?P<value>\d+)'
  name: demo_app_log_size  # metric name
  value: value             # metric value
  labels:                  # metric labels
    log_name: main

JSON

{
    "name": "metric1",
    "labels": {"label1": "foo", "label2": "bar"},
    "value": 123.4
}

            echo '{"name": "metric1", "labels": {"label1": "foo", "label2": "bar"}, "value": 123.4}'
            

plugin: execute
config:
  command: /tmp/calc_metrics.sh
  parser: json

echo '[{"name": "metric1", "value": 123.4}, {"name": "metric2", "value": 567}]'

Плагин Logparser

Данный плагин отправляет метрики, полученные из файла логов. Для генерации метрик можно использовать парсеры Regexp или JSON.

Regexp

   plugin: logparser
   config:
   file: /var/log/app/stages.log
   regexes:
   # 2015-11-21 15:42:36,972 demo [DEBUG] page=item stages: db=0.007s, render=0.002s, total=0.010s count=1
   - regex: '(?P\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).+ page=(?P\w+) stages: db=(?P\d+\.\d+)s, render=(?P\d+\.\d+)s, total=(?P\d+\.\d+)s count=(?P\d+)'
   time_field: datetime
   time_field_format: '2006-01-02 15:04:05'
   metrics:
   ...
   

• file — путь до файла, который будет анализироваться. Okagent корректно обрабатывает ротацию файлов.
• regexes — список регулярных выражений, которые будут применены к строкам. Регулярные выражения применяются последовательно.
  • regexp — поле, в котором задается Perl-совместимое регулярное выражение(regex), на основании которого строка будет разделена на именованные группы для дальнейшей трансформации в метрики.
• time_field — имя группы для временных меток.
• time_field_format — формат временных меток.
• metrics — список метрик, которые должны быть отправлены, вместе с правилами трансформации строк в метрики.

JSON

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

   plugin: logparser
   config:
   file: /var/log/app/stages.log
   json: true
   # {ts: "2015-11-21 15:42:36.000+0300", user: "demo", page: "item", db: "0.007", render: "0.002", total: "0.010", count: "1"}
   time_field: ts
   time_field_format: "2006-01-02 15:04:05.000-0700"
   metrics:
   ...
   

• file — путь до анализируемого файла. Okagent корректно обрабатывает ротацию файлов.
• json — поле, определяющее тип парсера (JSON).
• time_field — имя группы для временных меток.
• time_field_format — формат временных меток.

TOP

Парсинг логов часто приводит к большому "оттоку" (churn) метрик, что негативно сказывается на отображении графиков. Для метрик на основе файлов логов рекомендуется использовать функцию TOP. Она позволяет получить N метрик (параметр N задается в конфигурационном файле), при этом все остальные метрики суммируются и отправляются в виде дополнительной метрики со значением label: ~other.

Пример. Производится парсинг лог-фала /var/log/app/stages.log, в котором содержится информация о запросах пользователей к сервису. Требуется отправлять метрики только по десяти запросам, которые чаще всего встречались за последние 10 минут. Для реализации этой схемы необходимо создать конфигурационный YAML-файл /usr/local/okagent/etc/config.d/top_url.yaml следующего вида:

   plugin: logparser
   config:
   file: /var/log/app/stages.log
   #{"ts":"2018-09-12 13:07:11.500","logger": "requests","time":"33","method":"PUT","status":200,"uri":"/aaa/bbb","rid":noRequestId,ip":"2.2.2.2"}
   #{"ts":"2019-11-20 18:32:49.851+0300","logger":"requests","time":"157","method":"PUT","status":200,"uri":"/foo/bar?from=header_new","rid":"11","ip":"1.1.1.1"}
   json: true
   time_field: ts
   time_field_format: "2006-01-02 15:04:05.000-0700"
   top_vars:
   topurl:
   source: uri
   weight: 1
   threshold_percent: 1
   window_minutes: 10
   metrics:
   - type: rate
   name: service_requests_rate
   labels:
   method: =method
   url: =topurl
   status: =status
   - type: percentiles
   name: service_response_time_percentiles
   value: ms2sec:time
   args: [50, 75, 95, 99]
   - type: percentiles
   name: service_response_time_percentile_by_url
   value: ms2sec:time
   args: [95]
   labels:
   url: =topurl
   

В разделе top_vars есть следующие поля:

• topurl — новый лейбл для метрики, по которому будет производиться получение TOPN URIs (JSON-поле – source: uri).

• weight — вес, на который будет изменяться счетчик при каждом вхождении для URI.
• threshold_percent — метрики, процент которых в общей сумме ниже этого порогового значения, объединяются в специальную кумулятивную метрику (~other).
• window_minutes — размер окна, в рамках которого производится подсчет TOP.

type задает тип метрики и может принимать следующие значения:

• rate — средняя скорость роста метрики в минуту. Является значением по умолчанию.
• percentile — процентиль для метрики. Поле args — массив желаемых процентилей, например: [50, 95, 99].
• max или min — отправляет максимальное или минимальное значение для метрики за минуту.
• threshold — собирает количество попаданий значения value в различные интервалы (например, (-∞, 0.5], (0.5, 1], ...).

time_field — имя группы для хранения временных меток.

time_field_format — формат временных меток. Возможные форматы:

• unix_timestamp — временные метки в формате Unix
• common_log_format — временные метки в формате 2/Jan/2006:15:04:05 -0700
• time_iso8601 — временные метки в формате RFC 3339 (также ISO 8601)
• Кастомный формат временных меток. Пользователь сам определяет, как контрольное время — например, Mon Jan 2 15:04:05 -0700 MST 2006 — будет приведено к формату лога. Служит примером для плагина Logparser.

При отсутствии информации о часовом поясе используется часовой пояс UTC.

Поле metric может содержать поле labels, значениями которого могут выступать статические (stage: db) или динамические (page: =page) лейблы. Знак равенства = перед значением лейбла (как в примере выше — page: =page) означает, что значение этого лейбла должно быть взято из regexp-группы с именем page.

Прмер. Предположим, что лог приложения содержит следующие записи:

   ...
   2015-11-01 22:51:44,072 demo [DEBUG] page=item stages: db=0.005s, render=0.002s
   2015-11-01 22:51:44,087 demo [DEBUG] page=list stages: db=0.003s, render=0.001s
   ...
   

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

   plugin: logparser
   config:
   file: /var/log/app/stages.log
   regexes:
   # 2015-11-21 15:42:36,972 demo [DEBUG] page=item stages: db=0.007s, render=0.002s, total=0.010s count=1
   - regex: '(?P<datetime>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).+ page=(?P<page>\w+) stages: db=(?P<db>\d+\.\d+)s, render=(?P<render>\d+\.\d+)s, total=(?P<total>\d+\.\d+)s count=(?P<count>\d+)'
   time_field: datetime
   time_field_format: '2006-01-02 15:04:05'
   metrics:
   - type: percentiles
   args: [50, 75, 95, 98, 99]
   value: db
   name: demo_stages_percentiles
   labels:
   stage: db
   - type: percentiles
   args: [50, 75, 95, 98, 99]
   value: render
   name: demo_stages_percentiles
   labels:
   stage: render
   - type: rate
   name: demo_requests_rate
   labels:
   page: =page
   - type: rate
   name: demo_documents_rate
   value: count
   labels:
   page: =page
   - type: threshold
   value: total
   args: [0.05, 0.1]
   name: demo_render_histogram
   labels:
   page: =render
   

... плагин Logparser будет отправлять следующие метрики: demo_requests_rate, demo_documents_rate, demo_stages_percentiles and demo_render_histogram.

Плагин HTTP

Этот плагин отправляет пользовательские метрики о доступности HTTP-сервиса, а так же метрики, полученные в результате парсинга ответа на HTTP-запроса.

Пример. Есть HTTP-сервис, доступ к которому ограничен Basic Auth. Ответ на запрос к URL /service/stat выглядит следующим образом:

curl --user name:password -H 'Foo: bar' -v 'http://127.0.0.1:8080/service/stat'
   > GET /service/stat HTTP/1.1
   > Host: 127.0.0.1
   > Authorization: Basic bmFtZTpwYXNzd29yZA==
   > Foo: bar
   >
   < HTTP/1.1 200 OK
   <
   online_users=140 active_users=10

Для отправки пользовательских метрик, полученных в результате парсинга ответа на HTTP-запрос, необходимо создать конфигурационный файл /usr/local/okagent/etc/config.d/http.yaml в формате YAML:

plugin: http
   config:
   url: http://127.0.0.1:8080/service/stat
   username: name
   password: password
   #sslskip: on #optional, disable certificate verification, like curl --insecure
   headers:
   foo: bar
   metrics:
   - metric: users_online
   regex: 'online_users=(\d+)'
   - metric: users_active
   regex: 'active_users=(\d+)'
   

Запрос будет выполняться каждую минуту, и по результатам парсинга полученного ответа будут отправляться следующие метрики:

metric(name="users_online")
   metric(name="users_active")
   

Кроме того, будут отправляться три дополнительные метрики:

metric(name="status", plugin="http", instance="<config filename>")

Со значением "1", если запрос был выполнен успешно, и "0" — в противном случае.

metric(name="status", plugin="http", instance="<config filename> type="text", value="")

Значение лейбла value будет пустым, если запрос был выполнен без ошибок. В противном случае в значении поля value будет указана ошибка, которая возникла в процессе выполнения запроса.

metric(name="http.request_time", plugin="http", instance="<config filename>")

В качестве значения этой метрики будет передаваться время выполения запроса.

Внимание: Имена метрик и лейблов могут содержать только ASCII-символы и цифры и должны удовлятворять регулярному выражению [a-zA-Z_][a-zA-Z0-9_]*.

Внимание: Перед использованием проверьте корректность конфигурационного файла.

Внимание: Для применения настроек перезапустите Okagent: $ sudo /etc/init.d/okagent restart (или $ sudo systemctl restart okagent.service).

Плагин Redis query

Этот плагин позволяет отправлять кастомные метрики, полученные в результате выполения команд Redis. Пример конфигурационного файла /usr/local/okagent/etc/config.d/redis_example.yaml приведен ниже:

plugin: redis_query
   config:
   #host: 127.0.0.1 #optional
   #port: 6379 #optional
   #database: 0 #optional
   commands:
   - LLEN achievement_queue
   - SCARD some_queue
   - HGET stat active_connections
   - GET mail_sender_queue_len

   metric(name="achievement_queue.llen")
   metric(name="some_queue.scard")
   metric(name="stat.hget", param="active_connections")
   metric(name="mail_sender_queue_len.get")
   

Плагин Prometheus

Данный плагин позволяет собирать данные с Prometheus-совместимых экспортеров и отправлять их в виде метрик.

Для приложений, запущенных в Kubernetes, обнаружение (discovering) производится с помощью аннотаций:

   apiVersion: apps/v1
   kind: Deployment #or StatefulSet, DaemonSet, CronJob, ...
   metadata:
   name: my-app
   annotations:
   prometheus.io/scrape: "true"
   prometheus.io/scheme: "http"
   prometheus.io/port: "80"
   prometheus.io/path: "/metrics"
   ...

Okagent также может производить discovering для приложений, запущенных в Docker-контейнерах, у которых установлены соответствующие лейблы:

   docker run --name my-app \
   --label io.prometheus.scrape=true \
   --label io.prometheus.port=80 \
   --label io.prometheus.scheme=http \
   --label io.prometheus.path="/metrics" \
   ...

Okagent способен собирать данные с пользовательских targets, описанных в конфигурационном файле. Сбор данных производится, пока Okagent получает корректные ответы. Пример конфигурационного файла плагина приведен ниже:

   plugin: prometheus
   config:
   targets:
   - http://localhost:9100/metrics
   # max cardinality (default 5000)
   limit: 1200
   # additional labels for all scraped metrics
   labels:
   exporter: node
   

При необходимости можно указать данные для аутентификации. На текущий момент поддерживается Basic Authorization и аутентификация на базе Bearer-токенов

   plugin: prometheus
   config:
   targets:
   - http://localhost:9100/metrics
   authorization:
   type: basic
   username: <user>
   password: <password>
   

Пример конфигурационного файла с использование Bearer-токена:

   plugin: prometheus
   config:
   targets:
   - http://localhost:9100/metrics
   authorization:
   type: bearer
   token: <token>
   

API

В Okmeter встроена ограниченная поддержка API Prometheus. На настоящий момент поддерживаются два типа запросов: query и query_range.

Okmeter можно подключить как Datasource в инсталяцию Grafana. Для этого необходимо добавить новый Datasource типа Prometheus со следующими настройками:

В качестве Basic Auth Password необходимо использовать токен доступа . Важно установить Scrape interval, равный 60s.

После настройки этот Datasource можно использовать для получения данных из Okmeter.

На настоящий момент Okmeter не поддерживает язык запросов PromQL. Поддерживается только собственный язык запросов Okmeter Query Language.

Query Language

Синтаксис lines-выражений:

lines:
- expression: metric(a='b', c='d*', e=['f', 'g*']) #пример с различными load averages

получить список всех метрик с определенным значением лейблов

a='b' – точное соответствие; все метрики с лейблом a, значение которого равно 'b'

c='d*' – частичное соответствие; все метрики с лейблом c, значение которого начинается с символа 'd'

e=['f', 'g*'] все метрики с лейблом e, значение которого равно 'f' или начинается с символа 'g'

lines:
- expression: rate(EXPR) #пример: python cpu_user

Скорость изменения значений для всех метрик, указанных в EXPR

lines:
- expression: counter_rate(EXPR) #пример: python cpu_user

аналогично функции rate, но с обработкой сброса счетчиков

lines:
- expression: sum(EXPR [, ignore_nan=True|False]) #пример: all python's cpu_user and cpu_system

сумма всех метрик, указанных в EXPR

В случае ignore_nan=False конечный результат тоже будет NaN, если хотя бы одно из значений равно NaN. Значение по умолчанию: ignore_nan=True

lines:
- expression: max(EXPR)
- expression: min(EXPR)
- expression: std(EXPR) #стандартное отклонение
- expression: average(EXPR) #то же, что и mean
- expression: mean(EXPR) #пример mean load average

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

lines:
- expression: sum_by(label_name, [other_label,] EXPR) #пример processes cpu usage
- expression: max_by(label_name, [other_label,] EXPR)
- expression: min_by(label_name, [other_label,] EXPR)
- expression: std_by(label_name, [other_label,] EXPR) #стандартное отклонение
- expression: mean_by(label_name, [other_label,] EXPR) #то же, что и average
- expression: average_by(label_name, [other_label,] EXPR) #пример mean load average

группировка всех метрик в EXPR по значению лейбла label_name; все метрики из одной группы агрегируются в одну, новую метрику.

Возможно использование параметра ignore_nan=False|True; поведение аналогично sum

lines:
- expression: win_sum(window_size_in_seconds, EXPR)
- expression: win_mean(window_size_in_seconds, EXPR) #то же, что и win_avg
- expression: win_min(window_size_in_seconds, EXPR)
- expression: win_max(window_size_in_seconds, EXPR)
- expression: win_std(window_size_in_seconds, EXPR)
- expression: win_avg(window_size_in_seconds, EXPR) #пример mean load average с окном в 1 час

Применяются функции sum|mean|min|max|std для каждой метрики, указанной в EXPR, со смещением, равным window_size_in_seconds. См. Скользящая средняя

lines:
- expression: cum_sum(EXPR) #пример

Кумулятивная сумма для всех метрик в EXPR.

lines:
- expression: top(N, EXPR[, include_other=true|false][, by="exp"|"sum"|"max"]) #пример: 5 процессов с наибольшим использованием CPU
- expression: bottom(N, EXPR[, by="exp"|"sum"|"max"])

Показать top|bottom N (N максимальных|минимальных значений) для каждой метрики, указанной в EXPR, выбранных на основе exp|ews(экспоненциально взвешенной суммы) или sum или max для каждой точки

lines:
- expression: filter_with(EXPR, FILTER_EXPR) #пример: использование памяти долгоживущими процессами

фильтр для метрик, указанных в EXPR; возвращает только метрики с ненулевым (или не-NaN) значением FILTER_EXPR.

lines:
- expression: const(v[, label="value", ...]) #пример

константная метрика со значением v и дополнительным лейблом, который можно использовать в легенде

lines:
- expression: time()

возвращает timestamp по оси X в качестве значения Y

lines:
- expression: from_string("1,2,3,3,2,1,", [,repeat=false] [,sep=' '] [,label="value", ...]) #пример

конструктор метрик из строки, например: "1,2,3,3,2,1,". Здесь каждый элемент равен значению метрики за соответствующую минуту

lines:
- expression: defined(EXPR) #пример: все процессы

возвращает 1, если у метрики, указанной в EXPR, есть значение в данной точке, или 0, если значение метрики NaN

lines:
- expression: replace(old_val, new_val, EXPR) #пример
- expression: n2z(EXPR) #shortcut for "replace(nan, 0, EXPR)"
- expression: zero_if_none(EXPR) #shortcut for "replace(nan, 0, EXPR)"
- expression: z2n(EXPR) #shortcut for "replace(0, nan, EXPR)"
- expression: zero_if_negative(EXPR)
- expression: none_if_zero(EXPR) #shortcut for "replace(0, nan, EXPR)"
- expression: remove_below(EXPR, value)
- expression: remove_above(EXPR, value)
- expression: clamp_min(EXPR, min)
- expression: clamp_max(EXPR, max)

устанавливает новое значение new_val взамен старого old_val

lines:
- expression: sum_by(label, [other_label,] metric(..)) / max_by(label, [other_label,] metric(.))
- expression: sum_by(label, [other_label,] metric(..)) * sum_by(label, [other_label,] metric(.))
- expression: sum_by(label, [other_label,] metric(..)) - min_by(label, [other_label,] metric(.))

возвращает результат арифметических операций /, * или - для всех пар метрик (одной с левой стороны и одной с правой стороны), у которых полностью совпадают наборы лейблов и их значений

lines:
- expression: sum_by(label, [other_label,] metric(..)) / EXPR
- expression: min_by(label, [other_label,] metric(..)) * EXPR
- expression: max_by(label, [other_label,] metric(..)) - EXPR

производится / (деление) на значение EXPR или * (умножение) на значение EXPR или - (вычитание)значения EXPR для каждой метрики слева, полученной в результате расчета XXX_by(label, ...)

Настройка отображения легенды:

lines:
- expression: metric(...)
  legend: '%s'

в легенде отображаются пары label_name:label_value для каждой линии

lines:
- expression: metric(...)
  legend: '%(label_name)s anything'

в легенде отображаются label_value anything для каждой линии

Настройка цвета линии:

lines:
- expression: metric(...)
  color: '#81ff22'
- expression: metric(...)
  color: 'red'

задает цвет линии

lines:
- expression: metric(...)
  colors: ['#80AB00', 'red', 'rgb(127,0,20)', 'hsla(100,10%,20%,0.8)']

циклическое переключение по списку цветов

lines:
- expression: metric(...)
  colors: 
    /regex.*/: '#fff'
    /regex2/: 'gold'

задает цвет линий, удовлетворяющих regexp

lines:
- expression: metric(...)
options:
  colors: semaphore
  #OR
  colors: semaphore inv

заливает все ранее неокрашенные линии градиентом от red до green

или от green до red, если задана опция semaphore inv

Сортировка:

lines:
- expression: metric(...)
options:
  sort: alpha|num

сортировка всех строк в легенде в алфавитном порядке или по значениям (режим по умолчанию)

lines:
- expression: metric(...)
options:
  sort: ['fixed', 'order', 'for', 'legend', 'items']

фиксированный порядок для отображения элементов легенды

lines:
- expression: metric(...)
options:
  sort: ...
  order: DESC

убывающий порядок сортировки

Синтаксис сортировки во всплывающей подсказке:

lines:
- expression: metric(...)
options:
  tooltip:
    sort_order: name|-name|value|-value

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

• в алфавитном(name | -name).
• по значениям(value | -value)

Captions:

lines:
- expression: metric(...)
- expression: metric(...)
title: 'some %(label_name)s'

название графика

lines:
- expression: metric(...)
- expression: metric(...)
options:
  y_title: 'some text'

название оси Y

Alerting

Алерты — неотъемлемая часть системы мониторинга. Они позволяют пользователю своевременно узнавать о происходящем.

Настройка уведомлений в Okmeter состоит из двух частей: в части triggers настраиваются правила, определяющие, когда отправляется уведомление. Часть notifications определяет, куда отправляется уведомление

Okmeter предлагает большое количество преднастроенных триггеров. Также можно создавать свои триггеры или переопределять преднастроенные.

Настоятельно рекомендуем тестировать изменения в настройках triggers или notifications, чтобы убедиться, что уведомления срабатывают тогда, когда это необходимо. Самый простой способ тестирования — перевести триггер в активное состояние. Сделать это можно, например, изменив значение threshold.

   expression: 'sum(n2z(metric(name="nginx.requests.rate", status="5*")))'
   threshold: '>= 1'
   severity: critical
   message: '5xx NGINX %(value).1f per sec'
   notify_after: 120
   resolve_after: 180
   notification_config: ops

   expression: 'sum_by(status, n2z(metric(name="nginx.requests.rate", status="5*")))'
   message: '%(status)s NGINX %(value).1f per sec'

   renotify_interval: 600
   notify_resolve: on
   oncalls: # email and sms
   - admin_1
   - admin_2
   - boss
   slack_url: https://hooks.slack.com/services/XXXX/XXXX/XXXXXXXX
   slack_channel: '#ops'
   telegram_chat_id: -XXXXXXXX
   opsgenie:
   api_key: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
   prometheus:
   url: http://HOST:PORT/api/v1/alerts
   basic_auth:
   username: XXXX
   password: XXXX

Удаление Okagent

Остановите процесс Okagent. Для этого выполните одну из следующих команд:

• sudo /etc/init.d/okagent stop
• sudo service okagent stop
• sudo systemctl stop okagent.service && sudo systemctl disable okagent.service

Удалите файлы Okagent и скрипты запуска с помощью команды sudo rm -rf /usr/local/okagent /etc/init.d/okagent

Пометьте уведомление "no heartbeat" как обработанное (resolve)

Через трое суток хост будет перемещен в раздел inactive, а через 30 дней он будет автоматически удален.