ორი წლის წინ უკვე გავაკეთე პოსტი მარტივი მარცხი ვებსაიტისთვის შესახებ ოკერრ. ახლა არის პროექტის გარკვეული განვითარება და მეც გამოვაქვეყნე okerr სერვერის გვერდითი კოდი ფარგლებში ღია ლიცენზია, ამიტომ გადავწყვიტე დამეწერა ეს მოკლე მიმოხილვა Habr-ზე.

[ სრული ზომა ]

ვისთვისაც შეიძლება დაინტერესდეს

ეს შეიძლება იყოს თქვენთვის საინტერესო, თუ მუშაობთ მცირე გუნდში ან მარტო. თქვენ არ გაქვთ მონიტორინგი და არ ხართ დარწმუნებული, ნამდვილად გჭირდებათ თუ არა. ან თქვენ სცადეთ რაიმე პოპულარული სერიოზული მონიტორინგი „დიდი ბიჭებისთვის“, მაგრამ ის რატომღაც „არ აფრინდა“ თქვენთვის, ან ის მუშაობს თითქმის ნაგულისხმევ კონფიგურაციაში და დიდად არ შეცვლილა თქვენი ცხოვრება. და ასევე - თუ თქვენ ნამდვილად არ აპირებთ მთელი თანამშრომლის (ან თუნდაც განყოფილების) გამოყოფას მონიტორინგის დაფის მონიტორინგისთვის დღეში მინიმუმ ორი საათის განმავლობაში ან მისი კონფიგურაცია.

რატომ არის okerr უჩვეულო

შემდეგ მე გაჩვენებთ ოკერას საინტერესო მახასიათებლებს, რომლებიც განასხვავებს მას ზოგიერთი სხვა მონიტორინგის სისტემებისგან.

Okerr არის ჰიბრიდული მონიტორინგი

შიდა მონიტორინგის დროს მონიტორინგულ მანქანებზე მუშაობს „აგენტი“, რომელიც გადასცემს მონაცემებს მონიტორინგის სერვერზე (მაგალითად, თავისუფალი ადგილი დისკზე). როდესაც გარე, სერვერი ახორციელებს შემოწმებებს ქსელში (მაგალითად, ping ან ვებსაიტის ხელმისაწვდომობა). თითოეულ მიდგომას აქვს თავისი შეზღუდვები. Okerr იყენებს ორივე ვარიანტს. სერვერების შიგნით შემოწმებას ახორციელებს ძალიან მსუბუქი (30Kb) აგენტი ან თქვენი საკუთარი სკრიპტები და აპლიკაციები, ხოლო ქსელის შემოწმება ხდება okerr სენსორების მეშვეობით სხვადასხვა ქვეყანაში.

okerr არ არის მხოლოდ პროგრამული უზრუნველყოფა, არამედ სერვისიც

ნებისმიერი მონიტორინგის სერვერის ნაწილი დიდი და რთულია, რთულია ინსტალაცია და კონფიგურაცია და საჭიროებს რესურსებს. okerr-ით შეგიძლიათ დააინსტალიროთ თქვენი საკუთარი მონიტორინგის სერვერი (ის არის უფასო და ღია წყარო), ან შეგიძლიათ უბრალოდ გამოიყენოთ კლიენტის ნაწილი და გამოიყენოთ ჩვენი სერვერის სერვისი. ასევე უფასო.

თუ მონიტორინგი საშუალებას გაძლევთ კომპენსირება და დაფაროთ სერვერებსა და აპლიკაციებში საიმედოობის ნაკლებობა, მაშინ ჩნდება ფილოსოფიური კითხვა - ვინ არის მცველი? როგორ გვეტყვის მონიტორინგი პრობლემის შესახებ, თუ ის თავად „მოკვდა“ რაიმე მიზეზით, ცალკე ან თქვენს სხვა რესურსებთან ერთად (მაგალითად, დაეცა არხი მონაცემთა ცენტრისკენ)? გარე სერვისის okerr-ის გამოყენებისას - ეს პრობლემა მოგვარებულია - თქვენ მიიღებთ გაფრთხილებას მაშინაც კი, თუ მთელი მონაცემთა ცენტრი თქვენს სერვერებთან არის ელექტროენერგიის გარეშე ან თავს დაესხმება ზომბებს.

რა თქმა უნდა, არსებობს რისკი, რომ თავად okerr სერვერი მიუწვდომელი იყოს, ეს ასეა (როგორც მოგეხსენებათ, საიმედოობის 90% ყოველთვის მიიღება მარტივად და "უფასოდ", 99% მინიმალური ძალისხმევით, და ყოველი მომდევნო ცხრა არის ექსპონენტურად უფრო რთული). მაგრამ, ჯერ ერთი, ამის შანსი ნაკლებია და მეორეც, პრობლემა შეიძლება შეუმჩნეველი დარჩეს მხოლოდ იმ შემთხვევაში, თუ ის ემთხვევა ჩვენს სერვერებზე არსებულ პრობლემებს. თუ ჩვენ გვაქვს 99.9% სანდოობა და თქვენ გაქვთ 99.9% (არც თუ ისე მაღალი რიცხვები), მაშინ გამოუცნობი მარცხის შანსი არის 0.1% 0.1% = 0.0001%. სამი ცხრიანის დამატება თქვენს საიმედოობას თითქმის ძალისხმევისა და ხარჯების გარეშე ძალიან კარგია!

მონიტორინგის, როგორც სერვისის კიდევ ერთი უპირატესობა არის ის, რომ ჰოსტინგის პროვაიდერს ან ვებ სტუდიას შეუძლია დააინსტალიროს okerr სერვერი და უზრუნველყოს კლიენტებზე წვდომა ფასიანი ან უფასო დამატებითი სერვისის სახით. თქვენს კონკურენტებს უბრალოდ აქვთ ჰოსტინგი და ვებსაიტები, მაგრამ თქვენ გაქვთ საიმედო ჰოსტინგი მონიტორინგით.

Okerr არის ინდიკატორების შესახებ

ინდიკატორი არის "ნათურა". მას აქვს ორი ძირითადი მდგომარეობა - მწვანე (OK) ან წითელი (ERR). პროექტი შეიცავს ბევრ დაჯგუფებულ (მაგალითად, სერვერის მიხედვით) ინდიკატორებს. პროექტის მთავარ გვერდზე მაშინვე ხედავთ, რომ ან ყველაფერი მწვანეა (და შეგიძლიათ დახუროთ), ან რაღაც წითლად ანათებს და საჭიროებს გამოსწორებას. ამ მდგომარეობებს შორის გადასვლისას, გაფრთხილება იგზავნება. დღეში ერთხელ, სანამ თქვენ აყენებთ მას, იგზავნება პროექტის შეჯამება.

თითოეულ okerr ინდიკატორს აქვს ჩაშენებული პირობები, რომლითაც ის ცვლის მდგომარეობას (Zabbix-ში ამას ტრიგერი ეწოდება). მაგალითად, დატვირთვის საშუალო არ უნდა იყოს 2-ზე მეტი (რა თქმა უნდა, ეს კონფიგურირებადია). და ყოველი შიდა შემოწმებისთვის (დატვირთვის საშუალო, დისკის გარეშე, ...) არის მცველი. თუ რაიმე მიზეზით არ მივიღებთ წარმატებულ დადასტურებას დანიშნულ დროს, შეცდომის დაფიქსირება და გაფრთხილება იგზავნება.

ჩვენი ჩვეული სამუშაო ნიმუშია დილით ელ.ფოსტის შემოწმება და სხვა წერილებს შორის შეჯამების დათვალიერება (ჩვენ ვგეგმავთ მას მუშაობის დასაწყისში). თუ მასში ყველაფერი წესრიგშია, ჩვენ ვაკეთებთ სხვა მნიშვნელოვან საკითხებს (მაგრამ უსაფრთხოების მიზნით, შეგვიძლია სწრაფად გადავხედოთ okerra-ს დაფა და დავრწმუნდეთ, რომ ამ მომენტში ყველაფერი მწვანეა). თუ გაფრთხილება მოვა, ჩვენ ვრეაგირებთ.

რა თქმა უნდა, შესაძლებელია უბრალოდ შევინარჩუნოთ „ინფორმაციული“ ინდიკატორები (ქსელის სურათის დანახვა მონიტორინგისგან), მაგრამ ყველაფერი კეთდება იმისათვის, რომ უბრალოდ, მარტივად და სწრაფად შეიქმნას ინდიკატორები სპეციალურად ავტომატური მონიტორინგისა და სიგნალიზაციისთვის.

დანიშნულება, რისთვისაც თქვენ აყენებთ okerr-ს, არის სიგნალიზაცია, ასე რომ თქვენ შეგიძლიათ შექმნათ ინდიკატორი წუთში, მას შეუძლია ერთი წლის განმავლობაში "დაიძინოს", უბრალოდ მიიღოს განახლებები და როდესაც ერთი წლის შემდეგ რაღაც იშლება, ის ანათებს და აგზავნის. გაფრთხილება. იმ წუთმა, რომელიც ერთხელ დახარჯეთ ინდიკატორის შექმნაზე, შედეგი გამოიღო; პრობლემის შესახებ მაშინვე გაიგეთ სხვებზე ადრე. შესაძლებელია, რომ მათ გაასწორეს, სანამ ვინმე შეამჩნევდა. სწრაფად აწეული რაღაც არ ითვლება დავარდნილად!

უსაფრთხოების

სირცხვილი იქნება, თუ დააყენებთ მონიტორინგს საიმედოობის გაზრდის მიზნით, მაგრამ შედეგად, თქვენ თავს დაესხმიან ქსელის მეშვეობით და საკმაოდ ბევრია ქსელის დაუცველობა სხვადასხვა მონიტორინგის ინსტრუმენტებში (ზაბქსი, Nagios).

აგენტი (ოკერმოდი პაკეტიდან okerrupdate) სისტემაში გაშვებული არ არის ქსელის სერვერი, არამედ კლიენტი. მაშასადამე, მონიტორირებულ სერვერზე არ არის დამატებითი ღია პორტები, კლიენტი ადვილად მუშაობს firewall-ის ან NAT-ის მიღმა და ძალიან რთულია (მე ვიტყოდი „შეუძლებელი“) ქსელის გატეხვა, რადგან პრინციპში ის არ უსმენს ქსელს. სოკეტი.

სრული მონიტორინგის გაშუქება

ახლა ჩვენი წესია, რომ ყველა ტექნიკურ პრობლემას ვსწავლობთ okerr-ისგან. თუ უეცრად დაირღვა წესი (okerr-მა არ გააფრთხილა მისი გარდაუვალი შემთხვევის შესახებ (თუ ეს შესაძლებელია) ან რომ ეს უკვე მოხდა) - ჩვენ ვამატებთ ჩეკებს okerr-ს.

გარე შემოწმება

საკმაოდ ტიპიური ნაკრები:

• Ping
• http სტატუსი
• SSL სერთიფიკატის მოქმედების და სიახლის შემოწმება (გააფრთხილებს, თუ ვადა ამოიწურება)
• გახსენით TCP პორტი და მასზე ბანერი
• http grep (გვერდი [არ უნდა] შეიცავდეს კონკრეტულ ტექსტს)
• sha1 ჰეში, რათა დაიჭიროთ გვერდის ცვლილებები.
• DNS (DNS ჩანაწერს უნდა ჰქონდეს კონკრეტული მნიშვნელობა)
• WHOIS (გააფრთხილებს, თუ დომენი გაუარესდება)
• ანტისპამი DNSBL (მასპინძლის შემოწმება 50+ ანტისპამის შავ სიებში ერთდროულად)

შიდა შემოწმებები

ასევე, საკმაოდ სტანდარტული ნაკრები (მაგრამ ადვილად გაფართოებადი).

• df (თავისუფალი ადგილი დისკზე)
• საშუალო დატვირთვა
• opentcp (გახსენით TCP მოსასმენი სოკეტები - შეგატყობინებთ, თუ რამე დაიწყო ან გაფუჭდა)
• uptime - უბრალოდ uptime სერვერზე. შეგატყობინებთ, თუ შეიცვალა (ანუ სერვერი გადატვირთულია)
• client_ip
• dirsize - ჩვენ ვიყენებთ მას, რათა თვალყური ადევნოთ, როდესაც ჩვენი ვირტუალური მანქანის rootfs აჭარბებს დაშვებულ ზომას, მკაცრი შეზღუდვების დაწესების გარეშე და მომხმარებლის სახლის დირექტორიების ზომის
• ცარიელი და არა ცარიელი - აკონტროლეთ ფაილები, რომლებიც უნდა იყოს ცარიელი (ან არა ცარიელი). მაგალითად, თავად okerr სერვერის შეცდომის ჟურნალი ცარიელი უნდა იყოს და თუ მასში არის თუნდაც სტრიქონი, მივიღებ შეტყობინებას და ვამოწმებ. მაგრამ mail.log ფოსტის სერვერზე არ უნდა იყოს ცარიელი (როტაციიდან N წუთი). და ზოგჯერ ის ცარიელი იყო ჩვენთვის სისტემის განახლების შემდეგ, როდესაც logrotate ვერ გადატვირთა rsyslog სწორად.
• linecount - ხაზების რაოდენობა ფაილში (როგორც wc -l). ჩვენ ვიყენებთ მას, როგორც ცარიელის უფრო რბილ ჩანაცვლებას, როდესაც შეცდომების ჟურნალი ჯერ კიდევ შეიძლება გაიზარდოს, მაგრამ მხოლოდ ნელა (მაგალითად, Googlebot ხვდება ზოგიერთ დახურულ გვერდს). 2 წუთში არის 20 ხაზის ლიმიტი. თუ ის უფრო მაღალია, იქნება გაფრთხილება

საინტერესო შიდა შემოწმებები

თუ ამ მომენტამდე „დიაგონალურად“ კითხულობდით, ახლა უფრო საინტერესო იქნება ყურადღებით წაკითხვა.

სარეზერვო

აკონტროლებს სარეზერვო ასლებს დირექტორიაში. ჩვენს სარეზერვო ფაილებს აქვთ სახელები, როგორიცაა "ServerName-20200530.tar.gz". okerr-ში თითოეული სერვერისთვის იქმნება ინდიკატორი ServerName-DATE.tar.gz (ფაქტობრივი თარიღი იცვლება სტრიქონში „DATE“). ასევე კონტროლდება ახალი სარეზერვო ასლის არსებობა და მისი ზომა (მაგალითად, ის არ შეიძლება იყოს წინა სარეზერვო ასლის 90%-ზე ნაკლები).

რა უნდა გაკეთდეს იმისათვის, რომ ახალი სარეზერვო ასლის თვალყურის დევნება დაიწყოს მას შემდეგ, რაც დავიწყეთ მისი შექმნა და ამ დირექტორიაში განთავსება? არაფერი! ეს არის ძალიან მოსახერხებელი მიდგომა, როდესაც თქვენ გჭირდებათ "არაფრის" გაკეთება, რადგან:

• „არაფრის“ კეთება საკმაოდ სწრაფია, ის დაზოგავს დროს
• ძნელია დაივიწყო "არაფრის" გაკეთება
• ძნელია შეცდომით „არაფერის“ გაკეთება. არაფერია ყველაზე საიმედო მეთოდი

თუ მოულოდნელად ახალი სარეზერვო ფაილების გამოჩენა შეწყდება, იქნება გაფრთხილება. თუ, მაგალითად, გათიშეთ ერთ-ერთი სერვერი და აღარ უნდა იყოს სარეზერვო ასლები, მოგიწევთ ინდიკატორის წაშლა (ვებ ინტერფეისის საშუალებით ან ჭურვიდან API-ის საშუალებით).

maxfilesz

თვალყურს ადევნებს ყველაზე დიდი ფაილების ზომას (ჩვეულებრივ: /var/log/*). ეს საშუალებას გაძლევთ დაიჭიროთ არაპროგნოზირებადი პრობლემები, მაგალითად, უხეში ძალის პაროლები ან სერვერის მეშვეობით სპამის გაგზავნა.

runstatus/runline

ეს არის ორი მნიშვნელოვანი პროქსი მოდული სერვერზე სხვა პროგრამების გასაშვებად. Runstatus აცნობებს პროგრამის გასვლის კოდს ინდიკატორზე. მაგალითად, okerr არ (მოითხოვს) მოდულს, რომ შეამოწმოს systemd სერვისების გაშვება. ეს კეთდება runstatus-ის მეშვეობით (იხ. ქვემოთ). Runline - აცნობებს სერვერს იმ ხაზს, რომელსაც პროგრამა აწარმოებს. Მაგალითად, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" ჩვენს სერვერზე Runline კონფიგურაციაში ქმნის ინდიკატორს სერვერის სახელი:ტემპი პროცესორის ტემპერატურასთან.

sql

ახორციელებს ციფრულ მოთხოვნას MySQL-ში და აცნობებს შედეგს ინდიკატორს. მარტივ შემთხვევაში, შეგიძლიათ გააკეთოთ, მაგალითად, "SELECT 1" - ეს შეამოწმებს, რომ DBMS მთლიანობაში მუშაობს.

მაგრამ ბევრად უფრო საინტერესო აპლიკაციაა, მაგალითად, ონლაინ მაღაზიაში შეკვეთების რაოდენობის თვალყურის დევნება. თუ იცით, რომ გაქვთ 100 ან მეტი შეკვეთა საათში, შეგიძლიათ დააყენოთ მინიმალური ლიმიტი 100 ან 80-მდე. შემდეგ თუ თქვენი გაყიდვები მოულოდნელად შემცირდება, თქვენ მიიღებთ გაფრთხილებას და შეგიძლიათ ამის გარკვევა.

გაითვალისწინეთ, რომ არ აქვს მნიშვნელობა რა არაპროგნოზირებადი მიზეზით მოხდა ეს:

• სერვერი უბრალოდ მიუწვდომელია (გამორთულია ან ქსელის გარეშე) და გაფრთხილება მოვიდა იქიდან, რომ ინდიკატორი იყო "დამპალი".
• სერვერი გადატვირთულია რაღაცით, მუშაობს ნელა ან იკარგება პაკეტები, ეს მოუხერხებელია მომხმარებლებისთვის და ისინი ტოვებენ შესყიდვის გარეშე
• სერვერი შედის სპამის სიებში და მისგან ფოსტა არ მიიღება, მომხმარებლები ვერ დარეგისტრირდებიან
• სარეკლამო კამპანიის ბიუჯეტი ამოიწურა, ბანერები არ ტრიალებს.

შეიძლება არსებობდეს მრავალი მიზეზი და ყველა მათგანის წინასწარ პროგნოზირება შეუძლებელია და ტექნიკურად რთულია თვალყურის დევნება. მაგრამ თქვენ შეგიძლიათ მოხერხებულად აკონტროლოთ საბოლოო პარამეტრი (ბრძანებები) და დაადგინოთ, რომ სიტუაცია საეჭვოა და იმსახურებს მოგვარებას.

ლოგიკური ინდიკატორები

საშუალებას აძლევს გამოიყენოს ლოგიკური გამონათქვამები (პითონის სინტაქსი) მოდულის მეშვეობით დამოწმება(სტატია ჰაბრეზე). პროექტის მონაცემები და მისი ინდიკატორები ხელმისაწვდომია გამოხატვისთვის. მაგალითად, ზემოთ SQL-ის შემოწმების შესახებ თავში შეიძლება შენიშნეთ სუსტი წერტილი - დღის განმავლობაში შეიძლება გვქონდეს 100 გაყიდვა საათში, ღამით კი - 20 და ეს ჩვეულებრივია და არა პრობლემა. Რა უნდა გავაკეთო? ინდიკატორი ღამით მუდმივად პანიკაში იქნება.

თქვენ შეგიძლიათ შექმნათ ორი ინდიკატორი, დღე და ღამე. გააკეთეთ ორივე „ჩუმად“ (ისინი არ გამოაგზავნიან სიგნალებს). და შექმენით ლოგიკური ინდიკატორი, რომელიც მოითხოვს, რომ დღის მაჩვენებელი 20:00 საათამდე იყოს OK, ხოლო 20:00 საათის შემდეგ საკმარისია ღამის მაჩვენებელი იყოს OK.

ლოგიკური ინდიკატორის გამოყენების კიდევ ერთი მაგალითია ესკალაცია. მაგალითად, პროექტის მენეჯერი გააუქმებს სიგნალებს (მას ამის საჭიროება არ აქვს, ადმინისტრატორებმა უნდა უპასუხონ ნორმალურ პრობლემებს), მაგრამ გამოიწერს ლოგიკურ ინდიკატორს, რომელიც წითლდება, თუ პროექტში რომელიმე ინდიკატორი არ არის გამოსწორებული დანიშნულ დროში.

ასევე, შესაძლებელია სამუშაოსთვის ნებადართული დროის დაწესება, მაგალითად, დილის 3-დან 5 საათამდე. ჩვენ არ გვაინტერესებს ამ დროის განმავლობაში სერვერები და საიტები იშლება თუ არა. მაგრამ 5:00 საათზე უნდა იმუშაონ. თუ ისინი სხვა დროს არ მუშაობენ - გააფრთხილეთ. ლოგიკური მაჩვენებელი ასევე საშუალებას გაძლევთ გაითვალისწინოთ სერვერის სიჭარბე. თუ თქვენ გაქვთ 5 ვებ სერვერი, მაშინ ადმინისტრატორებს შეუძლიათ ნებისმიერ დროს გამორთონ 1-2 სერვერი. მაგრამ თუ ბრძოლაში 3 სერვერიდან 5-ზე ნაკლებია, იქნება გაფრთხილება.

ზემოთ მოყვანილი მაგალითები არ არის ოკერის ფუნქციები და არა ზოგიერთი ფუნქცია, რომელიც უნდა იყოს გააქტიურებული და კონფიგურირებული. Okerra-ს არ აქვს ყველა ეს ფუნქცია, მაგრამ არსებობს ლოგიკური მოდული, რომელიც საშუალებას გაძლევთ განახორციელოთ ეს ფუნქცია (დაახლოებით, როგორც პროგრამირების ენაში - თუ გვაქვს არითმეტიკული ოპერატორები, მაშინ არ გვჭირდება სპეციალური ფუნქცია 20% დღგ-ის გამოსათვლელად. ენიდან, თქვენ ყოველთვის შეგიძლიათ ამის გაკეთება საკუთარ თავს, რათა მოერგოს თქვენს საჭიროებებს).

ლოგიკური ინდიკატორი ალბათ ერთ-ერთია okerr-ში შედარებით რთული თემებიდან, მაგრამ კარგი ამბავი ის არის, რომ თქვენ არ გჭირდებათ მისი ათვისება, სანამ არ დაგჭირდებათ. მაგრამ ამავე დროს, ისინი მნიშვნელოვნად აფართოებენ შესაძლებლობებს, ხოლო თავად სისტემას საკმაოდ მარტივია.

საკუთარი ჩეკების დამატება

მე ნამდვილად მსურს გადმოგცეთ აზრი, რომ okerr არ არის ათასობით მზა ჩეკების ნაკრები ყველა შემთხვევისთვის, არამედ პირიქით - უპირველეს ყოვლისა - მარტივი ძრავა საკუთარი ჩეკების შექმნის მარტივი უნარით. საკუთარი ჩეკების შექმნა okerr-ში არ არის დავალება ჰაკერებისთვის, სისტემის თანადეველოპერებისთვის ან, სულ მცირე, მოწინავე okerr მომხმარებლებისთვის, მაგრამ შესასრულებელი ამოცანაა ნებისმიერი ადმინისტრატორისთვის, რომელმაც პირველად დააინსტალირა Linux ერთი თვის წინ.

მინიმალური ხელფასის შემოწმება ხდება მოდულის საშუალებით გაშვების სტატუსი:

ეს ხაზი კონფიგურაციაში გაშვების სტატუსი შეგატყობინებთ, თუ /bin/true მოულოდნელად არ დაიწყება ან დააბრუნებს 0-ის გარდა სხვა რამეს.

true_OK=/bin/true

მხოლოდ ერთი ხაზი - და აქ ჩვენ უკვე ცოტა ვართ გაფართოვდა ფუნქციონალობა okerr.

ასეთ შემოწმებასაც უკვე აქვს თავისი ღირებულება: თუ მოულოდნელად თქვენი სერვერი გაფუჭდა, okerr სერვერზე შესაბამისი ინდიკატორი დროულად არ განახლდება და დროის გასვლის შემდეგ გამოჩნდება გაფრთხილება.

ეს შემოწმება შეატყობინებს, რომ apache2 სერვერი გაფუჭდა (კარგად, თქვენ არასოდეს იცით ...):

apache_OK="systemctl is-active --quiet apache2"

ასე რომ, თუ თქვენ საუბრობთ პროგრამირების რომელიმე ენაზე და მინიმუმ შეგიძლიათ დაწეროთ shell სკრიპტები, მაშინ უკვე შეგიძლიათ დაამატოთ თქვენი საკუთარი ჩეკები.

უფრო რთული - შეგიძლიათ დაწეროთ (ნებისმიერ ენაზე) თქვენი საკუთარი მოდული okerrmod-ისთვის. უმარტივეს შემთხვევაში ასე გამოიყურება:

#!/usr/bin/python3

print("STATUS: OK")

ძალიან რთული არ არის? მოდულმა თავად უნდა გააკეთოს შემოწმება და გამოსცეს შედეგები STDOUT-ზე. უფრო რთული მოდული იძლევა, მაგალითად, შემდეგს:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

ის ერთდროულად აახლებს რამდენიმე ინდიკატორს (გამოყოფილი ცარიელი ხაზით), საჭიროების შემთხვევაში ქმნის მათ, მიუთითებს გადამოწმების დეტალებს და ტეგს, რომლითაც ადვილია საჭირო ინდიკატორების პოვნა დაფაზე.

დეპეშა

არის Telegram ბოტი @OkerrBot. თქვენ არ გჭირდებათ თქვენი ტელეფონის გადატვირთვა ცალკეული აპლიკაციებით (მე არ მომწონს, რომ Pyaterochka-სთვის გჭირდებათ ერთი აპლიკაცია რუქით, Lenta-სთვის მეორე, MTS-ისთვის მესამე და ასე შემდეგ ყველასთვის, ყველასთვის, ყველასთვის). საკმარისია ერთი დეპეშა. ტელეგრამის საშუალებით შეგიძლიათ დაუყოვნებლივ მიიღოთ შეტყობინებები, შეამოწმოთ პროექტის სტატუსი და მისცეთ ბრძანება ხელახლა გადაამოწმოთ ყველა პრობლემური ინდიკატორი. გამოვედით თეატრიდან/თვითმფრინავიდან, ორი საათის განმავლობაში თითი არ გვქონდა პულსზე, ჩავრთეთ ტელეფონი, ჩატბოტში ერთ ღილაკს დავაჭირეთ და დავრწმუნდით, რომ ყველაფერი კარგად იყო.

სტატუსის გვერდები

დღესდღეობით, სტატუსის გვერდები თითქმის აუცილებელია ნებისმიერი ბიზნესისთვის, რომელსაც აქვს IT, პასუხისმგებლიანი დამოკიდებულება სანდოობის მიმართ და რომელიც თავის კლიენტებს/მომხმარებლებს პატივისცემით ეპყრობა.

წარმოიდგინეთ სიტუაცია - მომხმარებელს სურს რაღაცის გაკეთება, ინფორმაციის ნახვა ან შეკვეთის გაკეთება და რაღაც არ მუშაობს. მან არ იცის რა ხდება, ვის მხარეზეა პრობლემა და როდის მოგვარდება. იქნებ თქვენს კომპანიას უბრალოდ აქვს არაფუნქციონალური ვებსაიტი? ანუ ექვსი თვის წინ გატყდა და ორ წელიწადში გამოსწორდება? მაგრამ მაცივარი ახლავე უნდა იყიდო, ის უკვე კალათაშია... და სულ სხვა საქმეა, როცა ადამიანი ხედავს, რომ რაღაც გჭირს (ყოველ შემთხვევაში, აშკარაა, რომ პრობლემა მის მხარეს არ არის), რომ აღმოჩენილია პრობლემა, რომ თქვენ უკვე მუშაობთ მასზე და შესაძლოა დაწეროთ გამოსწორების სავარაუდო დროც. მომხმარებელს შეუძლია გამოიწეროს და მიიღოს შეტყობინება ელექტრონული ფოსტით, როდესაც პრობლემა მოგვარდება და შეუძლია გააკეთოს ის, რაც მას სურდა (შეიძინოს მაცივარი).

პრობლემები და შეფერხებები ყველას ემართება. მაგრამ მომხმარებლები და პარტნიორები უფრო მეტად ენდობიან მათ, ვინც უფრო გამჭვირვალე და პასუხისმგებელია ამ მიდგომით.

აქ 10 სხვა პროექტის მიმოხილვა, რომელიც საშუალებას გაძლევთ შექმნათ სტატუსის გვერდები. აქ მოცემულია მაგალითები, თუ როგორ გამოიყურება ეს პროექტის გვერდები Python и Dropbox. okerr სტატუსის გვერდი.

Failover

იმისათვის, რომ ეს სტატია კიდევ არ გაგრძელდეს, კიდევ ერთხელ მივმართავ ჩემს წინა სტატიას - მარტივი მარცხი ვებსაიტისთვის . თუ თქვენ შეგიძლიათ შექმნათ დუბლიკატი სერვერი, შემდეგ მარცხის გამოყენებით, თქვენ ძირითადად არ გექნებათ ხანგრძლივი შეფერხება - როგორც კი პრობლემა გამოვლინდება, მომხმარებლები ავტომატურად გადამისამართდებიან სამუშაო სარეზერვო სერვერზე. და მეჩვენება, რომ ეს არის ძალიან საინტერესო, ნათელი ფუნქცია, რომელიც იშვიათად არის ხელმისაწვდომი სადმე.

დაბალი სისტემური მოთხოვნები

okerr სერვერებისთვის ჩვენ ვიყენებთ მანქანებს RAM-ით 2 გბ-დან. ქსელის სენსორებისთვის 512 მბაც კი საკმარისია. კლიენტის ნაწილი ზოგადად თითქმის ნულის ტოლია. (პლასტმასის ჩანთა okerrupdate იწონის 26 კბ, მაგრამ მოითხოვს Python3 და სტანდარტულ ბიბლიოთეკებს). კლიენტი მუშაობს cron სკრიპტიდან, ამიტომ მას აქვს ნულოვანი მუდმივი მეხსიერების მოხმარება. ჩვენ მიერ მონიტორინგებულ მანქანებს შორის გვაქვს სენსორები (სუპერ იაფი VPS 512 მბ ოპერატიული მეხსიერებით) და Raspberry Pi. ეს შესაძლებელია კლიენტის ნაწილის გარეშეც განახლებების გაგზავნა curl-ის საშუალებით! (იხილეთ ქვემოთ)

ამის გათვალისწინებით - ოკერრ, ალბათ ყველაზე თავისუფალი მონიტორინგის სისტემა ხელმისაწვდომიდან, რადგან თუნდაც სხვა უფასო ღია კოდის სისტემის გამოსაყენებლად, როგორიცაა Zabbix ან Nagios, თქვენ უნდა გამოყოთ მასზე რესურსები (სერვერი) და ეს უკვე ფულია. გარდა ამისა, გარკვეული სერვერის შენარჩუნება ჯერ კიდევ საჭიროა. okerr-ით ამ ნაწილის ამოღება შესაძლებელია. ან არ გჭირდებათ მისი ამოღება და საკუთარი სერვერის გამოყენება, იმისდა მიხედვით, თუ რა მოგწონთ საუკეთესოდ.

API და ინტეგრაცია საკუთრების პროგრამულ უზრუნველყოფაში

მარტივი და ღია არქიტექტურა. okerr-ს აქვს საკმაოდ მარტივი API, რომელთანაც ადვილია მუშაობა. გჭირდებათ 1000 ინდიკატორის შექმნა? ამას გააკეთებს ერთი სკრიპტი 3-4 ხაზისგან. გჭირდებათ 1000 ინდიკატორის ხელახლა კონფიგურაცია? ასევე ძალიან ადვილია. მაგალითად, ჩვენ გვინდა ორჯერ გადავამოწმოთ ყველა ჩვენი HTTPS სერთიფიკატი რუსული სენსორიდან:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

თქვენ შეგიძლიათ განაახლოთ ინდიკატორი ჩვენი კლიენტის მოდულის გამოყენებით, მის გარეშეც, მხოლოდ curl-ის საშუალებით.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

თქვენ შეგიძლიათ განაახლოთ ინდიკატორები პირდაპირ თქვენი პროგრამიდან. მაგალითად, გულისცემის სიგნალების გაგზავნა, რათა okerr-მა იცოდეს, რომ ის მუშაობს და აღვიძებს განგაშის, თუ ის ავარია ან გაიყინება. სხვათა შორის, okerr კომპონენტები სწორედ ამას აკეთებენ - okerr აკონტროლებს საკუთარ თავს და თითქმის ნებისმიერ მოდულში არსებული პრობლემები გამოვლინდება და წარმოქმნის გაფრთხილებას პრობლემის შესახებ. (და ამ "თითქმის" შემთხვევაში - ისინი გადამოწმებულია სხვა სერვერიდან)

აქ არის კოდი (გამარტივებული) ჩვენს ტელეგრამის ბოტში:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

არსებობს ბიბლიოთეკა პითონის პროგრამებიდან ინდიკატორების განახლებისთვის okerrupdate, ნებისმიერი სხვა ენისთვის არ არის ბიბლიოთეკა, მაგრამ შეგიძლიათ დარეკოთ okerrupdate სკრიპტი ან გააკეთოთ HTTP მოთხოვნა okerr სერვერზე.

როგორ გვეხმარება okerr

ოკერმა შეცვალა ჩვენი ცხოვრება. Ნამდვილად. შესაძლოა, სხვა მონიტორინგის სისტემამ იგივე გააკეთოს, მაგრამ okerr-თან მუშაობა ჩვენთვის მარტივი და მარტივია და მას აქვს ყველა ის ფუნქცია, რაც ჩვენ გვჭირდებოდა (დავამატეთ რაც არ ჰქონდა). სხვათა შორის, თუ რაიმე ფუნქცია აკლია, იკითხე და დავამატებ (არ გპირდები, მაგრამ მინდა, რომ okerr იყოს საუკეთესო მონიტორინგის სისტემა მცირე და საშუალო პროექტებისთვის). ან კიდევ უკეთესი, დაამატე თავად - ეს მარტივია.

ჩვენ მოვახერხეთ ცხოვრება პრინციპით "ვისწავლოთ ყველა პრობლემის შესახებ კერადან". თუ მოულოდნელად წარმოიქმნება პრობლემა, რომლის შესახებაც ჩვენ არ ვისწავლეთ okerr-ისგან, ჩვენ ვამატებთ ჩეკს okerr-ს. (ამ შემთხვევაში „ჩვენ“-ში ვგულისხმობ ჩვენ, როგორც სისტემის მომხმარებლებს და არა თანადეველოპერებს). თავიდან ეს ჩვეულებრივი იყო, მაგრამ ახლა ძალიან იშვიათი გახდა.

მონიტორინგი

okerr-ის საშუალებით ჩვენ ვაკვირდებით ჟურნალის ზომებს ყველა სერვერზე. რა თქმა უნდა, შეუძლებელია ჟურნალის ყველა სტრიქონის გააზრებულად წაკითხვა თვალით, მაგრამ უბრალოდ ზრდის ტემპის მონიტორინგი უკვე ბევრს იძლევა. ამის მეშვეობით ჩვენ აღმოვაჩინეთ სპამის გაგზავნა და უხეში ძალისმიერი პაროლის ძიება, და როდესაც ზოგიერთი აპლიკაცია „გიჟდება“, მათ რაღაც არ გამოსდის და ისინი ამას ისევ და ისევ იმეორებენ (ყოველ ჯერზე ამატებენ რამდენიმე სტრიქონს ჟურნალში. ).

SSL სერთიფიკატები. გაშვებისთანავე თითქმის მაშინვე LetsEncrypt ჩვენმა მომხმარებელმა დაიწყო უფასო SSL სერთიფიკატების მიწოდება თავისი კლიენტებისთვის (დაახლოებით ათასი მათგანი). და ეს მხოლოდ ჯოჯოხეთი აღმოჩნდა ადმინისტრაციისთვის! ფაქტია, რომ საიტები "ცოცხალია", კლიენტები პერიოდულად სთხოვენ მათ რაიმეს გაკეთებას, პროგრამისტები აკეთებენ ამას. მათ შეუძლიათ სრულიად თავისუფლად გადაიტანონ საიტი სხვა DocumentRoot-ზე, მაგალითად. ან დაამატეთ უპირობო გადაწერა ვირტუალური მასპინძლის კონფიგურაციაში. ბუნებრივია, ამის შემდეგ ფუჭდება სერტიფიკატების ავტომატური განახლება. ახლა ჩვენ გვაქვს ყველა SSL ჰოსტი დაემატა okerr-ს ავტომატურად, ჩვენი სხვა სასარგებლო უტილიტის მეშვეობით პაკეტიდან a2conf. მოდით უბრალოდ დავიწყოთ a2okerr.py — და თუ რამდენიმე ახალი საიტი გამოჩნდება სერვერზე, ისინი ავტომატურად გამოჩნდება okerr-ში. თუ მოულოდნელად რაიმე მიზეზით სერთიფიკატი არ განახლდება, სერთიფიკატის ვადის გასვლამდე სამი კვირით ადრე, ჩვენ ვიცით და გავარკვევთ, რატომ არ არის განახლებული, ასეთი ძაღლი. a2certbot.py იგივე პაკეტიდან - ეს ძალიან ეხმარება ამაში (ის მაშინვე ამოწმებს ყველაზე სავარაუდო პრობლემებს - და კარგად წერს რა იყო შემოწმებული და სად არის დიდი ალბათობით პრობლემა).

ჩვენ ვაკვირდებით ყველა ჩვენი დომენის ვადის გასვლის თარიღს. და ყველა ჩვენი ფოსტის სერვერი, რომელიც აგზავნის ფოსტას, ასევე შემოწმებულია 50+ სხვადასხვა შავ სიებში. (და ხანდახან მათში ვარდებიან). სხვათა შორის, იცოდით, რომ Google mail სერვერებიც შავ სიაშია? მხოლოდ თვითშემოწმებისთვის, ჩვენ დავამატეთ mail-wr1-f54.google.com მონიტორინგის სერვერებს და ის კვლავ SORBS-ის შავ სიაშია! (ეს ეხება "ანტი-სპამერების" ღირებულებას)

სარეზერვო ასლები - ზემოთ უკვე დავწერე, რამდენად ადვილია მათი მონიტორინგი okerr-ით. მაგრამ ჩვენ ვაკვირდებით როგორც უახლეს სარეზერვო ასლებს ჩვენს სერვერზე, ასევე (ცალკე უტილიტის გამოყენებით, რომელიც იყენებს okerr) სარეზერვო ასლებს, რომლებსაც ვატვირთავთ Amazon Glacier-ზე. დიახ, პრობლემები დროდადრო ხდება. გასაკვირი არ არის, რომ ისინი უყურებდნენ.

ჩვენ ვიყენებთ ესკალაციის ინდიკატორს. ეს გვიჩვენებს, თუ რაიმე პრობლემა დიდი ხნის განმავლობაში არ მოგვარებულა. მე კი, როცა რაღაც პრობლემას ვაგვარებ, ხანდახან შემიძლია მათი დავიწყება. ესკალაცია კარგი შეხსენებაა, მაშინაც კი, თუ საკუთარ თავს აკონტროლებთ.

მთლიანობაში, მე მჯერა, რომ ჩვენი მუშაობის ხარისხი მასშტაბური რიგით გაიზარდა. შეფერხების დრო თითქმის არ არის (ან კლიენტს არ აქვს ამის შენიშვნის დრო. უბრალოდ შშ!), ხოლო სამუშაოს მოცულობა შემცირდა და სამუშაო პირობები უფრო მშვიდი გახდა. გადაუდებელი სამუშაოებიდან გადავედით ლენტით ხვრელების გაკეთებით მშვიდ და გაზომილ სამუშაოზე, როცა ბევრი პრობლემა წინასწარ არის ნაწინასწარმეტყველები და დროა მათი თავიდან აცილება. მომხდარი პრობლემებიც კი უფრო ადვილი მოსაგვარებელი გახდა: ჯერ ერთი, მათ შესახებ ვიგებთ, სანამ კლიენტები პანიკაში ჩავარდებიან და მეორეც, ხშირად ხდება, რომ პრობლემა დაკავშირებულია ბოლო სამუშაოსთან (როცა ერთს ვაკეთებდი, მეორეს გავტეხე) - ასე რომ, ცხელა, კვალი უფრო ადვილია მასთან გამკლავება.

მაგრამ იყო სხვა შემთხვევაც...

იცოდით, რომ პოპულარულ Debian 9-ში (Stretch) ისეთი პოპულარული პაკეტი, როგორიცაა phpmyadmin, ჯერ კიდევ (მრავალი თვის განმავლობაში!) დაუცველ მდგომარეობაშია? (CVE-2019-6798). როდესაც დაუცველობა გამოჩნდა, ჩვენ სწრაფად დავფარეთ იგი სხვადასხვა გზით. მაგრამ მე დავაყენე უსაფრთხოების ტრეკერის გვერდის მონიტორინგი okerr-ში, რათა ვიცოდე, როდის გამოვა „ლამაზი“ გამოსავალი (შინაარსის SHA1 ჯამის მეშვეობით). ინდიკატორმა რამდენჯერმე დამიკრა, გვერდი შეიცვალა, მაგრამ როგორც ხედავთ, მაინც (2019 წლის იანვრიდან!) არ მიუთითებს, რომ პრობლემა მოგვარებულია. იქნებ, სხვათა შორის, ვინმემ იცის, რა პრობლემაა, რომ ასეთი მნიშვნელოვანი პაკეტი წელიწადზე მეტია ისევ დაუცველია?

სხვა დროს მსგავს სიტუაციაში: SSH-ში დაუცველობის შემდეგ, საჭირო გახდა ყველა სერვერის განახლება. და როდესაც დასახავთ ამოცანას, თქვენ უნდა აკონტროლოთ შესრულება. (დაქვემდებარებულები არასწორად იგებენ, ივიწყებენ, იბნევიან და უშვებენ შეცდომებს). ამიტომ, ჯერ დავამატეთ SSH ვერსიის შემოწმება okerr-ზე ყველა სერვერზე და okerr-ის მეშვეობით დავრწმუნდით, რომ განახლებები გავრცელდა ყველა სერვერზე. (მოხერხებული! მე ავირჩიე ამ ტიპის ინდიკატორი და თქვენ მაშინვე შეგიძლიათ ნახოთ რომელ სერვერს რომელი ვერსია აქვს). როდესაც დავრწმუნდით, რომ დავალება დასრულებულია ყველა სერვერზე, ჩვენ ამოვიღეთ ინდიკატორები.

რამდენჯერმე იყო სიტუაცია, როდესაც გარკვეული პრობლემა ჩნდება, შემდეგ კი თავისით გადის. (ალბათ ყველასთვის ნაცნობი?). სანამ შეამჩნევთ, სანამ შეამოწმებთ - და შესამოწმებელი არაფერია - ყველაფერი უკვე კარგად მუშაობს. მაგრამ შემდეგ ისევ იშლება. ჩვენ ეს მოხდა, მაგალითად, პროდუქტებით, რომლებიც ავტვირთეთ Amazon Marketplace-ში (MWS). რაღაც მომენტში, დატვირთული ინვენტარი იყო არასწორი (საქონლის არასწორი რაოდენობა და არასწორი ფასები). ჩვენ გავარკვიეთ. მაგრამ ამის გასარკვევად, მნიშვნელოვანი იყო პრობლემის შესახებ დაუყოვნებლივ გაერკვია. სამწუხაროდ, MWS, ისევე როგორც ამაზონის ყველა სერვისი, ცოტათი ნელია, ამიტომ ყოველთვის იყო ჩამორჩენა, მაგრამ მაინც, ჩვენ შევძელით უხეშად მაინც გაგვეგო კავშირი პრობლემასა და მის გამომწვევ სკრიპტებს შორის (ჩვენ შევამოწმეთ, დავრჩით ის ოკერს, და შეამოწმა იგი დაუყოვნებლივ მიიღო გაფრთხილება).

კოლექციას ცოტა ხნის წინ საინტერესო შემთხვევა დაემატა დიდმა და ძვირადღირებულმა ევროპულმა ჰოსტერმა, რომელსაც ჩვენი მომხმარებელი იყენებს. უეცრად, ყველა ჩვენი სერვერი გაქრა რადარიდან! ჯერ თავად მომხმარებელმა შეამჩნია, რომ საიტი, რომელზეც მუშაობდა, არ იხსნება და ამის შესახებ ბილეთი გააკეთა. მაგრამ არა მხოლოდ ერთი საიტი დაიშალა, არამედ ყველა! (ნატაშა, ჩვენ ყველაფერი დავკარგეთ!). აქ ოკერმა დაიწყო გრძელი ფეხის სახვევების გაგზავნა ყველა იმ ინდიკატორით, რომელიც მას ანათებდა. პანიკა, პანიკა, წრეებში დავრბივართ (სხვა რა ვქნათ?). მერე ყველაფერი ამაღლდა. გამოდის, რომ დატა-ცენტრში რუტინული მოვლა იყო (ბევრ წელიწადში ერთხელ) და, რა თქმა უნდა, უნდა გაგვეფრთხილებინა. მაგრამ რაღაც პრობლემა შეექმნა მათ და არ გაგვაფრთხილეს. ისე, მეტი გულის შეტევა, ნაკლები ინფარქტი. მაგრამ ყველაფრის აღდგენის შემდეგ, თქვენ უნდა გადაამოწმოთ ყველაფერი! ვერ წარმომიდგენია, როგორ გავაკეთებდი ამას ჩემი ხელით. ოკერმა ყველაფერი რამდენიმე წუთში გამოსცადა. აღმოჩნდა, რომ სერვერების უმეტესობა უბრალოდ დროებით მიუწვდომელი იყო, მაგრამ ისინი მუშაობდნენ. ზოგი გადატვირთული იყო, მაგრამ ისე ადგა, როგორც უნდა. ყველა დანაკარგიდან ჩვენ დავკარგეთ ორი სარეზერვო საშუალება, რომელიც გვირგვინის მიხედვით უნდა შექმნილიყო და დატვირთულიყო ამ სავსე ბანანის მიმდინარეობისას. მე არც კი შევწუხდი მათი შექმნა, მხოლოდ ერთი დღის შემდეგ მოვიდა სიგნალიზაცია, რომ ყველაფერი წესრიგში იყო, სარეზერვო ასლები გამოჩნდა. მე ძალიან მომწონს ეს მაგალითი, რადგან okerr ძალიან გამოსადეგი აღმოჩნდა ისეთ სიტუაციაში, რაზეც წინასწარ არც კი გვიფიქრია, მაგრამ მონიტორინგის მიზანიც სწორედ ეს არის - წინააღმდეგობის გაწევა არაპროგნოზირებადს.

Okerr სენსორებისთვის ჩვენ ვიყენებთ ყველაზე იაფ შესაძლო ჰოსტინგს (სადაც ხარისხი და საიმედოობა არ არის მნიშვნელოვანი, ისინი აზღვევენ ერთმანეთს). ასე რომ, ჩვენ ახლახან ვიპოვეთ ძალიან კარგი ჰოსტინგი და სუპერ იაფი, კრიტერიუმები გასაოცარია. მაგრამ... ხანდახან გამოდის, რომ ვირტუალური აპარატიდან გამავალი კავშირები სხვა (მეზობელი) IP-დან ხდება. სასწაულები. Client_ip მოდულით https://diagnostic.opendns.com/myip იღებს არასწორ IP-ს. და ინდიკატორის სერვერის ჟურნალებიდან ირკვევა, რომ განახლება ასევე მოვიდა ამ მეზობელი IP-დან. მოდით, ახლავე გავუმკლავდეთ მხარდაჭერას. კარგია, რომ ეს მშვიდობის დროს შევნიშნეთ. მაგრამ, მაგალითად, ხშირად ხდება, რომ წვდომა რეგისტრირებულია IP თეთრი სიის მიხედვით - და თუ სერვერი ხანდახან ასე ციმციმებს მოკლე დროში - შეგიძლიათ სცადოთ ამ პრობლემის დაჭერა ძალიან დიდი ხნის განმავლობაში.

კიდევ ერთი რამ – რადგან ვსაუბრობთ VPS ჰოსტინგზე – ჩვენ ყოველთვის ვიყენებთ იაფებს (hetzner, ovh, scaleway). ძალიან მომწონს როგორც ეტალონების, ასევე სტაბილურობის თვალსაზრისით. ჩვენ ასევე ვიყენებთ ბევრად უფრო ძვირადღირებულ Amazon EC2-ს სხვა პროექტებისთვის. ასე რომ, okerr-ის წყალობით, ჩვენ გვაქვს საკუთარი ინფორმირებული აზრი. ორივე ეცემა. და მე არ ვიტყოდი, რომ ჩვენი დაკვირვების ხანგრძლივი პერიოდის განმავლობაში, იაფი ჰოსტინგი, როგორიცაა ჰეცნერი, შესამჩნევად ნაკლებად სტაბილური აღმოჩნდა, ვიდრე EC2. ამიტომ, თუ არ ხართ მიბმული ამაზონის სხვა ფუნქციებთან, რატომ გადაიხადოთ მეტი? 🙂

რა არის შემდეგი?

თუ ამ ეტაპზე ოკერისგან ჯერ არ შეგაშინეთ, მაშინ სცადეთ! შეგიძლიათ პირდაპირ გადახვიდეთ ამ ბმულზე okerr დემო ანგარიში (დააწკაპუნეთ ახლავე!) მაგრამ გაითვალისწინეთ, რომ არსებობს მხოლოდ ერთი დემო ანგარიში ყველასთვის, ასე რომ, თუ რაიმეს გააკეთებთ, იმავე ანგარიშში სხვამ შეიძლება ხელი შეგიშალოთ ერთდროულად. ან (უკეთესი) დარეგისტრირდით ბმულით offsite okerr - ყველაფერი მარტივია, SMS-ის გარეშე. თუ არ მოგწონთ თქვენი რეალური ელ. ფოსტის გამოყენება, შეგიძლიათ გამოიყენოთ ერთჯერადი, მაგალითად, მეილინატორი (მე გირჩევთ getnada.com). ასეთი ანგარიშები შეიძლება წაიშალოს დროთა განმავლობაში, მაგრამ ისინი კარგი იქნება ტესტირებისთვის.

რეგისტრაციის შემდეგ მოგეთხოვებათ ტრენინგის გავლა (შეასრულეთ რამდენიმე არც თუ ისე რთული სასწავლო დავალება). საწყისი ლიმიტები ძალიან მცირეა, მაგრამ ტრენინგისთვის ან ერთი სერვერისთვის ისინი საკმარისია. ტრენინგის დასრულების შემდეგ გაიზრდება ლიმიტები (მაგალითად, ინდიკატორების მაქსიმალური რაოდენობა).

დოკუმენტაციიდან - პირველ რიგში WIKI სერვერის მხარეს და კლიენტზე (okerrupdate ვიკი). მაგრამ თუ რამე გაუგებარია, დაწერეთ მხარდაჭერა (at) okerr.com-ზე ან დატოვეთ ბილეთი - ჩვენ შევეცდებით სწრაფად მოვაგვაროთ ყველაფერი.

თუ მას სერიოზულად იყენებთ და ეს გაზრდილი ლიმიტები საკმარისი არ არის, მოგვწერეთ მხარდაჭერა და ჩვენ გავზრდით (უფასოდ).

გსურთ დააინსტალიროთ okerr სერვერი თქვენს სერვერზე? Აქ okerr-dev საცავი. ჩვენ გირჩევთ დააინსტალიროთ სუფთა ვირტუალურ მანქანაზე, შემდეგ შეგიძლიათ ამის გაკეთება უბრალოდ ინსტალაციის სკრიპტით. თქვენს ვირტუალურ მანქანაზე - არანაირი შეზღუდვა :-). კიდევ ერთხელ, თუ რამე მოხდება, ჩვენ ყოველთვის ვეცდებით დაგეხმაროთ.

ჩვენ გვინდა, რომ ეს პროექტი ამოქმედდეს, რათა სამყარო ჩვენი წყალობით გახდეს უფრო საიმედო. უფასო პროგრამული უზრუნველყოფისა და სერვისების წყალობით, სამყარო უფრო მეგობრული გახდა და უფრო დინამიურად ვითარდება. წყაროების შენახვა შესაძლებელია უფასო github-ში, ფოსტისთვის შეგიძლიათ გამოიყენოთ უფასო gmail. ჩვენ ვიყენებთ უფასოდ მტკნარი ქსელები მხარდაჭერისთვის. ნებისმიერი მათგანისთვის, თქვენ არ გჭირდებათ სერვერების გადახდა, არ გჭირდებათ ჩამოტვირთვა და კონფიგურაცია და არ გჭირდებათ სხვადასხვა ოპერაციული პრობლემების გადაჭრა. ყოველ ახალ პროექტს, ყველა გუნდს დაუყოვნებლივ აქვს ფოსტა, საცავი და CRM. და ეს ყველაფერი არის ძალიან ხარისხიანი და უფასო და დაუყოვნებლივ. ჩვენ გვინდა, რომ იგივე იყოს მონიტორინგისთვის - მცირე კომპანიებსა და პროექტებს შეუძლიათ გამოიყენონ okerr უფასოდ და დაბადების და ზრდის ეტაპზეც კი ჰქონდეს ზრდასრულთა სერიოზული პროექტების სანდოობა.

წყარო: www.habr.com