diff --git a/docs/devlog.md b/docs/devlog.md
index 0b27109d..aee35bca 100644
--- a/docs/devlog.md
+++ b/docs/devlog.md
@@ -1,6 +1,91 @@
 
 ## 2023-02-25
 
+TODO: counters-and-metrics
+  Сделать механизм счётчиков и измерений на их основе.
+  Идея такая: счётчик заводится и каким-то образом
+  изменяется ( в зависимости от типа ). Наиболее вероятные
+  типы: Integer, Double.
+
+  Некий процесс производит измерения счётчиков в зависимости
+  от их типа/настроек. Например, средее за период. Скользящее
+  среднее. Изменение за период времени (TBD).
+
+  Счётчики могут быть доступны как в логе, так и удалённо
+  (RPC), для целей отладки.
+
+  Простейшее примение: watchdog. Смотрим на некую величину,
+  если она не меняется некоторое время (например, между
+  двумя запросами) --- следовательно, произошла авария
+  и нужно рестартовать сервис и/или рапортовать об
+  этом.
+
+  Что бы не таскать счётчики по монадам/публичным интерфейсам,
+  можно поступить с ними аналогично тому, как сделаны логи.
+
+  Счётчики должны быть максимально возможно быстрые и вносить
+  минимальные задержки в работу программы.
+
+  Задача разбивается на несколько частей:
+
+  1. Счётчик, показывающий текущиее состояние.
+     Пример, текущее значение потребления RAM.
+     Или текущее количество запросов.
+
+  2. Измерение, т.е некий процесс, который с заданной
+     периодичностью смотрит значение счётчика и что-то с ним
+     делает: например, считает скользящее среднее или
+     экспоненциальное среднее.
+
+  3. Вывод информации о счётчиках (Лог? RPC?)
+
+  4. Анализ информации о счётчиках
+
+  Пример, зачем нужен счётчик:  введём подпротокол
+  для измерения RTT, для использования в алгоритме
+  Congestion Control.
+
+  Еще пример, зачем нужен счётчик: заводим в каждом
+  процессе, который подозревается на наличие busyloop.
+  Смотрим скорость изменения счетчика. Если она больше
+  некоторого порога, определяемого периодичностью процесса,
+  следовательно, у нас busyloop.
+
+  Можно определять эти busyloop даже без явно заданного
+  порога, просто глядя на график от времени и обнаруживая
+  аномалии.
+
+  Порядок реализации:
+
+  1. драфт дизайна, включающий примеры использования
+  2. обсуждение
+  3. реализация
+
+  возможно, есть что-то готовое/полуготовое.
+
+  Во всякий там прометеус/графану и прочее подобное я не верю.
+  Но даже если и есть годное, можно адаптировать.
+
+  Счётчики это типичные временные ряды, можно их складывать
+  в ClickHouse.
+
+  Опять же, у нас нет цели поддерживать/мониторить целую огромную
+  инфраструктуру отрядом девопсов.
+
+  Цели две: отладка и реализация watchdog-ов, т.е нода должна сама,
+  своими силами анализировать счётчики и как-то справляться с
+  аномалиями.
+
+  То есть: пир состоит из двух (или чуть больше) независимых (forkOS)
+  потоков, один из которых делает работу, второй смотрит за первым,
+  и рестартует его, если надо.
+
+  Отдельно можно анализировать снапшоты данных метрик и скармливать
+  их в BDD, что бы строить деревья принятия решений: нормальная ситуация,
+  или требуется загасить/перезапустить ноду, или же речь вообще идёт о
+  DDoS атаке и надо обороняться --- банить каких-то пиров, например.
+
+
 FIXME: blocks-wip-inconsistency
   Иногда показывает blocks.wip не равный 0, когда
   блоки в действительности скачаны.