Doporučte monitoring pro začátečníka

[kopevi2]

Dobrý den,
zrovna tím bych nezačínal, webové rozhraní přes tomcat je dost overkill, doporučuji fat klienta a hrát si s ním bez www rozhraní které je vlastně fat klient běžící na tomcatu na serveru a bude to celé žrát 3x víc než samotné cečkove netxms..

Pokud ale opravdu chcete, zaklad je uchodit tomcat aby šla default page, a poté do webapps složky tomcatu zkopírovat aplikaci staženou z download ve formě ROOT.war tomcat ji nahodí a bude hned za lomítkem url serveru.

Pokud aktualizujete netxms server, budete muset také aktualizovat web rozhraní ono warko, pokud je tam větší změna napíše že klient verze jsou různé a ukončí se.

Postup je tady, a na první dobrou co jej pročítám mě přijde aktuální
https://netxms.org/documentation/adminguide/installation.html#web-management-client

Moje rada pro Vás je ale na tohle kašlat, stáhnete odsud https://netxms.com/download/releases/5.2/nxmc-5.2.7-win32-x64-bundled-jre.zip win fat clienta včetně jre co se nemusí se instalovat dá se synchronizovat třeba nextcloud diskem, zadejte ip serveru user a pass a jste tam.

Dobrý den, děkuji moc za reakci. Nakonec jsem instalaci webového rozhraní zavrhl. Ten klient se zdá být ok, celkem se to pěkně používá. Jen mi vyvstala otázka, nemáte zkušenost s kompilováním agenta na RPI5 (Raspbian 12 - bookworm)? Na stránkách je pouze klient zkompilovaný pro zastaralého Bustera 10. Zkoušel jsem to kompilovat podle různých návodů, vše se zdálo OK, ale klient nenaběhne viz kód:

Kód: [Vybrat]

× nxagentd.service - NetXMS Agent
    Loaded: loaded (/lib/systemd/system/nxagentd.service; enabled; preset: enabled)
    Active: failed (Result: exit-code) since Sun 2025-11-09 14:05:47 CET; 2min 54s ago
    Process: 1361070 ExecStart=/usr/bin/nxagentd -d (code=exited, status=127)
        CPU: 1ms

lis 09 14:05:47 mama-rpi systemd[1]: nxagentd.service: Scheduled restart job, restart counter is at 5.
lis 09 14:05:47 mama-rpi systemd[1]: Stopped nxagentd.service - NetXMS Agent.
lis 09 14:05:47 mama-rpi systemd[1]: nxagentd.service: Start request repeated too quickly.
lis 09 14:05:47 mama-rpi systemd[1]: nxagentd.service: Failed with result 'exit-code'.
lis 09 14:05:47 mama-rpi systemd[1]: Failed to start nxagentd.service - NetXMS Agent.
Konkrétně hláška "/usr/bin/nxagentd -d (code=exited, status=127)" značí, že systém nezná toho agenta - omlouvám se, že to píšu tak krkolomně.

Ještě jsem zkoušel výpis z journalctl a ve výpisu se opakují podobné hlášky.

Kód: [Vybrat]

lis 09 12:13:06 mama-rpi systemd[1]: Starting nxagentd.service - NetXMS Agent...
░░ Subject: A start job for unit nxagentd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nxagentd.service has begun execution.
░░
░░ The job identifier is 188004.
lis 09 12:13:06 mama-rpi nxagentd[1307236]: /usr/bin/nxagentd: error while loading shar>
lis 09 12:13:06 mama-rpi systemd[1]: nxagentd.service: Control process exited, code=exi>
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit nxagentd.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 127.
lis 09 12:13:06 mama-rpi systemd[1]: nxagentd.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit nxagentd.service has entered the 'failed' state with result 'exit-code'.
lis 09 12:13:06 mama-rpi systemd[1]: Failed to start nxagentd.service - NetXMS Agent.
░░ Subject: A start job for unit nxagentd.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nxagentd.service has finished with a failure.

Myslíte si, že to je chyba v kompilaci-instalaci, a že by stačilo tam přidat tu cestu do PATH? (Přiznám se, že úplně nevím jak to správně opravit Jenom googluju, čím to může být.)
Mám ještě záložní plán a to je SNMP na tom RPI, ale to až, selžou všechny možnosti o rozchození toho agenta. Hlavně NetXMS jsem si vybral právě kvůli snadné integraci čtení ze MODBUS skrze RPI(což se mi v budoucnu může hodit)..

[Reklama]

[madmucho]

Dobrý den,
binarku agenta na raspberrpi pi se mi povedlo ze zdrojáků zkompilovat, ale nějak se nám to téma článku mění a komplikuje.
Pro testy bych zvolil raději platformu na kterou máte agenta před sestaveného, až si budete jistý že vyhovuje a funguje, pouštěl bych se do tohohle na jiných platformách.

Pro kompilaci na raspberry pi doinstalujte alespoň zaklad pro sestavování, pro postup dále předpokládám Debian 12

Kód: [Vybrat]

apt install build-essential autoconf libssl-dev libpcre2-dev libmodbus-dev
stáhněte zdrojové kódy netxms ze stránek

Kód: [Vybrat]

https://netxms.com/download/releases/5.2/netxms-5.2.7.tar.gzrozbalte třeba do /opt/netxms

v adresáři pak configure a make

Kód: [Vybrat]

./configure --with-libmodbus --with-libssh --with-snmp --with-agent --with-openssl --with-client-proxy --with-static-subagents-list=ssh
make
make install
ldconfig
pro systemd je unit file dostupny po kompilaci v /opt/netxms/netxms-5.2.7/contrib/startup/systemd/netxms-server.service takže ho zkopirovat do /etc/systemd/system
vytvořit základní konfigurační soubor v /etc/nxagentd.conf dle dokumentace

A pak unitu nechat zaregistrovat a pokusit se nastartovat službu a zkouknout

Kód: [Vybrat]

systemctl daemon-reload
systemctl start netxms-agent
systemctl status netxms-agent

je to minimální konfigurace pro agenta snad pro vaše účely bude dostačující.
agent log je dle konfigu agenta, tam najdete pokud se spustí, další provozní informace.
LogFile=/var/log/nxagentd

Pevné nervy přeji.

[kopevi2]

......

je to minimální konfigurace pro agenta snad pro vaše účely bude dostačující.
agent log je dle konfigu agenta, tam najdete pokud se spustí, další provozní informace.
LogFile=/var/log/nxagentd

Pevné nervy přeji.

Jste zlatej, moc děkuju, už jsem to rozchodil. Ještě bych měl asi trochu hloupý dotaz, ale zkouším přidat to RPi do monitorinku. Musím mít to RPi ve stejné síti jako je ten server (tzn. udělat VPN), nebo se dá přihlásit na ten server, který má veřejnou ip i bez toho? Ptám se, protože, když jsem zkoušel tam dát to zařízení- jako nový nód, tak mi to sice tam to zařízení přidá, ale nemám z něj žádné metriky...(IP jsem zkusil zjistit pomocí

Kód: [Vybrat]

curl ifconfig.me, ale jsem stoprocentně za milionem natů

[madmucho]

Server se ptá agenta, musí na něj vidět, mít vypublikované porty nebo vpn.

Existuje i možnost vytvořit v konfiguraci tunel, ale je to složité PKI kolem dokola vpn bude snazší.

......

je to minimální konfigurace pro agenta snad pro vaše účely bude dostačující.
agent log je dle konfigu agenta, tam najdete pokud se spustí, další provozní informace.
LogFile=/var/log/nxagentd

Pevné nervy přeji.

Jste zlatej, moc děkuju, už jsem to rozchodil. Ještě bych měl asi trochu hloupý dotaz, ale zkouším přidat to RPi do monitorinku. Musím mít to RPi ve stejné síti jako je ten server (tzn. udělat VPN), nebo se dá přihlásit na ten server, který má veřejnou ip i bez toho? Ptám se, protože, když jsem zkoušel tam dát to zařízení- jako nový nód, tak mi to sice tam to zařízení přidá, ale nemám z něj žádné metriky...(IP jsem zkusil zjistit pomocí

Kód: [Vybrat]

curl ifconfig.me, ale jsem stoprocentně za milionem natů

[kopevi2]

Ok, moc děkuju, zkusím tam tedy přidat jinou VPS abych si to nacvičil, a pak udělám tu VPN pro klienty...

[Reklama]

[hmmmw]

Pokud něco, co můžeš využít i v profesním životě tak prometehus+alertmanager, nebo ten zabbix.

Pokud chceš malou (podle popis ti nebude stačit) domáci utilitku, tak uptime-kuma. Naklikáš si endpointy, a vidíš, že to jede/nejede. Plus ti to může poslat alert. https://github.com/louislam/uptime-kuma

Tak jsem si našel ten prometheus, https://www.youtube.com/watch?v=1si0DXveWH4
Ale chtěl bych se zeptat, jestli je lepší (dle vás) to provozovat v dockeru, někde na vps, nebo u sebe doma na vyhrazené virtuálce. Jde mi o to, abych to nemusel složitě nahazovat po každý aktualizaci tý VPS a zároveň abych si nerozdrbal ten mail server. Resp. jde mi o best practices, jak by se řeklo :-) IT se asi nikdy živit nebudu, ale přece jen chci dělat věci, jak se sluší a patří.

Promiň, po pár měsících jsem si všimnul, že ses doptával. Jelikož to tu je pořád aktivní, odpovím obecně:

Co jde, cpu doma do dockeru. Je třeba si vyladit tu úvodní konfiguraci, ale pak už to můžeš opakovaně zahazovat a spouštět, a pořád máš uklizeno.

[kopevi2]

Pokud něco, co můžeš využít i v profesním životě tak prometehus+alertmanager, nebo ten zabbix.

Pokud chceš malou (podle popis ti nebude stačit) domáci utilitku, tak uptime-kuma. Naklikáš si endpointy, a vidíš, že to jede/nejede. Plus ti to může poslat alert. https://github.com/louislam/uptime-kuma

Tak jsem si našel ten prometheus, https://www.youtube.com/watch?v=1si0DXveWH4
Ale chtěl bych se zeptat, jestli je lepší (dle vás) to provozovat v dockeru, někde na vps, nebo u sebe doma na vyhrazené virtuálce. Jde mi o to, abych to nemusel složitě nahazovat po každý aktualizaci tý VPS a zároveň abych si nerozdrbal ten mail server. Resp. jde mi o best practices, jak by se řeklo :-) IT se asi nikdy živit nebudu, ale přece jen chci dělat věci, jak se sluší a patří.

Promiň, po pár měsících jsem si všimnul, že ses doptával. Jelikož to tu je pořád aktivní, odpovím obecně:

Co jde, cpu doma do dockeru. Je třeba si vyladit tu úvodní konfiguraci, ale pak už to můžeš opakovaně zahazovat a spouštět, a pořád máš uklizeno.

Ahoj díky za info. Já jsem to teď o víkendu drátoval a udělal jsem to tak (nevím jestli je to dobře), že jsem si přikoupil vps kde mám ten monitorovací server. Wireguardem jsem tam nadrátoval všechny moje "blbinky" (čti RPička pro tetu, mámu, nasky, 3d tiskárny apod..). Problém jsem zaznamenal až při drátování druhé VPS(s veřejnou ip a vlastním dns) kde mám mail server (Mail-in-a-box: CalDAV. CardDAV, nextcloud, vlastní dns), kde jsem to udělal nejdřív klasika, abych zbytečně nedělal tunely, tak veřejná IP VPS MIAB a veřejná IP VPS s monitorinkem NETXMS, což fachalo - dělal jsem to pouze na zkoušku, přenos nebyl šifrovaný, všechno jsem si pak změnil. Bohužel jsem to nastavil nějak blbě, takže při nahození wg tunelu mezi nima, se mi rozsypalo to DNS na MIAB VPS a nefachalo nic (maily, nextcloud apod...) takže jsem to zase shodil dolu a nemonituruju. Nevěděl by někdo prosím, jak udělat ten tunel mezi VPS, aby ten tunel byl pouze na ten monitorink a ostatní tzn. maily, nextcloud chodily klasika přes to dns v tý VPS s MIAB? Vím že to bude asi prkotina, ale tohle bych chtěl umět pořádně a nechci to rozdrbat komplet...Dík za případnou radu a pomoc..

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Mně inspiroval tenhle článek, pro alternativy : .

Možná triviální dotaz, ale ten docker(nebo portainer?) jede přímo v distribuci v železe a ne ve VM? A je nějak vyladěna konfigurace (jako rootles, nesting)? A taky kvůli bezpečnosti, jestli je nějak zásadní toho dockera uzavírat do virtuálky.
Já pořád mám trochu bariéru dát docker do VM, protože tím pádem bude sešněrovaný množství RAM (pořád této představě věřím, přestože s memory balloning možností defacto limity ram jsou pasé)

WG nefachá tunel

Takhle moc neporadím, nevidím konkrétní zadrátování,... Je schéma  VPS1:WG1, VPS2:WG2, domácí router:WG3? Na WG3 mám nejvíc logiky, ten umožní se zvenčí napojit na zařízení v té vnitřní síti.  Mají potom všechny tři wg v peerech ostatní dva ? Aby byli do trojúhleníku. Druhá věc, jsou privátní klíče vždy unikátní? Nejde zkopírovat config (privátní klíč) a vložit ho na nový wg peer, jinak se budou střídavě překřikovat-přepojovat. Možná tam taky je nastavená brána tak, že ty pakety putují opakovaně až vymřou po TeTeLici.- chtělo by to tcpdumpovat ICMP pakety.
(Já tedy DNS přes wg neřeším).

[kopevi2]

Přikládám schéma, jak to mám zatím řešeno. Tunel VPN-koncentrátor <-> VPS MIAB fachá, ale od té chvíle na VPS MIAB nelze přistupovat "extreně" tzn přes IP:176.102.x.y ale pouze v rámci VPN tzn. IP:10.220.59.9 -> předpokládám, že tím bypassuju veškerý provoz přes VPN-koncentrátor a je tím tedy odstaven DNS v MIAB a veškeré služby z MIAB. Nevěděl by někdo nějaký návod, jak udělat správně routovací tabulku, že veškerý provoz má jít na rozhraní eth0 a pouze komunikace v rámci VPN (což bude pouze monitorink, případně zálohy do S3) půjdou přes rozhraní garage1 (což je wireguard) půjdou na 10.220.59.1 do koncentrátoru..