Fórum Root.cz
Hlavní témata => Server => Téma založeno: kopevi2 23. 08. 2025, 19:32:33
-
Zdravím,
chtěl bych se zeptat na vhodný monitoring. Chtěl bych monitorovat cca 10 strojů (NASky, tiskárna Brother, různé jednodeskové počítače-debian, routery-openwrt). Zařízení mám mezi sebou spojené VPN tunely wireguard. Zkoušel jsem Cacti, ale moc mi tam nejde to SNMP na tiskárny.
Mohli byste mi doporučit vhodný monitorovací systém (poměr výkon/jednoduchost). Na mail-in-a-box mám munin, šlo by to použít i na to?
Chtěl bych zaznamenávat rychlost sítě, využití disků, teploty, pokusy na přihlášení na ssh, případně další věci, ideálně, aby tam šlo i dobastlit sbírání dat z čidel (vlhkost apod, cron na php skript). Upozornění např. na email. Konfigurace ideálně v texťáku.
Děkuji za případné tipy a nasměřování.
-
Ja mám dobrú skúsenosť s prometheus a alertmonitoringom k nemu (ak treba) a pre pripad potreby dashboardov, graphana... ale na domace pouzitie by mne postacoval samotny prometheus.
-
Netxms
Ja som rozbehol nieco podobne v NetXMS cez docker.
Problem bude hlavne Brother a SNMP.
Tlaciarne su lepsie od HP.
Pripajam link:
https://github.com/netxms/docker
-
https://github.com/netdata/netdata
-
děkuji všem. Ještě bych se chtěl zeptat, jak byste mi to doporučili provozovat? Mam dell wyse s proxmoxem, nebo vps s tim mail-in-a-box(dle vyvojare miab by to melo byt ovsem vyhrazene jen pro miab) v dockeru.
-
děkuji všem. Ještě bych se chtěl zeptat, jak byste mi to doporučili provozovat? Mam dell wyse s proxmoxem, nebo vps s tim mail-in-a-box(dle vyvojare miab by to melo byt ovsem vyhrazene jen pro miab) v dockeru.
Dneska Prometheus nebo ZABBIX, ale ten také používá stejnou Grafanu jako Prometheus, který je jednodušší na nastavení.
-
Dneska Prometheus nebo ZABBIX, ale ten také používá stejnou Grafanu jako Prometheus, který je jednodušší na nastavení.
Pane Crhonku, jste hodný, ale já bych od vás chtěl spíš než rady, tak ty disky, co jsem si koupil.
https://forum.root.cz/index.php?topic=30575.195
-
pomůže jenom dopis do schránky, ten nikdo nesmaže.
-
Mohli byste mi doporučit vhodný monitorovací systém (poměr výkon/jednoduchost).
Já doporučuju Zabbix. Je dostatečně flexibilní a zároveň jednoduchý na pochopení a používání.
-
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
-
To je boží! Chodím sem celkem často, ale tohle mi uniklo. ;D
Dneska Prometheus nebo ZABBIX, ale ten také používá stejnou Grafanu jako Prometheus, který je jednodušší na nastavení.
Pane Crhonku, jste hodný, ale já bych od vás chtěl spíš než rady, tak ty disky, co jsem si koupil.
https://forum.root.cz/index.php?topic=30575.195
-
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ří.
-
Asi trochu pozdě, ale možná by jsi se mohl podívat na https://checkmk.com/
Je to takový Nagios na steroidech. Monitoruji tím stovky serverů, tiskáren a switchů už asi 10 let, zatím jsem nenašel nic lepšího.
-
Asi trochu pozdě, ale možná by jsi se mohl podívat na https://checkmk.com/
Je to takový Nagios na steroidech. Monitoruji tím stovky serverů, tiskáren a switchů už asi 10 let, zatím jsem nenašel nic lepšího.
Pozdě ještě není, pořád se rozhoupávám co zvolit a jak to udělat. Nagios jsem kdysi viděl, líbilo se mi, jak to pěkně kreslilo návaznosti prvků, ale pro mě to byla vyšší dívčí (tímto zdravím Ricarda a Wira z Pod-o-lee :-) ). A znáte nějaký monitorink, kde bych si rovnou rozkliknul např. ssh konzoli, nebo bych mohl schraňovat konfiguráky (např. na ten wireguard)?
-
Neznám a ani znát nechci 😛. Monitoring má monitorovat, ssh konzolovat a backup SW zálohovat.
-
Asi trochu pozdě, ale možná by jsi se mohl podívat na https://checkmk.com/
Je to takový Nagios na steroidech. Monitoruji tím stovky serverů, tiskáren a switchů už asi 10 let, zatím jsem nenašel nic lepšího.
Pozdě ještě není, pořád se rozhoupávám co zvolit a jak to udělat. Nagios jsem kdysi viděl, líbilo se mi, jak to pěkně kreslilo návaznosti prvků, ale pro mě to byla vyšší dívčí (tímto zdravím Ricarda a Wira z Pod-o-lee :-) ). A znáte nějaký monitorink, kde bych si rovnou rozkliknul např. ssh konzoli, nebo bych mohl schraňovat konfiguráky (např. na ten wireguard)?
https://www.netxms.org/documentation/adminguide/ssh-monitoring.html
-
...
https://www.netxms.org/documentation/adminguide/ssh-monitoring.html
Díky moc, asi zkusím to netxms, protože se mi líbí, jak to pěkně jde všechno rozřadit a navíc to umí MQTT, což by bylo super na určitý čidla, který nechci sypat do Home assistanta.
-
Tyjo, netxms má poměrně detailní datový model:
https://netxms.org/documentation/userguide/basic-concepts.html
Hmm... ! :-)
-
Zdravím,
chtěl bych se zeptat na vhodný monitoring. Chtěl bych monitorovat cca 10 strojů (NASky, tiskárna Brother, různé jednodeskové počítače-debian, routery-openwrt). Zařízení mám mezi sebou spojené VPN tunely wireguard. Zkoušel jsem Cacti, ale moc mi tam nejde to SNMP na tiskárny.
Mohli byste mi doporučit vhodný monitorovací systém (poměr výkon/jednoduchost). Na mail-in-a-box mám munin, šlo by to použít i na to?
Chtěl bych zaznamenávat rychlost sítě, využití disků, teploty, pokusy na přihlášení na ssh, případně další věci, ideálně, aby tam šlo i dobastlit sbírání dat z čidel (vlhkost apod, cron na php skript). Upozornění např. na email. Konfigurace ideálně v texťáku.
Děkuji za případné tipy a nasměřování.
Já bych sáhnul po Zabbixu – a to ne proto, že s ním dělám, ale prostě proto, že dává smysl. Na Proxmoxu to rozběháš klidně na dvou virtuálkách (jedna na frontend + Zabbix, druhá na PostgreSQL s TimescaleDB nebo jak se to teď jmenuje). Není to žádná věda. Spousta věcí, co chceš, už je hotová v šablonách. A navíc existuje jednoduchá integrace do Home Assistantu. Myslím, že na to má dokonce video i Dmitrij (tvář Zabbixu na YouTube).
Druhá varianta je Grafana s Mimirem (proč si hrát Prometheem, když si ho Grafana sama forknula).
Tohle jsou jinak dvě nejčastější řešení, na která narazíš v korporátech – třeba v Alze nebo O2. Takže to má i profesní přesah.
-
......
Já bych sáhnul po Zabbixu – a to ne proto, že s ním dělám, ale prostě proto, že dává smysl. Na Proxmoxu to rozběháš klidně na dvou virtuálkách (jedna na frontend + Zabbix, druhá na PostgreSQL s TimescaleDB nebo jak se to teď jmenuje). Není to žádná věda. Spousta věcí, co chceš, už je hotová v šablonách. A navíc existuje jednoduchá integrace do Home Assistantu. Myslím, že na to má dokonce video i Dmitrij (tvář Zabbixu na YouTube).
.....
Dík za poposunutí, a šlo by to udělat tak, že bych si udělal virtuálku v ní měl to SQL a taky v dockeru ten Zabbix (tzn. ušetřil bych jeden virtualni stroj)? To Wyse má jen 4 jádra, a mám volno jen na dvě virtuálky, na jedný už jedu právě ten HA... Pardon, že se takhle blbě ptám, ale jsem fakt začátečník/nadšenec, někde to na mě troubilo, že databáze se v dockeru neukládá, tak bych úplně nechtěl přijít o data, i když o nic nejde, ale taky nechci zabít pár hodin tím, že budu dělat něco, co nemůže fungovat, kvůli mému špatnému rozhodnutí...
-
Observium
https://hub.docker.com/r/uberchuckie/observium
services:
app:
image: uberchuckie/observium
container_name: observium
environment:
- TZ=Europe/Prague
volumes:
- observium-config:/config
- observium-logs:/opt/observium/logs
- observium-rrd:/opt/observium/rrd
ports:
- "8668:8668"
- "514:514/udp"
restart: unless-stopped
healthcheck:
test: ["CMD", "nmap", "-p", "8668", "localhost", "|", "grep", "open", "&&", "exit", "0", "||", "exit", "1" ]
volumes:
observium-config:
observium-logs:
observium-rrd:
-
Dík za poposunutí, a šlo by to udělat tak, že bych si udělal virtuálku v ní měl to SQL a taky v dockeru ten Zabbix (tzn. ušetřil bych jeden virtualni stroj)? To Wyse má jen 4 jádra, a mám volno jen na dvě virtuálky, na jedný už jedu právě ten HA... Pardon, že se takhle blbě ptám, ale jsem fakt začátečník/nadšenec, někde to na mě troubilo, že databáze se v dockeru neukládá, tak bych úplně nechtěl přijít o data, i když o nic nejde, ale taky nechci zabít pár hodin tím, že budu dělat něco, co nemůže fungovat, kvůli mému špatnému rozhodnutí...
Tak ono je Zabbixu celkem jedno, kde tu databázi máš – klidně to můžeš mít i celé na jednom serveru. Jen zkušenost je taková, že je lepší to mít oddělené. Ve finále to klidně může běžet celé v kontejnerech :) Jen to ale není doporučeno pro produkční prostředí.
https://www.zabbix.com/container_images (https://www.zabbix.com/container_images)
https://www.youtube.com/watch?v=csZwhQcJmxQ&ab_channel=Zabbix (https://www.youtube.com/watch?v=csZwhQcJmxQ&ab_channel=Zabbix)
https://www.zabbix.com/documentation/current/en/manual/installation/containers (https://www.zabbix.com/documentation/current/en/manual/installation/containers)
A jinak určitě PSQL s TimescaleDB. To je teď nejvíce podporovaná varianta.
-
Děkuji všem, o víkendu teda zkusím ten zabbix a vedle toho ten netxms, pak to porovnám, co mi bude vyhovovat nejvíce. Dle vašich doporučení jsem si našel ten yt kanál o zabbixu a je to tam popsáno přesně polopaticky, takže to snad nebude na dny/hodiny laborování :-).
-
Děkuji všem, o víkendu teda zkusím ten zabbix a vedle toho ten netxms, pak to porovnám, co mi bude vyhovovat nejvíce. Dle vašich doporučení jsem si našel ten yt kanál o zabbixu a je to tam popsáno přesně polopaticky, takže to snad nebude na dny/hodiny laborování :-).
Playlist super tutorialov pre zaciatocnikov na NetXMS od Tomasa Kirnaka:
https://www.youtube.com/playlist?list=PLt3aE2eGS5P9L72H82S83MrKx2uz5x8gv
-
Super vec je oficialny NetXMS client pre mobilne zariadenia Android:
https://play.google.com/store/apps/details?id=org.netxms.android
-
My to často děláme tak, že pokud se zachytí nějaký stav, který by neměl existovat, pošleme si zprávu na Telegram do k tomu zřízené skupiny. Tu skupinu může odebírat více lidí a výhoda je, že je tam i historie problémů. Pak si stačí pohlídat, že se zpráva pošle jen při změně stavu a máte kompletní historii.
Zpráva se pak odešle volání obyčejného URL třeba přes wget.
https://api.telegram.org/bot<BOT_TOKEN>/sendMessage?chat_id=<CHAT_ID>&text=<b>Bold message</b>&parse_mode=HTML
Předem si musím registrovat id nového bota a přidat je do skupiny a zjistit id skupiny.
https://chatgpt.com/share/68ef95ae-a05c-8002-bb04-68336a75ca4b
Specializované systémy, které mají sloužit jen pro monitoring jsem nepochopil. Jsou složité a nic moc navíc to nepřinese.
-
My to často děláme tak, že pokud se zachytí nějaký stav, který by neměl existovat, pošleme si zprávu na Telegram do k tomu zřízené skupiny.
...
Specializované systémy, které mají sloužit jen pro monitoring jsem nepochopil. Jsou složité a nic moc navíc to nepřinese.
Tohle funguje v malém týmu a situaci, kde se těch problémů moc neděje a může si tam člověk tyhle custom věci snadno dodělat. Pokud by ten kanál mělo monitorovat sto lidí, a chodilo tam furt něco, tak to začnou všichni ignorovat. Takže se musí rozdělit role a scope (developera v týmu X možná zajímá, že jeho služba má problém, ale fakt nepotřebuje vědět, že na serveru týmu Y umřel disk), různé priority problémů, je potřeba udržet jednotnost monitoringu v rámci projektu, do toho se přidají požadavky na certifikaci...
A to je zatím jen detekce stavů pro alerty. Já ale chci vidět, co třeba dělá nová změna mojí služby s počtem spojení na databázi. Ale abych to mohl posoudit, potřebuji vidět i kolik chodí požadavků na tu službu, nestačí si jen grepnout něco v terminálu. Obzvlášť, když ani nemám do produkčního prostředí přístup na shell.
Nebo pokud jde o nějakou službu/server od někoho jiného - asi bude mít nějaký endpoint co bude produkovat metriky pro Prometheus, ale těžko do něj budu dělat binární patche, abych si tam přidal http call. Nedej bože, když to ani neběží na mém železe. To se pak najednou nějaké monitorovací systémy, kde se to všechno sbírá dohromady, začnou pořádně hodit.
-
My to často děláme tak, že pokud se zachytí nějaký stav, který by neměl existovat, pošleme si zprávu na Telegram do k tomu zřízené skupiny.
...
Specializované systémy, které mají sloužit jen pro monitoring jsem nepochopil. Jsou složité a nic moc navíc to nepřinese.
Tohle funguje v malém týmu a situaci, kde se těch problémů moc neděje a může si tam člověk tyhle custom věci snadno dodělat. Pokud by ten kanál mělo monitorovat sto lidí, a chodilo tam furt něco, tak to začnou všichni ignorovat. Takže se musí rozdělit role a scope (developera v týmu X možná zajímá, že jeho služba má problém, ale fakt nepotřebuje vědět, že na serveru týmu Y umřel disk), různé priority problémů, je potřeba udržet jednotnost monitoringu v rámci projektu, do toho se přidají požadavky na certifikaci...
A to je zatím jen detekce stavů pro alerty. Já ale chci vidět, co třeba dělá nová změna mojí služby s počtem spojení na databázi. Ale abych to mohl posoudit, potřebuji vidět i kolik chodí požadavků na tu službu, nestačí si jen grepnout něco v terminálu. Obzvlášť, když ani nemám do produkčního prostředí přístup na shell.
Nebo pokud jde o nějakou službu/server od někoho jiného - asi bude mít nějaký endpoint co bude produkovat metriky pro Prometheus, ale těžko do něj budu dělat binární patche, abych si tam přidal http call. Nedej bože, když to ani neběží na mém železe. To se pak najednou nějaké monitorovací systémy, kde se to všechno sbírá dohromady, začnou pořádně hodit.
Zní to rozumně, velký projekt a tým má jiné požadavky. Nicméně předpokládám, že většina projektů (alespoň v době kdy začínají) jede spíše v menším týmu a vyhnout se parním mlátičkám může být výhoda. Alespoň pro začátečníky určitě.
Problém nezahltit je zde vždy. Na telegram je třeba posílat opravdu jen urgentní věci, jako že něco opravdu spadlo nebo to bezprostředně hrozí. Zbytek stačí do mailu nebo jiného systému, nebo jen logovat případně posílat jednou za čas reporty.
-
Tak jsem to netxms nainstaloval, zatím ale teda plavu v rozchození webového rozhraní - návody na https://www.netxms.org/documentation/adminguide/installation.html#custom-logo-on-login-screen
jsou docela zmatečný - prakticky nic nefachalo, jak mělo, nemáte někdo někde návod, kde je to fakt krok za krokem, aby to i hloupý strojař pochopil (tzn. i s nastavením reverzní proxy apod..)? Díky moc za ochotu...
-
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 (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 (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.
Tak jsem to netxms nainstaloval, zatím ale teda plavu v rozchození webového rozhraní - návody na https://www.netxms.org/documentation/adminguide/installation.html#custom-logo-on-login-screen
jsou docela zmatečný - prakticky nic nefachalo, jak mělo, nemáte někdo někde návod, kde je to fakt krok za krokem, aby to i hloupý strojař pochopil (tzn. i s nastavením reverzní proxy apod..)? Díky moc za ochotu...
-
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 (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 (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:
× 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.
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)..
-
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
apt install build-essential autoconf libssl-dev libpcre2-dev libmodbus-dev
stáhněte zdrojové kódy netxms ze stránek 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
./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
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 (http://LogFile=/var/log/nxagentd)
Pevné nervy přeji.
-
......
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 (http://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í curl ifconfig.me, ale jsem stoprocentně za milionem natů
-
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 (http://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í curl ifconfig.me, ale jsem stoprocentně za milionem natů
-
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...
-
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.
-
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 (https://www.xda-developers.com/docker-containers-help-monitor-entire-home-lab/), 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).
-
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..
-
ta přístupnost pouze z tunelu a ne z internetu, je podle mě symptom toho, že tok komunikace nejde stejnou cestou (příchozí a odchozí) - důsledek je ,že odpovědi přichází z jiné IP (a nebo ani neodcházejí, pokud je filtru je něco po cestě nezařízne : od samotného původce(myšleno "odpovědce"- server-kde se requesty mění v odpovědi)/ rp-filter nebo nějaký firewall hlídající ct-state invalid) --
nemá některý ze strojů jako default route wireguard rozhraní?
Nevím který přesně to je článek, ale možná "policy routing" a nebo některý ze série (https://www.root.cz/serialy/wireguard-pro-jednoduchou-linuxovou-vpn/) zde na root.cz.