Сутринта получих мониторингов имейл от Baidu и установих, че сайтът не може да бъде отворен и тогава няма за какво да се притеснявате, защото сайтът не може да бъде отворен, а възможните причини са следните:
1: Сервитьорът е в изоставане
2: Сървърът е атакуван
Тогава не обърнах много внимание, измих си зъбите и измих лицето си, за да отида на работа, след което включих компютъра, за да посетя уебсайта на Alibaba Cloud, и за да видя дали е атакуван или просрочен, установих, че няма просрочени задължения или атака.
След това се свързах със сървъра чрез ssh, рестартирах сървъра, изчаках 5 минути и установих, че сървърът не може да бъде свързан, и установих, че нещата не са толкова лесни!!
Тъй като външната мрежова връзка не може да бъде свързана, нека използваме VNC за свързване, тоест да влезем в конзолата на уебсайта на Alibaba Cloud, за да имаме отдалечена връзка, която е уеб версията на отдалечената връзка, и да се премине през интранет, и след това да се намери черен екран!!
Нещата стават все по-малко опростени, чувствам, че нещо не е наред с Alibaba Cloud??? (Защото не съм пипал никаква операция на сървъра) Първо подадох поръчка за работа, обясних ситуацията и после започнах работа...
В метрото, влезте в приложението Alibaba Cloud, обърнете внимание на обратната връзка по поръчка по всяко време, изведнъж на страницата на приложението има съобщение, линк: https://help.aliyun.com/noticelist/articleid/20651342.html
(Възстановено) На 12 ноември 2017 г. по пекинско време беше обявено взаимното посещение на телекомуникациите север-юг
Лично аз предполагам, че проблемът е от страна на Alibaba Cloud и дали е причинен от някои официални услуги на Alibaba Cloud или интерфейси, които не са се върнали към нормалното????
След обратната връзка за тикет в Alibaba Cloud установих, че мога да използвам ssh към сървъра, но след рестартиране не можех да се свържа със сървъра и многократно комуникирах с тикета, а телефонът беше комуникиран дълго време.
Дори и SSH да може да бъде свързан, някои услуги на сървъра не могат да работят нормално, като mysql сървъра, който не стартира нормално...
Накрая, билетът отговаря по следния начин:
Хост отдалечената връзка, както и възстановяването, тествате надолу.
Текущ проблем: В rc.local е зададена необичайна стартова задача, което кара системата да не се стартира напълно след стартиране и картата да бъде мастерирана, както е показано в Приложение 1.
След като коментирате съдържанието в rc.local, то ще се върне към нормалното, моля, проверете дали има някакви аномалии в услугата.
След обработка отворете съдържанието в rc.local.
Изглежда разбирам нещо, а именно, че някои услуги на сървъра не стартираха нормално, а после ръчно стартирах mysql и установих, че не може да се стартира за 30 секунди, и установих, че нещата не са толкова прости。。。。。
Чрез личната си интуиция натиснах командата df -h, за да проверя използването на място на твърдия диск, и открих, че има парче пространство, което заема 100% от мястото!!!
Накрая, намерете топ 10 файла, които заемат място на диска, и намерете файл, по-голям от 12g, който е лог файл на nginx,
Трябва да еДисковото пространство е пълно, което води до повредаПроменете конфигурационните параметри на nginx логовете, след това изтрийте nginx лог файловете, рестартирайте сървъра и някои ще се върнат към нормалното.
Конфигурацията на nginx има яма.Когато сървърният сегмент не посочва access_log и не са посочени access_log параметри в http сегмента, той по подразбиране се записва във файла logs/access.log, тоест стойността по подразбиране access_log "logs/access.log", и това е логът за достъп на всички сървъри。
|
Публикувано в 13.11.2017 г. 12:16:27 ч.
|
|
|
|
Хазяин|
Публикувано в 13.11.2017 г. 12:22:36 ч.
|
