Serverul la distanță pare să fie mort, cum să depanați?

Am un server Ubuntu care rulează de la distanță într-un alt birou. A murit de câteva ori și nu-mi dau seama care este cauza. Este un server care solicită servicii externe prin api. De mort Adică încă funcționează, dar nu mai funcționează. Rețeaua serverului pare să fie și ea offline și o scanare lan nu o găsește.

Este în spatele unui router de birou și rulează nucleul 18.04 4.15.0-147-generic. Nimeni de la fața locului nu are cont pe acest server.

Iată ce am încercat.

1. ultima repornire rezultat:

reporniți sistemul de pornire 4.15.0-151-gener Joi 22 iulie 14:49 încă rulează
reporniți sistemul de pornire 4.15.0-147-gener miercuri 21 iulie 15:48 încă rulează
reporniți sistemul de pornire 4.15.0-147-gener miercuri 21 iulie 14:05 - 15:48 (01:43)
reporniți sistemul de pornire 4.15.0-147-gener sâmbătă, 17 iulie 18:24 - 15:48 (3+21:24)
reporniți sistemul de pornire 4.15.0-147-gener Joi, 15 iulie 17:26 - 15:48 (5+22:22)

22 iul 14:49 a fost o repornire pe care am cerut personalului de la fața locului să o facă. Pe 21 iulie a avut loc o întrerupere a curentului.

2. /var/log/syslog

22 iulie 09:08:50 localhost service_start.sh[946]: INFO:launcher:myjob finalizează o ieșire pentru 2.
22 iulie 09:08:50 localhost service_start.sh[946]: INFO:launcJul 22 14:50:05 localhost systemd[1]: Se pornește jurnalul Flush pentru stocarea persistentă...
22 iulie 14:50:05 localhost systemd[1]: a pornit demonul de metadate LVM2.
22 iulie 14:50:05 localhost systemd[1]: A început încărcarea/salvarea semințelor aleatorii.
22 iulie 14:50:05 localhost lvm[443]: 2 volum(e) logic(e) în grupul de volume „localhost-vg” monitorizat
22 iulie 14:50:05 localhost systemd[1]: A început Setați aspectul tastaturii consolei.
22 iulie 14:50:05 localhost systemd-modules-load[436]: Modulul inserat „iscsi_tcp”

După aceea, sistemul a fost offline 22 iulie 09:08:50. 22 iul 14:50:05 a fost repornirea menționată anterior.

Se pare că sistemul nu a fost repornit sau oprit, altfel ar trebui să existe un jurnal care să indice asta. Și nu există nici un jurnal de erori de sistem în syslog.

Există două joburi cron de utilizator configurate pentru a rula la fiecare 5 și 10 minute și au existat intrări care rulează cron în syslog. 22 iulie 09:05:01 înainte ca sistemul să devină mort în jur 22 iulie 09:08:50.

Nu există oameni tehnici la fața locului și pot ajunge la server doar prin teamview de pe un alt computer la fața locului în acest moment.

Am rulat htop și încărcarea sistemului a fost ușoară.

Sunt în pierdere chiar acum. Ce altceva ar trebui să verific în timpul următoarei mele sesiuni de teamview?

Aveți destul de multe variabile în descrierea problemei dvs., în primul rând infrastructura de rețea din locația în care este găzduit serverul. Dacă acesta ar fi serverul meu, un prim pas ar fi să intru în el și să fac:

coada -f /var/log/syslog

Acest lucru, sau monitorizarea unuia dintre celelalte fișiere jurnal, ar putea arunca o lumină asupra cauzei care cauzează ca serverul să nu mai răspundă.

Din moment ce spuneți că serverul încă funcționează, chiar dacă este mort (nu este clar ce înseamnă asta), acest tip de conexiune implică pierderea conexiunii la rețea, așa că pe asta mi-aș concentra monitorizarea.

S-ar putea să descoperiți că cea mai rapidă modalitate de a rezolva acest lucru este depanarea la fața locului prin intermediul rețelei locale LAN.