#483_GO_ODP_Q8

Что будет, если читать из закрытого канала в Golang?
Cколько значений возвращает одно чтение из канала?
А почему range-чтение из канала возвращает одно?


1. Что произойдет при чтении из закрытого канала в Go?

Канал в Go — это структура, предназначенная для обмена сообщениями между горутинами.
Закрытие канала обозначается операцией close(ch) и сигнализирует другим горутинам, что больше сообщений поступать не будет.

Читая из закрытого канала, произойдут следующие события:
Если канал пуст (все значения были прочитаны), попытка чтения вернет ноль-значение типа отправляемого каналом и признак конца канала (ok = false), например:

val, ok := <-ch
if !ok { // true if channel is closed and empty
  fmt.Println("Channel is closed")
}

Попытка записи в закрытый канал приведет к панике ("panic") во время исполнения.


2. Сколько значений возвращает одно чтение из канала?

Чтение из канала в виде одиночной операции вида <-ch возвращает ровно одно значение — само сообщение из канала.

Однако при таком подходе возникает проблема проверки состояния канала: невозможно определить, закрыт ли канал или просто временно пустой.
Поэтому в Go принято проверять состояние канала с помощью дополнительного оператора:

value, ok := <-channel

Здесь:
value — значение, извлеченное из канала.
ok — булево значение, показывающее, успешно ли произошло извлечение (true) или канал закрыт и пуст (false).

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


3. Почему range-операция чтения из канала возвращает одно значение?

Оператор range предназначен для последовательного считывания всех элементов коллекции, включая каналы.
Для каналов оператор range автоматически проверяет оба аспекта — наличие новых значений и закрытость канала.

Формат диапазона выглядит так:

for val := range ch {
  // обработка полученного значения
}

Обратите внимание, что здесь возвращается только одно значение — сам элемент канала.
Дополнительная проверка состояния канала (ok) внутри range не производится, поскольку range останавливается сразу после закрытия канала и отсутствия оставшихся значений.

Range-прочитывание прекращается автоматически, когда канал закрывают и извлекли все доступные данные.
Это делает цикл удобным и безопасным способом обработки потока данных из канала.
Однако важно помнить, что range читает последовательно и блокируется, пока не получит новое значение или не обнаружит конец канала.

#484_GO_ODP_Q9

Что будет, если писать в закрытый канал в Golang?
Можно ли закрывать канал со стороны читателя?
А если очень надо закрыть канал со стороны читателя — как быть?


Операции над закрытыми каналами в Go.

1. Что произойдет, если записать в закрытый канал?

Запись в закрытый канал вызывает ошибку паники («panic») с сообщением:

"send on closed channel"

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

package main

import "fmt"

func main() {
  ch := make(chan string)
  close(ch)      // Канал закрыт перед записью
  ch <- "test"  // Приведет к panic
}

Выполнение приведенного выше кода приведет к ошибке:

panic: send on closed channel

Паника остановит выполнение программы, если ее специально не обработать (например, с помощью конструкции defer-recovery).


2. Можно ли закрыть канал со стороны читателя?

Канал можно закрыть только со стороны писателя.
Операция close(channel) должна выполняться там, откуда происходят отправки данных в канал.
Читатель не имеет права самостоятельно закрыть канал, так как закрытие подразумевает завершение процесса передачи данных, а не получение.

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

Например, следующая ситуация недопустима:

// Неверно!
for v := range myChan {
  if someCondition(v) {
    close(myChan) // Нельзя! Паника произойдет позже
    break
  }
  process(v)
}

3. Если очень хочется закрыть канал со стороны читателя, как правильно поступить?

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

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

Пример такого подхода:

package main

import (
  "fmt"
  "sync"
)

func producer(out chan<- string, wg *sync.WaitGroup) {
  defer close(out)     // Писатель закрывает канал
  wg.Done()
  out <- "message1"
  out <- "message2"
}

func consumer(in <-chan string, done chan bool) {
  for msg := range in {
    fmt.Println(msg)
  }
  done <- true  // Уведомление о завершении потребителя
}

func main() {
  var wg sync.WaitGroup
  producerCh := make(chan string)
  doneCh := make(chan bool)

  wg.Add(1)
  go producer(producerCh, &wg)
  go consumer(producerCh, doneCh)

  wg.Wait()              // Ждем окончания производителя
  <-doneCh              // Ожидаем завершения потребления
}

В данном примере:
Производитель закрыл канал после передачи всех сообщений.
Потребитель завершил свое чтение, используя стандартный механизм циклов for-range.
Завершение потребителей контролируется отдельно, без попытки самостоятельного закрытия основного канала.

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

#485_GO_ODP_Q10

Как отсортировать массив структур по алфавиту по полю Name в Golang?
Какой стандартный пакет предназначен для сортировки любых слайсов? Как сделать из массива слайс?
Отсортируется ли массив при сортировке слайса?


Вопрос №1: Как отсортировать массив структур по алфавиту по полю Name в Go?

Допустим есть такой тип структуры:

type Person struct {
  Name string
  Age  int
}

И массив структур:

people := []Person{
  {"Bob", 30},
  {"Alice", 25},
  {"Charlie", 35},
}

Можно отсортировать этот массив по имени, используя стандартную библиотеку сортировок пакета sort:

package main

import (
  "fmt"
  "sort"
)

type Person struct {
  Name string
  Age  int
}

type ByName []Person

// Реализуем интерфейс sort.Interface для нашей структуры
func (a ByName) Len() int {
  return len(a)
}

func (a ByName) Swap(i, j int) {
  a[i], a[j] = a[j], a[i]
}

func (a ByName) Less(i, j int) bool {
  return a[i].Name < a[j].Name
}

func main() {
  people := []Person{
    {"Bob", 30},
    {"Alice", 25},
    {"Charlie", 35},
  }

  sort.Sort(ByName(people)) // Сортировка массива по имени
  fmt.Println(people)
}

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

[{Alice 25} {Bob 30} {Charlie 35}]

Вопрос №2: Какой стандартный пакет предназначен для сортировки любых слайсов?

Стандартный пакет для сортировки различных типов коллекций в Go — пакет sort.
Пакет sort предоставляет методы для сортировки практически любого типа коллекций (включая строки, числа, структуры и любые типы, реализующие интерфейс sort.Interface):

sort.Ints() — сортирует целочисленные слайсы.
sort.Strings() — сортирует строковые слайсы.
sort.Float64s() — сортирует слайсы чисел с плавающей точкой.
И многие другие полезные утилиты.

Кроме того, если тип данных нестандартный (например, ваша собственная структура), потребуется реализовать интерфейс sort.Interface, состоящий из трех методов:
Len() — длина слайса.
Swap(i, j int) — обмен двух элементов местами.
Less(i, j int) — сравнение двух элементов (возвращает true, если первый меньше второго).


Вопрос №3: Как сделать из массива слайс?

Массив в Go представляет собой последовательность фиксированной длины, тогда как слайс — динамическая коллекция произвольной длины.

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

arr := [...]int{1, 2, 3, 4, 5}  // Массив фиксированной длины
slice := arr[:]  // Преобразование массива в слайс

Теперь переменная slice является полноценным слайсом, основанным на исходном массиве.


Вопрос №4: Отсортируется ли массив при сортировке слайса?

ДА, массив будет также отсортирован вместе со слайсом, потому что слайс в Go фактически ссылается на тот же базовый массив памяти.
Изменяя порядок элементов в слайсе, изменяется и оригинальный массив, на который он указывает:

arr := [...]int{3, 1, 4, 1, 5}
slice := arr[:]
sort.Ints(slice) // Сортируем слайс
fmt.Println(arr) // Выведем содержимое массива

Результат:

[1 1 3 4 5]

Изменение порядка элементов в слайсе повлияло и на массив, так как они разделяют одну область памяти.

#486_GO_ODP_Q11

Что такое сериализация в Golang?
Зачем нужна сериализация?
Почему нельзя для сериализации какой-либо переменной просто взять дамп занимаемой ею памяти?


1. Что такое сериализация в Go?

Сериализация — процесс преобразования сложных объектов (структур, слайсов, карт и др.) в последовательность байтов (строку, JSON, XML, бинарный формат и т.п.).
Основная цель сериализации заключается в возможности легко передавать объекты по сети, сохранять их в файл или базу данных и восстанавливать обратно в первоначальную форму (десериализация).

Сериализация помогает упаковывать данные в удобный формат для хранения или транспортировки, а десериализация восстанавливает эти данные обратно в объект.

Примеры популярных форматов сериализации в Go:
JSON (encoding/json)
XML (encoding/xml)
Protocol Buffers (google.golang.org/protobuf)
Binary Marshalling (encoding/gob)

Go предоставляет удобные встроенные механизмы для быстрой сериализации различных структур данных в различные форматы.

Пример сериализации структуры в JSON:

package main

import (
  "encoding/json"
  "fmt"
)

type User struct {
  ID int `json:"id"`  // Поле ID станет id в JSON
  Username string `json:"username"`  // Поле Username станет username в JSON
  Email string `json:"-"`  // Поле Email игнорируется в JSON
}

func main() {
  user := User{ID: 1, Username: "john_doe", Email: "johndoe@example.com"}
  jsonData, err := json.Marshal(user)
  if err != nil {
    panic(err)
  }
  fmt.Println(string(jsonData)) // {"id":1,"username":"john_doe"}
}

В результате получаем строку JSON, которую можно отправить по HTTP-запросу или сохранить в файле.


2. Зачем нужна сериализация?

Основные причины использования сериализации:
Передача данных — когда данные отправляются по сети, они должны быть представлены в удобном переносимом формате, понятном обеим сторонам коммуникации.
Хранение данных — данные сохраняются в файлах или базах данных. Без сериализации было бы сложно хранить сложные структуры, такие как вложенные объекты, карты или массивы.
Совместимость платформ — различные ЯП и платформы могут иметь разные представления данных в памяти. Сериализация обеспечивает общий формат обмена информацией независимо от языка или ОС.


3. Почему нельзя просто скопировать память объекта для сериализации?

Хотя идея просто создать дамп памяти кажется привлекательной, такая практика не подходит по нескольким причинам:
Несоответствие платформ — формат внутреннего представления данных различается между архитектурами и ЯП. Даже простое число или строка может храниться в памяти по-разному (endianness, выравнивание данных и т.д.).
Разница в структуре данных — типы данных, используемые одной программой, могут быть неизвестны другой программе. Например, одно приложение использует структуру определенного формата, а другое приложение ожидает совершенно иной формат.
Безопасность и целостность — внутреннее представление данных может содержать скрытые детали или метаданные, которые нежелательно отправлять другим приложениям или пользователям. Эти данные могут повлиять на безопасность или привести к некорректной интерпретации.
Проблемы совместимости версий — представьте, что обновили структуру данных в программе, добавив новые поля. Старые версии приложения не смогут интерпретировать новый формат дампа памяти.
Перегрузка ресурсов — создание полного дампа памяти требует больших объемов данных и увеличивает нагрузку на сеть или систему хранения.

Поэтому использование стандартных механизмов сериализации, таких как JSON, XML или protobuf, значительно упрощает взаимодействие между системами и минимизирует риск ошибок.

#487_GO_ODP_Q12

Сколько времени в минутах занимает написание процедуры обращения односвязного списка в Golang?
Какие тесты можно написать для проверки процедуры разворачивания односвязного списка?


Среднее время, необходимое для написания подобной процедуры, варьируется от нескольких минут до примерно 15–20 минут в зависимости от следующих факторов:
Уровень опыта программиста.
Необходимость оптимизировать код.
Наличие предварительных тестов и вспомогательных функций.

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


Тестирование крайне важно для уверенности в работоспособности и правильности процедуры разворота односвязного списка.

Ключевые тест-кейсы, которые полезно включить в набор тестов:

Базовая функциональность:

    Список с одним элементом
        Вход: [1]
        Выход: [1]

    Список с двумя элементами
        Вход: [1 → 2]
        Выход: [2 → 1]

    Средний размер списка
        Вход: [1 → 2 → 3 → 4 → 5]
        Выход: [5 → 4 → 3 → 2 → 1]

    Пустой список
        Вход: []
        Выход: []

    Списки с повторяющимися значениями
        Вход: [1 → 1 → 1 → 1]
        Выход: [1 → 1 → 1 → 1]

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

    Деструктивные изменения
        После разворота список остается неизмененным (т.е., не создает копию, а меняет связи узлов).

    Проверка устойчивости к неправильным входным данным
        Список с неправильно сформированными связями (например, разрыв цепочки связей).

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

package linkedlist_test

import (
  "testing"
)

// Структура узла односвязного списка
type ListNode struct {
  Value int
  Next  *ListNode
}

// Процедура обратного хода односвязного списка
func ReverseLinkedList(head *ListNode) *ListNode {
  var prev *ListNode
  current := head
  for current != nil {
    nextTemp := current.Next
    current.Next = prev
    prev = current
    current = nextTemp
  }
  return prev
}

// Вспомогательная функция для создания списка
func createList(values []int) *ListNode {
  dummyHead := new(ListNode)
  current := dummyHead
  for _, val := range values {
    current.Next = &ListNode{Value: val}
    current = current.Next
  }
  return dummyHead.Next
}

// Тестирование процедура перевода списка
func TestReverseLinkedList(t *testing.T) {
  testCases := []struct {
    name            string
    inputValues     []int
    expectedOutput  []int
  }{
    {"Empty list", []int{}, []int{}},
    {"Single element", []int{1}, []int{1}},
    {"Two elements", []int{1, 2}, []int{2, 1}},
    {"Multiple elements", []int{1, 2, 3, 4, 5}, []int{5, 4, 3, 2, 1}},
    {"Repeated values", []int{1, 1, 1, 1}, []int{1, 1, 1, 1}},
  }

  for _, tc := range testCases {
    t.Run(tc.name, func(t *testing.T) {
      head := createList(tc.inputValues)
      reversedHead := ReverseLinkedList(head)

      actualValues := make([]int, 0)
      for reversedHead != nil {
        actualValues = append(actualValues, reversedHead.Value)
        reversedHead = reversedHead.Next
      }

      if len(actualValues) != len(tc.expectedOutput) || !equalSlices(actualValues, tc.expectedOutput) {
        t.Errorf("Test failed for input: %v. Expected output: %v, but got: %v",
          tc.inputValues, tc.expectedOutput, actualValues)
        }
      })
  }
}

// Вспомогательная функция сравнения слайсов
func equalSlices(a, b []int) bool {
  if len(a) != len(b) {
    return false
  }
  for i := range a {
    if a[i] != b[i] {
      return false
    }
  }
  return true
}

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

#488_GO_ODP_Q13

Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется в Golang?
Почему?
Что такое tight coupling?
Почему это плохо?
В каком варианте связанность слабее?


1. Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется в Go?

Интерфейс лучше всего размещать там, где он используется.

Преимущества размещения интерфейсов там, где они используются:
Чистота абстракций — интерфейсы являются способом выражения требований одного пакета другому.
Размещая интерфейс рядом с кодом, который его использует, мы ясно показываем требования, предъявляемые другим пакетам.
Предположим, что есть пакет database, который реализует различные методы взаимодействия с базой данных.
Пакет, использующий базу данных (users), должен определить интерфейс базы данных внутри себя.
Это позволит избежать жесткой зависимости от конкретной реализации базы данных и обеспечит возможность замены одной реализации другой без изменения кода приложения.

// users/persistence.go
package users

type UserRepository interface {
  GetUserByID(id int) (*User, error)
}

Таким образом, реализация интерфейса размещается отдельно, в пакете database:

// database/mysql_repo.go
package database

import (
  "github.com/yourproject/users"
)

type MySQLRepo struct{}

func (r *MySQLRepo) GetUserByID(id int) (*users.User, error) {
  // Реализация метода для MySQL
}

Гибкость изменений — если интерфейс изменяется, такие изменения затрагивают лишь тот пакет, где он объявлен.
Все пакеты, реализующие этот интерфейс, могут адаптироваться независимо друг от друга.
Тестируемость — возможность легко заменить реализацию интерфейса позволяет писать тесты, заменяя реальные объекты тестовыми двойниками.


2. Что такое тесная связность (tight coupling)?

Tight coupling — ситуация, когда компоненты системы сильно зависят друг от друга.
Компоненты тесно связаны, если изменение одного компонента неизбежно влечет за собой необходимость внесения изменений в другие компоненты.

Рассмотрим два класса A и B, где класс A жестко зависит от методов и структуры класса B:

type A struct {
  b *B
}

func NewA(b *B) *A {
  return &A{b: b}
}

func (a *A) DoSomething() {
  a.b.DoAction()
}

Здесь класс A строго привязан к классу B, поскольку A ожидает конкретный тип объекта B и конкретные методы.


3. Почему тесная связность плоха?

Причины, почему тесная связность нежелательна:
Трудности поддержки и модификации — любое изменение в одном компоненте требует обновления всех зависимых компонентов. Это делает систему менее гибкой и увеличивает риск ошибок.
Ухудшение повторного использования — когда классы тесно связаны, трудно повторно использовать один класс без другого. Классы становятся частью единого целого, и замена одной части становится невозможной без ущерба для всей системы.
Проблемы тестирования — тестирование отдельных компонентов затруднено, потому что каждый компонент полагается на поведение другого.
Создание тестов усложняется необходимостью эмулирования поведения связанных классов.


4. Какой вариант связанности слабее?

Рассмотрим две ситуации:

Пример 1: Tight Coupling

type Engine struct {}

type Car struct {
  engine *Engine
}

func (c *Car) Start() {
  c.engine.Start()
}

Здесь класс Car жёстко привязан к типу *Engine. Изменение реализации двигателя потребует изменения класса автомобиля.

Пример 2: Loose Coupling
Используем интерфейс для ослабления связи между компонентами:

type EngineInterface interface {
  Start() error
}

type Car struct {
  engine EngineInterface
}

func (c *Car) Start() error {
  return c.engine.Start()
}

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

Интерфейсы следует помещать в тех местах, где они используются, чтобы обеспечить ясность требований и независимость реализации.
Тесная связь (tight coupling) возникает, когда компоненты системы сильно зависят друг от друга.
Тесная связь затрудняет поддержку, тестирование и повторное использование компонентов.
Ослабление связей достигается использованием интерфейсов и принципов проектирования, таких как Dependency Inversion Principle (Принцип Инверсии Зависимости).

#489_GO_ODP_Q14

Предположим, функция должна возвращать детализированные Recoverable и Fatal ошибки. Как это реализовано в пакете net?
Как это надо делать в современном Go? что нового и важного в плане обработки ошибок появилось начина с Go 1.13?
А чего не появилось, хоть мы и ждали?


Типичные случаи использования ошибок в пакете net.

Стандартный пакет net часто возвращает значения, используя встроенный тип error.
Однако, начиная с определённых версий Go, разработчикам предоставляется возможность получать дополнительную информацию об ошибке благодаря расширенным возможностям пакета errors и возможности обернуть одну ошибку другой.

Типичный пример из пакета net выглядит следующим образом:

conn, err := net.Dial("tcp", ":80")
if err != nil {
  log.Fatal(err)
}

Однако важно отметить, что многие ошибки имеют внутреннюю структуру, которую можно исследовать с помощью методов проверки типов (например, errors.Is() и errors.As()):

err = someNetworkOperation()
if errors.Is(err, os.ErrExist) {
  fmt.Println("File already exists.")
}

Этот подход даёт нам механизм классификации ошибок по содержимому и семантике, сохраняя при этом простоту конструкции обычного error.


Как правильно обрабатывать детализированные ошибки (Recoverable и Fatal).
Современный подход к обработке ошибок включает разделение ошибок на разные категории, такие как recoverable («исправимые») и fatal («фатальные»).


Правильная обработка этих категорий важна для устойчивости приложений.

1. Подход с помощью интерфейсов и структурированных ошибок.
Хорошей практикой является создание собственных специализированных типов ошибок, которые позволяют отличить recoverable ошибки от fatal:

type RecoverableError struct {
  Err error
}

type FatalError struct {
  Err error
}

func (re *RecoverableError) Error() string { return re.Err.Error() }
func (fe *FatalError) Error() string       { return fe.Err.Error() }

// Пример возврата ошибки
func SomeFunction() error {
  if somethingBadHappened {
    return &RecoverableError{Err: errors.New("something bad happened")}
  }
  if reallyBadHappened {
    return &FatalError{Err: errors.New("really bad thing happened")}
  }
  return nil
}

Затем можно проверять тип ошибки и реагировать соответствующим образом:

err := SomeFunction()
switch e := err.(type) {
case *RecoverableError:
  fmt.Printf("Recovered from %v\n", e)
case *FatalError:
  panic(e)
default:
  fmt.Println("Unknown error:", err)
}

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


2. Использование стандартных функций Go для детальной обработки ошибок.
Начиная с Go 1.13 появились новые стандартные инструменты для улучшения диагностики и управления ошибками:
Функция errors.Unwrap — позволяет извлекать вложенные ошибки, созданные функцией fmt.Errorf("%w", ...).
Функции errors.Is и errors.As — помогают сравнивать типы ошибок и извлекать детали внутренних ошибок соответственно.

Примеры:

err := someNetOp()
var connRefused net.AddrError
if errors.As(err, &connRefused) && connRefused.Temporary() {
    fmt.Println("Temporary connection refused:", connRefused.Err)
}

Новшества в Go 1.13 и далее касательно обработки ошибок.
Ключевые нововведения в Go, касающиеся обработки ошибок:
Поддержка упаковки ошибок с указанием контекста (%w) — начиная с Go 1.13 появилась поддержка специальной директивы %w в функции fmt.Errorf, позволяющей сохранять исходную ошибку вместе с новой информацией. Эта ошибка доступна через метод Unwrap():

wrappedErr := fmt.Errorf("failed to open file: %w", os.ErrPermission)

Расширенная диагностика ошибок с помощью errors.Is и errors.As — эти функции позволяют точнее анализировать ошибки и определять их происхождение, особенно полезно для стандартных библиотек вроде os и net.

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

import "runtime/debug"

debug.PrintStack()

.

Разделение ошибок на категории через упаковку и проверку типов — используя новую функциональность fmt.Errorf и встроенные механизмы проверки типов, стало проще создавать специализированные обработчики ошибок.


Чего не произошло (ожидаемые новшества):
Несмотря на появление новых инструментов, некоторые ожидаемые расширения функциональности пока не были внедрены официально:
Автоматическое отслеживание места возникновения ошибки — многие разработчики ожидали автоматического сохранения информации о месте возникновения ошибки аналогично Python’овому traceback. Пока эта функциональность не была введена.
Более выразительные средства для сопоставления типов ошибок — хотя функции Is и As значительно улучшили диагностику, иногда хотелось бы иметь ещё больше возможностей по сравнению разных видов ошибок без ручной распаковки.
Структурированные ошибки как объект первой важности — несмотря на улучшение в диагностике и упаковке, базовые примитивы всё ещё остаются довольно простыми, без официальной поддержки высокоуровневых механизмов обработки ошибок, аналогичных модели исключений в других ЯП.


Основные рекомендации:
Используйте механизмы группировки ошибок с помощью специальных типов (типа RecoverableError и FatalError).
Применяйте стандарты, введённые в Go 1.13, такие как %w, errors.Is и errors.As, для лучшей диагностики.
По мере развития проекта старайтесь придерживаться единообразия в подходе к работе с ошибками, обеспечивая лёгкую обработку и восстановление после проблем.

#490_GO_ODP_Q15

Главный недостаток стандартного логгера в Golang?
Каково основное применение информации из логов?


Недостатки стандартного логгера Go (log package).
Стандартный пакет log в Go обладает несколькими ключевыми недостатками:
Отсутствие структурированного вывода — стандартный логгер пишет данные в виде обычного текста, что делает извлечение и последующий анализ сложной задачей.
Нет встроенной поддержки формата JSON или другого способа представления структуры данных, удобной для машинной обработки.
Ограниченный уровень детализации — логгер поддерживает лишь простейшие уровни (panic, fatal, print), тогда как современные приложения требуют больше градации: trace, debug, info, warn, error, fatal.
Невозможность фильтрации — невозможно настроить вывод отдельных категорий сообщений, что важно для высоконагруженных систем. Сообщения пишутся сразу в поток без предварительной сортировки.
Нет ротации файлов логов — если объем логов велик, стандартная библиотека не способна автоматически вращать файлы логов, удалять старые или создавать архивы.
Недостаточная поддержка многопоточности — несмотря на поддержку потоков в Go, стандартный логгер не оптимизирован для параллельных сценариев. Синхронизация осуществляется блокировкой всей файловой записи, что снижает производительность в многопоточных приложениях.


Информация из логов применяется в следующих ключевых областях:
Диагностика и отладка — важнейшая задача логирования — фиксация деталей возникновения ошибок и сбоев.
Программист получает представление о состоянии приложения в конкретный момент времени, помогающее быстро диагностировать проблему.
Мониторинг состояния и производительности — по данным логов удобно анализировать состояние системы, проверять загрузку ресурсов, идентифицировать узкие места и планировать дальнейшее развитие инфраструктуры.
Безопасность и аудит — логи играют центральную роль в защите данных и контроле за действиями пользователей. Фиксация попыток взлома, изменение привилегий, выполнение административных команд позволяет своевременно реагировать на возможные инциденты.
Сбор статистики и аналитика — посредством логов можно собирать статистику о действиях пользователей, популярности сервисов, частоте обращений к ресурсам и многое другое, что полезно для улучшения продукта и понимания потребностей клиентов.


Стандартный логгер в Go недостаточно эффективен для большинства промышленных проектов, требующих продвинутых возможностей логирования.
Для серьезных решений лучше использовать сторонние библиотеки вроде Logrus, Zap или Kataras/iris.

#491_GO_ODP_Q16

Есть ли для Go хороший orm?
Что означает буква M в аббревиатуре ORM?
Как устроен GORM?
Что на букву M есть в GORM?
Что такое DAL и зачем он нужен?


Есть ли для Go хороший ORM?
Да, для Go существует несколько популярных ORM-фреймворков, среди которых наиболее известны следующие:
GORM — один из самых популярных и широко используемых ORM для Go. Поддерживает различные базы данных, такие как PostgreSQL, MySQL, SQLite, SQL Server и другие. Обладает высокой производительностью и гибкостью настройки.
SQLX — библиотека, расширяющая стандартный пакет database/sql, добавляет удобные методы для работы с базой данных и поддерживает автоматическое отображение полей структуры Go на столбцы таблицы БД.
ENT — современный ORM с поддержкой автоматического создания схемы и миграций, предлагает удобный API для CRUD операций и мощное построение запросов.

Каждый из этих инструментов имеет свои преимущества и подходит под разные сценарии разработки приложений.


Что означает буква M в аббревиатуре ORM?
Буква "M" в аббревиатуре ORM расшифровывается как Mapping, что переводится на русский как "отображение".
Полная расшифровка звучит как Object-Relational Mapping.
Это технология, позволяющая разработчику оперировать объектами ЯП (например, структурами в Go), которые автоматически сопоставляются с таблицами и полями реляционной БД.

Основная цель ORM — упростить работу с базами данных путем предоставления удобного API для взаимодействия с ними, минимизируя необходимость написания большого объема рутинного SQL-кода вручную.


Как устроен GORM?

GORM — представляет собой легкую библиотеку, предоставляющую мощный набор функций для работы с реляционными БД в Go.

Основные особенности и принципы устройства:
Поддержка различных СУБД — GORM совместим с популярными СУБД, как PostgreSQL, MySQL, SQLite, SQL Server и др.
Автоматическое отображение структур на таблицы — структуры Go легко преобразуются в таблицы БД. Поля структуры становятся колонками, а сама структура — таблицей.
Простота использования — предоставляет простой интерфейс для CRUD-операций (создание, чтение, обновление, удаление записей).
Миграции и авто-миграционные возможности — позволяет автоматически создавать схему базы данных на основе структур Go.
Производительность — благодаря использованию нативных драйверов баз данных, обеспечивает высокую производительность.
Расширяемость — легко интегрируется с различными middleware-компонентами, обеспечивая дополнительную функциональность, такую как ведение журнала, транзакционная поддержка и кэширование.

GORM спроектирован таким образом, чтобы минимизировать накладные расходы на обработку запросов и обеспечить удобное взаимодействие с БД даже для начинающих разработчиков.

.

Что на букву M есть в GORM?

Буква "M" в терминологии ORM обозначает mapping, т.е. процесс преобразования объектов Go в записи базы данных и наоборот. В GORM этот аспект реализуется следующим образом:
Отображение структур на таблицы — каждая структура Go связывается с определенной таблицей в базе данных. Имена полей структуры соответствуют именам столбцов в таблице.
Настройка отображений — разработчик может настраивать поведение отображения через аннотации (так называемые tags) в структуре, например, задавая правила сериализации/десериализации, устанавливая связи между моделями ("один ко многим", "многие ко многим") и определяя уникальные ключи.
Запросы и манипуляции — библиотека автоматически генерирует соответствующие SQL-запросы на основе действий над объектами Go (например, сохранение объекта приведет к вставке новой строки в таблицу).

Эти механизмы позволяют писать приложения с минимальным количеством SQL-кода и сосредоточиваться непосредственно на бизнес-логике проекта.


Что такое DAL и зачем он нужен?

DAL (Data Access Layer) — слой доступа к данным.
Этот уровень программного обеспечения предназначен для изоляции уровня хранения данных от остальной части системы.
Основная задача DAL — предоставление стандартного интерфейса для взаимодействия с хранилищем данных (обычно база данных), скрывая детали реализации конкретного хранилища (тип базы данных, SQL-запросы и т.п.).

Основные цели использования DAL:
Изоляция деталей работы с БД — код основного приложения не зависит от конкретной базы данных или формата хранимых данных.
Упрощение поддержки и тестирования — возможность замены одного механизма доступа к данным другим без изменения основной бизнес-логики приложения.
Улучшение производительности и масштабируемости — возможность добавления оптимизаций (кэширование, индексы, оптимизация запросов) на уровне слоя доступа к данным без затрагивания остальных частей приложения.

Примеры слоев DAL включают библиотеки вроде ORM (например, GORM), адаптеры к различным источникам данных, специализированные сервисы обработки данных и промежуточные слои между моделью предметной области и уровнем данных.


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

#492_GO_ODP_Q17

Какие линтеры применят для работы с Golang?
Какое отношение линтеры имеют к CI?
Зачем нужен CI в процессе разработки?


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


Стандартные инструменты:
go vet — проверяет синтаксические ошибки, подозрительные конструкции и возможные баги в коде.
Включается стандартным инструментом компилятора Go.
golint — анализирует соблюдение стиля кода согласно рекомендациям сообщества Go (имена переменных, функций и пакетов).
Не находит критичных ошибок, помогает соблюдать стандарты.
errcheck — линтер, проверяющий правильность обработки ошибок в программе.
Подчеркивает места, где игнорируются возвращаемые ошибки.
staticcheck — статический анализатор, обнаруживающий проблемные участки, ненужные проверки, неиспользуемые поля и т.д.
Помогает находить проблемы до запуска тестов.
ineffassign — отмечает неэффективные присваивания переменным, которые впоследствии нигде не используются.
megacheck — объединяет несколько линтеров (staticcheck и ineffectual assign) в одном инструменте.
misspell — инструмент для обнаружения опечаток в комментариях и строковых литералах.


Дополнительные инструменты:
govet — встроенный инструмент для анализа кода (аналогичен go vet, но часто используется отдельно).
testify — фреймворк для юнит-тестирования, включает полезную утилиту assert для улучшения читаемости тестового кода.
depguard — контролирует зависимости проекта, предотвращает использование нежелательных внешних библиотек.
varcheck — ищет неиспользованные локальные переменные.
deadcode — отслеживает неиспользованный код, удаляя мертвые функции и пакеты.


Какое отношение линтеры имеют к CI?

CI (Continuous Integration — непрерывная интеграция) — методология регулярного выполнения автоматизированных сборок и тестов после каждого коммита или определённых интервалов времени.
Линтеры — важная часть процесса CI, поскольку выполняют предварительную проверку качества кода перед запуском сборки и тестирования.


Связь линтеров и CI:
Автоматизированные проверки с использованием линтеров выполняются в рамках пайплайна CI, что позволяет выявить проблемы с качеством кода, стилем или потенциальными ошибками.
Интеграция линтеров гарантирует единообразие стиля и улучшает качество кода, снижая риск появления багов и затруднений в поддержке проекта.
Многие CI-платформы (Jenkins, GitLab CI, CircleCI, Travis CI) поддерживают запуск линтеров автоматически вместе с этапами сборки.


Зачем нужен CI в процессе разработки?

Непрерывная интеграция направлена на повышение эффективности командной работы и снижение рисков, связанных с интеграцией новых изменений в проект.


Основные причины важности CI:

Преимущества CI:
Быстрая обратная связь — каждое изменение проходит серию проверок, включая тесты и линтеры, что позволяет получать уведомления о проблемах и оперативно устранять их.
Обнаружение конфликтов заранее — частые интеграции уменьшают вероятность возникновения крупных конфликтов при объединении ветвей, особенно в больших командах.
Повышение качества кода — регулярные проверки с помощью линтеров и тестов обеспечивают высокий уровень качества и снижают количество дефектов.
Минимизация риска регрессий — тесты и проверка покрытия показывают, что новые изменения не нарушили существующие функциональные возможности.
Автоматизация процессов — автоматизация этапов сборки, тестирования и деплоймента экономит время и снижает нагрузку на разработчиков.
Постоянная готовность к релизу — постоянная интеграция и тестирование делают продукт готовым к выпуску, сокращая задержку между разработкой и релизом.

CI существенно ускоряет разработку и уменьшает риски внесения ошибок в систему, повышая стабильность и надёжность продукта.

#493_GO_ODP_Q18

Можно ли использовать один и тот же буфер []byte в нескольких горутинах?
Зачем может понадобиться использовать один и тот же буфер []byte в нескольких горутинах параллельно?
Что именно будем в защищать мьютексом в общем буфере?


Нет, напрямую нельзя безопасно использовать один и тот же срез байтов []byte одновременно несколькими горутинами без синхронизации.
Причина в том, что одновременный доступ к одному и тому же ресурсу (особенно запись) может привести к состоянию гонки (race condition), когда одна goroutine перезаписывает данные другой goroutine.

Однако можно обезопасить такой доступ с помощью механизмов синхронизации, таких как мьютексы (sync.Mutex), каналы (channel) или атомарные операции (atomic package).
Использование мьютекса позволит организовать безопасный параллельный доступ к общему буферу.


Зачем может понадобиться использовать один и тот же буфер []byte в нескольких горутинах параллельно?

Параллельное использование общего буфера может потребоваться в следующих ситуациях:
Разделение ресурсов памяти — когда общая память ограничена, и желательно уменьшить потребление оперативной памяти путём совместного использования одной большой области памяти разными частями программы.
Оптимизация производительности — общий буфер может использоваться для организации конвейеров обработки данных.
Одна goroutine записывает данные в буфер, другая считывает их оттуда, организуя параллельную обработку.
Буферизация данных — буферы могут служить для временного хранения результатов, полученных асинхронно, пока не завершатся другие этапы обработки.

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


Что именно будем защищать мьютексом в общем буфере?
Защищать придётся любую операцию, которая изменяет состояние буфера, а именно:
Операции записи (запись данных в буфер).
Операции чтения (чтение данных из буфера), если возможна ситуация конкурентного доступа на чтение и запись одновременно.

Пример безопасного использования буфера с мьютексом:

package main

import (
  "fmt"
  "sync"
)

func main() {
  var buffer []byte
  bufferMutex := sync.Mutex{}

  go func() {
    for i := 0; i < 10; i++ {
      bufferMutex.Lock()
      defer bufferMutex.Unlock()
      buffer = append(buffer, byte(i))
    }
  }()

  go func() {
    for len(buffer) < 10 {
      bufferMutex.Lock()
      if len(buffer) > 0 {
        fmt.Printf("%d\n", buffer[len(buffer)-1])
        buffer = buffer[:len(buffer)-1]
      }
      bufferMutex.Unlock()
    }
  }()

  // Ждём завершение всех горутин
  wg := &sync.WaitGroup{}
  wg.Add(2)
  wg.Done()
  wg.Done()
  wg.Wait()
}

Здесь обе горутины используют общую область памяти (buffer), защищённую мьютексом.
Мьютекс блокирует доступ к общим ресурсам во избежание состояний гонок.

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

#494_GO_ODP_Q19

Какие типы мьютексов предоставляет stdlib Golang?
Что именно и от чего защищает мьютекс?


Библиотека stdlib Go предлагает два основных типа мьютексов:

1. Mutex (sync.Mutex) — стандартный блокирующий мьютекс.
Когда один горутин захватывает мьютекс, другие горутины будут ожидать освобождения блокировки перед продолжением своей работы.
Используется для защиты совместного ресурса от одновременного доступа несколькими горутинами:

import (
  "sync"
)

var mu sync.Mutex

func main() {
  mu.Lock()
  defer mu.Unlock()
}

Что защищает?
Мьютекс обеспечивает исключительный доступ к критическим секциям кода или ресурсам (например, переменным), предотвращая конфликты между параллельными потоками исполнения (горутинами).


2. RWMutex (sync.RWMutex) — читательско-писательский мьютекс.
Позволяет нескольким читателям одновременно получать доступ к защищаемому ресурсу, но запись разрешена только одному писателю единовременно.
Это повышает производительность в ситуациях, когда чтение чаще встречается, чем запись:

import (
  "sync"
)

var rwmu sync.RWMutex

func read() {
  rwmu.RLock()
  defer rwmu.RUnlock()
}

func write() {
  rwmu.Lock()
  defer rwmu.Unlock()
}

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


Оба типа мьютексов предназначены для предотвращения гонки данных (data race condition).
Они обеспечивают безопасность конкурентного доступа к разделяемым данным путём временной блокировки ресурсов, гарантируя целостность и согласованность состояния программы.

#495_GO_ODP_Q20

Что такое lock-free структуры данных, и есть ли в Go такие?
Что такое atomic?
Что такое sync.Map?
Sync.Map — lock-free или нет?


Lock-Free структура данных — тип параллельной структуры данных, обеспечивающий согласованность состояния между потоками без блокировки критической секции мьютексами (mutex).
Это означает, что даже если один поток временно приостановлен или блокирован (например, вызванное ожидание ввода-вывода), другие потоки всё равно смогут продолжить свою работу с данной структурой данных без ожидания освобождения ресурса.
Такая конструкция улучшает производительность многопоточных приложений, снижая вероятность возникновения узких мест.

Однако lock-free алгоритмы сложнее проектировать и поддерживать, поскольку требуют тщательной синхронизации на уровне атомарных операций.


Atomic.
В Go пакет sync/atomic обеспечивает доступ к примитивам атомарных операций над базовыми типами данных (uint32, uint64, uintptr), позволяя избежать необходимости в обычных мьютексах для простых операций типа чтения-загрузки, записи-хранения и арифметики:

import "sync/atomic"

// Загрузка значения атома
value := atomic.LoadUint32(&val)

// Установка нового значения атома
atomic.StoreUint32(&val, newValue)

// Атомарная операция сравнения и обмена (CAS)
if atomic.CompareAndSwapUint32(&val, oldVal, newVal) {
  // Обмен успешно выполнен
}

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


Sync.Map.
Тип sync.Map представляет собой многопоточную карту (ассоциативный массив), оптимизированную для высококонкурентных сред.

Основные характеристики:
Гарантированная безопасность конкурентности (не требует ручного управления мьютексами).
Оптимизация производительности для случаев интенсивного чтения.
Поддерживает неблокирующие итерации по карте (чтение значений одновременно несколькими потоками).


Является ли sync.Map lock-free?
Нет, sync.Map формально не является lock-free.
Однако, его реализация внутренне разделяет состояние карты таким образом, что чтение выполняется быстро и эффективно, используя минимальные блокировки лишь при изменении состояния карты (запись новых элементов или удаление существующих).
Таким образом, хотя технически он основан на блокировках (использует внутренний мьютекс), его использование минимизирует влияние конкуренции потоков, приближаясь по поведению к lock-free алгоритмам.


Lock-free — обеспечение конкурентного доступа без классических блокировок.
Atomic — набор низкоуровневых атомарных операций, предоставляющих безопасный доступ к данным в параллельном окружении.
Sync.Map — многопоточная карта, использующая внутренние блокировки для изменения состояния, но высокоэффективна благодаря минимальной конкуренции.


Таким образом, несмотря на наличие внутренней блокировки, sync.Map спроектирована так, чтобы минимизировать её влияние на общую производительность программы.

#496_GO_ODP_Q21

Способы поиска проблем производительности на продакшене? Какие проблемы производительности вы знаете?
Может ли быть так, что потребление ресурсов (CPU, RAM, disk/net bandwidth) вполне умеренное, а пользователи жалуются на «тормоза»?
На что, чаще всего, жалуются пользователи, и как это связано с тем, что вы видите в системе?


Способы поиска проблем производительности на продакшене:

Мониторинг метрик системы — включает сбор и визуализацию различных показателей серверов и приложений:
Load Average — средняя нагрузка на систему.
Использование CPU, памяти (RAM), дисков (I/O), сети (bandwidth).
Количество активных процессов, соединений TCP/IP, очередь запросов базы данных и др.

Инструменты мониторинга:
Prometheus + Grafana, Zabbix, New Relic, Datadog.


Логирование ошибок и предупреждений — анализ лог-файлов помогает выявить узкие места приложения:
Ошибки HTTP-запросов (5xx, 4xx).
Таймауты запросов (request timeouts).
Исключение исключений внутри сервера.
Медленные SQL-запросы.

Средства анализа логов:
ELK Stack (Elasticsearch+Logstash+Kibana), Graylog, Splunk.


Профилирование нагрузки и трассировка запросов — позволяет измерять производительность отдельных компонентов системы:
Tracing — понимание пути выполнения запросов от клиента до бэкенд-сервисов и обратно.
Трассировка конкретных операций (SQL-запросы, внешние API-вызовы).

Средства профилирования:
Zipkin, Jaeger, Pinpoint, OpenTelemetry.


Анализ зависимостей и взаимодействий сервисов — при распределенной архитектуре важно отслеживать зависимости между сервисами:
Задержки передачи данных между микросервисами.
Пропускная способность каналов связи (сетевые задержки).
Блокировки транзакций в базах данных.


APM (Application Performance Monitoring) — комплексные решения позволяют мониторить сразу несколько аспектов:
Время отклика страниц/API.
Нагрузка на серверы.
Производительность фронтенда.

Примеры инструментов:
AppDynamics, Dynatrace, Lightstep.


Проблемы производительности:

High Load Average — высокая загрузка процессора из-за чрезмерного количества потоков или блокировок (например, lock contention).
Медленная база данных — недостаточная индексация таблиц, плохие запросы, нехватка ресурсов БД (slow queries, deadlocks).
Нехватка оперативной памяти — большое количество объектов в памяти (memory leaks), недостаточный объем выделенного ресурса (OOM issues).
Недостаточная пропускная способность сети — перегруженность сетевых интерфейсов, низкая скорость чтения/записи файлов.
Высокая задержка I/O (disk I/O latency) — низкая производительность жестких дисков или SSD, медленное чтение записей.
Проблемы масштабирования — неправильно настроенная балансировка нагрузки, недостаток реплик, плохо подобранное горизонтальное масштабирование.
Ошибка конфигураций — некорректные настройки контейнеров Docker/Kubernetes, неправильные тайминги и лимиты.
Зависимость от внешних сервисов — медленный отклик сторонних API, перегрузка CDN-ресурсов, долгие DNS-разрешения.


Умеренные ресурсы и жалобы пользователей («тормоза»).

Такое возможно! Основные причины:
Latency сети — плохое соединение у конечного пользователя (низкий ping, нестабильная связь). Например, клиент находится далеко географически от сервера, и каждый запрос проходит большое расстояние.
Неподходящие браузеры или устройства — пользователь работает на слабых устройствах или устаревших версиях браузера.
JavaScript/CSS/HTML проблемы на стороне фронта — избыточные DOM-операции, неэффективные JS-скрипты, неоптимизированные CSS-правила замедляют рендеринг страницы.
Асинхронность и ожидание ресурсов — долгие загрузки статики (изображения, стили, скрипты), много асинхронных AJAX-запросов.
Кэширование — отсутствие кэшированных ресурсов на стороне клиента (неправильные заголовки Cache-Control, Expires).
Ожидания на стороне бизнес-логики — внутренняя логика приложения имеет высокие ожидания (long running transactions, bulk operations).

.

Жалобы пользователей и видимые симптомы в системе:

«Страницы долго загружаются» — долгое выполнение PHP-кода, долгая отдача статичных ресурсов, медленные операции на сервере (SQL-запросы, вызовы API).

«Система подвисает при работе» — длительные вычисления на фронте (JS-циклы, перерисовка UI), ресурсоемкость браузера, тяжелые JavaScript-библиотеки.

«Приложение медленно откликается» — высокая задержка на стороне сети, некорректная настройка кеширования, неправильно выбранные индексы в базе данных.

«Заполнение формы тормозит» — сложная обработка форм на стороне клиента (валидация полей, Ajax-подсказки), не оптимальные взаимодействия (slow response times from server-side logic).


Чтобы связать такие жалобы с системой, нужно анализировать журналы запросов, сетевую активность, профилировку исполнения и мониторинг фронтенда.
Например, инструмент Lighthouse (Google Chrome DevTools) покажет конкретные моменты тормозов во фронтенде, а серверные метрики дадут подсказки относительно возможной внутренней блокировки или долгих SQL-запросов.


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

#497_GO_ODP_Q22

Стандартный набор метрик Prometheus в Go -программе?
Оставив Prometeus в стороне — что вообще Go-программа способна о себе рассказать?
Метрики runtime — что это, и откуда берется?


Стандартный набор метрик Prometheus в Go-программе.

Prometheus предлагает стандартный набор библиотек для сбора метрик в Go-приложениях.

Основные типы метрик:

Counter (Счётчик) — используются для подсчёта количества событий (например, число обработанных запросов):

var requestsTotal = prometheus.NewCounter(prometheus.CounterOpts{
  Name: "http_requests_total",
  Help: "Total number of processed HTTP requests.",
})

Gauge (Индикатор) — показатель текущего значения переменной величины. Может увеличиваться и уменьшаться (например, свободная память):

var freeMemoryBytes = prometheus.NewGauge(prometheus.GaugeOpts{
  Name: "free_memory_bytes",
  Help: "Amount of available memory in bytes.",
})

Histogram (Гистограмма) — используется для измерения распределения значений, таких как продолжительность обработки запросов:

var requestDurationSeconds = prometheus.NewHistogramVec(
  prometheus.HistogramOpts{
    Name: "http_request_duration_seconds",
    Help: "HTTP request duration distribution.",
    Buckets: []float64{.005, .01, .025, .05, .1, .25},
  },
  []string{"method"},
)

Summary (Краткое описание) — обобщённая статистика (среднее значение, медиана, квантили) распределения значений:

var requestLatencyMilliseconds = prometheus.NewSummaryVec(
  prometheus.SummaryOpts{
    Name: "http_request_latency_milliseconds",
    Help: "Request processing time summary statistics.",
    Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001}, // percentiles
  },
  []string{"endpoint"},
)

Пример стандартного набора метрик для веб-приложения на Go:

package main
import (
  "net/http"
  "github.com/prometheus/client_golang/prometheus"
  "github.com/prometheus/client_golang/prometheus/promauto"
  "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
  requestsTotal = promauto.NewCounter(prometheus.CounterOpts{
    Name: "http_requests_total",
    Help: "Total number of processed HTTP requests.",
  })
  requestDurationSeconds = promauto.NewHistogramVec(prometheus.HistogramOpts{
    Name:    "http_request_duration_seconds",
    Help:    "HTTP request duration histogram.",
    Buckets: prometheus.LinearBuckets(0.001, 0.001, 10),
  }, []string{"path"})
)

func handler(w http.ResponseWriter, r *http.Request) {
  defer func() { requestsTotal.Inc() }()
  timer := prometheus.NewTimer(requestDurationSeconds.WithLabelValues(r.URL.Path))
  defer timer.ObserveDuration()
  w.Write([]byte("Hello World"))
}

func main() {
  http.HandleFunc("/", handler)
  http.Handle("/metrics", promhttp.Handler())
  http.ListenAndServe(":8080", nil)
}

.

Что вообще Go-программа способна о себе рассказать?

Go-программы предоставляют огромное количество встроенных возможностей для самоотчета благодаря пакету runtime.


Основные категории информации, которую можно собрать из программы на Go:

Метрики среды выполнения (runtime) — эти данные предоставляются стандартным пакетом runtime.
Память — общий объём используемой памяти, выделенный heap-size, числа объектов GC, stack trace и размеры сегментов.
Процессор — использование процессорного времени, частота переключений контекста.
Сборщик мусора (GC) — информация о количестве циклов сборки мусора, объёмах освобождаемой памяти, интервалах запуска.
Threads/Goroutines — общее количество горутин, потоки выполнения, режим параллелизма.
Heap — структура куч, распределение объектов по типам и состояниям (allocated vs freed objects).

Пример простого вывода метрик среды выполнения:

package main
import (
  "fmt"
  "log"
  "runtime"
)

func main() {
  var m runtime.MemStats
  runtime.ReadMemStats(&m)
  fmt.Printf("Alloc: %v MiB\n", bToMb(m.Alloc))  // Выделено памяти
  fmt.Printf("Sys: %v MiB\n", bToMb(m.Sys))  // Общая система памяти
  fmt.Printf("NumGC: %d\n", m.NumGC)  // Число запусков GC
  fmt.Printf("PauseTotalNs: %v ms\n", nsToMs(m.PauseTotalNs))  // Всего пауза GC
  log.Println(runtime.NumGoroutine())  // Текущие активные goroutines
}

// Вспомогательные функции преобразования байтов и наносекунд
func bToMb(b uint64) float64 { return float64(b) / 1024 / 1024 }
func nsToMs(ns int64) float64 { return float64(ns) / 1_000_000 }

Другие важные показатели.
Помимо метрик runtime, Go-программы способны сообщать дополнительную полезную информацию:
Версия компилятора и окружения — имя операционной системы, архитектура, версия Go.
Процессы ввода-вывода — счётчики открытых файловых дескрипторов, используемых сокетов, временных затрат на ввод-вывод.
Информация о приложении — длительность жизни процесса, количество обработанных сообщений, уровень конкурентности (goroutines, каналы).
Эффекты многопоточности — детали работы механизма планировщика, взаимодействие c очередями, работа воркер-пулов.


Откуда берутся метрики runtime?

Метрики среды выполнения собираются автоматически самим Go-интерпретатором и виртуальной машиной.
Эти данные доступны через пакет runtime, предоставляющий доступ к внутренним структурам Go-процесса:

Пакет runtime отслеживает изменения в структуре выполнения, включая работу сборщика мусора, управление памятью и работой планировщика.
Периодические события синхронизации происходят каждые несколько миллисекунд (по умолчанию примерно раз в 10 мс), собирая актуальные сведения о состоянии приложения.
Интерфейс runtime.MemStats предоставляет статистику памяти и другие характеристики среды выполнения.

Методы типа runtime.ReadMemStats() или runtime.NumGoroutine() вызывают внутренний механизм записи текущих состояний и возвращают собранную информацию приложению.


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