Monitoring zdarzeń platformowych
Wymagania
aktywna aplikacja Router2 z EximeeEvents
aplikacja dostarczana z platformą Eximee od wersji 2.3167.0
aktywna aplikacja WebformsRest
aplikacja dostarczana z platformą Eximee
aktywna aplikacja MonitoringLogProcessor
aplikacja dostarczana z platformą Eximee 2.3019.0
aktywna baza przechowująca zdarzenia
do działania aplikacji wymagany jest PostgreSQL w wersji >=9.5
aktywna instancja Kafki
platforma Eximee dostarcza Kafka w odpowiedniej wersji
w przypadku chęci wykorzystania Kafki istniejącej w banku polecamy wersję >= 3.4
aktywna instancja Grafana min 8.X.X
przykładowy dashboard monitoringu jest przekazywany z platformą w pliku grafana.json
Uruchomienie funkcjonalności w platformie sterowane jest przez dodanie do zmiennej COMPOSE_PROFILES wartości "monitoring".
Założenia działania
Aplikacja Webforms generuje zdarzenia związane ze stanem wniosków.
Możliwe są różne implementacje logowania zdarzeń aktywne w tym samym czasie. Zależy to od konfiguracji oraz wdrożenia. EximeeEventsConnector (jedna z możliwych implementacji) zbiera zdarzenia i wysyła je do EximeeEvents.
EximeeEvents zapisuje je na odpowiedni topic Kafki.
MonitoringEventProcessor czyta zdarzenia z kafki, weryfikuje je i zapisuje do bazy danych (PostgreSQL) w sposób możliwy do odczytania przez Grafanę.
Zdarzenia w bazie danych mogą zostać odczytane przez zewnętrzne aplikacje w celu wizualizacji lub analizy. Razem z platformą dostarczana będzie konfiguracja Grafany w celu wizualizacji zdarzeń.
Aplikacja Router2 z EximeeEvents
Przeznaczenie
EximeeEvents to plugin do aplikacji Router2. Udostępnia on endpoint przyjmujący zdarzenia, które są następnie zapisywane na odpowiednim topicu Kafki.
Topic i grupa wiadomości przekazywanej do kafki muszą być spójne z konfiguracją MonitoringLogProcessora.
Konfiguracja
Konfiguracja oraz więcej informacji tutaj [Rejestracja zdarzeń procesu]
Aplikacja MonitoringLogProcessor
Przeznaczenie
Zadaniem aplikacji jest wypełnianie bazy danych (aktualnie tylko PostgreSQL) zdarzeniami platformowymi.
Aplikacja czyta zdarzenia ze źródła (Kafka) i weryfikuje czy jest to zdarzenie systemowe (pochodzące z platformy). Następnie zdarzenia systemowe są dostosowywane pod Grafanę i zapisywane do bazy danych.
Konfiguracja
Baza danych - docelowe miejsce do przechowywania zdarzeń
MONITORING_LOG_PROCESSOR_DATABASE_DIALECT
TAK
org.hibernate.dialect.PostgreSQL95Dialect
Dialekt bazy danych przeznaczonej do przechowywania zdarzeń.
MONITORING_LOG_PROCESSOR_DATABASE_URL
TAK
Namiar na bazę danych.
MONITORING_LOG_PROCESSOR_DATABASE_USERNAME
TAK
db_user
Użytkownik z uprawnieniami do zapisu zdarzeń.
MONITORING_LOG_PROCESSOR_DATABASE_PASSWORD
TAK
db_pass
Hasło użytkownika dostępowego do bazy danych.
Kafka
MONITORING_LOG_PROCESSOR_KAFKA_TOPIC
TAK
all
Topic, na który trafią wiadomości ze zdarzeniami
MONITORING_LOG_PROCESSOR_KAFKA_GROUP
TAK
eximee-events
Grupa zdarzeń eximee
Zapisywane zdarzenia
Zdarzenia muszą być pochodzenia systemowego (origin = SYSTEM).
Typy zdarzeń są modyfikowane na typ biznesowy. Typ, który nie posiada odpowiednika w zdarzeniu biznesowym, dostaje pustą wartość. Informacja o zamianie typów zdarzeń znajduje się poniżej:
FORM_NEW_STARTED
FORM_ENTRY
Wejście na wniosek
FORM_NEXT_PAGE FORM_PREVIOUS_PAGE
PAGE_SAVE
Zapisanie stanu aktualnej strony - przejście na kolejną lub poprzednią stronę
FORM_CLIENT_PAGE_CHANGED
PAGE_ENTRY
Zmiana strony - wejście na inną stronę.
FORM_SAVE
FORM_SAVE
Wysłanie wniosku
FORM_DRAFT_SAVE
FORM_DRAFT_SAVE
Zapisanie roboczej wersji wniosku
FORM_DRAFT_RESTORE
FORM_DRAFT_RESTORE
Przywrócenie roboczej wersji wniosku
Struktura bazy danych (PostgreSQL)
Określona struktura bazy danych ze zdarzeniami biznesowymi.
Tabela
events
Nazwa pola
Typ
nullable
Opis
id
bigserial
FALSE
Kolejne identyfikatory zdarzeń
origin
text
FALSE
Pochodzenie zdarzenia (SYSTEM / BUSINESS)
type
text
FALSE
Typ zdarzenia biznesowego (tabela z typem zdarzeń znajduje się wyżej)
timestamp
timestamp
FALSE
Czas wywołania zdarzenia (data i godzina)
payload
jsonb
TRUE
Dane zdarzenia w postaci JSONa, jeśli zdarzenie posiada dodatkowe dane.
Skrypty migracyjne
Skrypty migracyjne do stworzenia i modyfikowania tabeli zapisywane są w archiwum do przekazania razem z platformą.
Aplikacja Webforms z logowaniem zdarzeń
Przeznaczenie
Mechanizm logowania zdarzeń ma za zadanie zbierać zdarzenia związane ze zmianą stanu wniosków z całej platformy. Zdarzenia są wysyłane w paczkach do Kafki przy pomocy EximeeEvents.
Konfiguracja
W celu aktywowania zbierania zdarzeń, należy odpowiednio ustawić konfigurację webforms.xml. Poniżej fragment konfiguracji, który odpowiada za aktywny przepływ zbierania zdarzeń.
<?xml version="1.0" encoding="UTF-8" ?>
<webforms>
....
<server>
...
<features>
...
<eventLog>
<enabled>true</enabled>
<coreExecutorPoolSize>5</coreExecutorPoolSize>
<maxExecutorPoolSize>10</maxExecutorPoolSize>
<eximeeEventsProcessor>
<enabled>true</enabled>
<url>http://localhost:9002</url>
</eximeeEventsProcessor>
</eventLog>
</features>
</server>
</webforms>Oraz tabela przedstawiająca konfigurację instalacyjną.
Akywny mechanizm zbierania zdarzeń
server.features.eventLog.enabled
true
Aktywność mechanizmu zbierania zdarzeń
server.features.eventLog.coreExecutorPoolSize
5
Liczba wątków w ramach przetwarzania zdarzeń
server.features.eventLog.maxExecutorPoolSize
10
Maksymalna liczba wątków w ramach przetwarzania zdarzeń
Aktywny mechanizm logowania zdarzeń
server.features.eventLog.eximeeEventsProcessor.enabled
true
Aktywność mechanizmu EximeeEvents
server.features.eventLog.eximeeEventsProcessor.url
Namiar na aplikację EximeeEvents do zapisywania zdarzeń na kafce
Last updated
Was this helpful?