Getting metrics from logs in Elasticsearch

Мне по работе надо получать события когда в логах приложений (логи у нас попадают в elasticsearch) появляются определённые сообщения. Zabbix умеет делать запросы по http. Но у нас Victoriametrics (ибн Prometheus) и хотелось бы, что бы alertmanager генерировал алерты. Но для того, что бы он смог это сделать, нужно что бы соответствующая метрика появилась в victoriametrics. Грубо говоря, нужно что бы Prometheus (или что на него похожее — vmagent) обратился к elasticsearch с определённым запросом и создал метрику. Но он зараза такое не умеет :(.

Да, можно попросить программеров, что бы они сделали нужную нам метрику у приложения. Но это хорошо когда программеры рядом и идут на встречу. Если их нет или это какое то старое приложение то ФСЁ — приплыли и рядом с victoriametrics надо ставить zabbix или что то такое…

Я честно искал приложение, которое может посылать необходимые мне запросы в elasticsearch и генерить метрики Prometheus. Но не нашёл. Возможно я плохо искал?

Вобщем мне надоело искать и я вспомнил, что нормальный сисадмин должен уметь писать вспомогательные утилиты. Я же типа нормальный сисадмин? 🙂

Заодно решил подучить go. Учить язык надо на каком то живом задании. Собственно вот, задание:

  • Приложение должно уметь посылать запросы в elasticsearch и генерировать метрики в формате Prometheus.
  • Это должен быть контейнер.
  • Должна быть горизонтальная масштабируемость. Запросов ожидается много.
  • Мы должны легко жить в kubernetes.

Итого. Программисты, не бейте меня ногами. Вы такого не написали, а мне очень надо. Поэтому родилась вот такая утилита: https://github.com/BigKAA/metrics-from-logs

Это первая версия, написанная по быстрому, на коленке. Там ещё много чего надо дописывать. Научится нормально работать с Redis и много ещё чего.

Kubernetes, StatefulSet, Nexus

Хороший пример для объяснения зачем нужен StatefulSet. Начало серии видео по devops инструментам в кубернетес. Nexus внутри kubernetes, делаем свой docker registry.

  • 03:43 — Про Nexus, общие вопросы выбора технологии деплоймента.
  • 06:40 — StatefulSet — теория.
  • 10:54 — Namespace для nexus, LimitRange на namespace, проект в rancher.
  • 13:48 — Файлы деплоя nexus:
  • 14:20 — Headless service
  • 16:25 — StatefulSet
  • 21:09 — Service, ссылка на конкретный pod в StatefulSet. Вот оно!
  • 23:28 — Ingress.
  • 26:31 — Пароль админа nexus и первоначальная настройка nexus.
  • 27:49 — Настройка репозитория для хранения docker контейнеров. Пользователи и роли.
  • 32:00 — ssl порт и сертификат для репозитория.
  • 41-05 — пушим образы!

Файлы, используемые в видео: https://github.com/BigKAA/youtube/tree/master/nexus

Hibernate, Spring и имена таблиц, полей базы данных.

Эх, давно не брал я в руки шашку. (с) Василий Иванович

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

Досталась мне в наследство базёнка, в которой имена таблиц и полей начинаются с большой буквы. Типа: Notes, NotesIndex и т.п.

Настраиваю spring JPA, все как в примере работы с MySQL. Только в отличии от примера использую готовую таблицу. Проверку опять же:

spring.jpa.hibernate.ddl-auto=validate

Описываю сущности. Причем понимаю, что название таблиц и полей нестандартное, явно указываю имена:

@Data
@Entity
@Table(name = "Notes")
public class Notes {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name="NoteIndex")
  private int noteIndex;

Запускаю приложение и ловлю ошибку:

nested exception is org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing table [notes]

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

spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl