XNUMX년전에 이미 포스팅을 했었는데 웹 사이트에 대한 간단한 장애 조치 약 오케르. 이제 프로젝트가 어느 정도 발전하고 있으며, 저는 또한 출판했습니다. okrr 서버 측 소스 코드 아래의 오픈 라이센스, 그래서 Habr에 대한 짧은 리뷰를 쓰기로 결정했습니다.

[ 풀 사이즈 ]

누구에게 관심을 가질 수 있습니까?

소규모 팀에서 또는 혼자 일하는 경우 이는 귀하에게 흥미로울 수 있습니다. 모니터링 기능이 없고 실제로 필요한지 확실하지 않습니다. "대학생을 위한" 인기 있는 진지한 모니터링을 시도했지만 어떻게든 "성공하지 못했거나" 거의 기본 구성으로 작동하고 인생을 크게 바꾸지 않았습니다. 또한 전체 직원(또는 부서)을 할당하여 하루에 최소 두 시간 이상 모니터링 대시보드를 모니터링하거나 구성할 계획이 없는 경우에도 마찬가지입니다.

okrr이 특이한 이유

다음으로 다른 모니터링 시스템과 구별되는 okerra의 흥미로운 기능을 보여 드리겠습니다.

Okerr는 하이브리드 모니터링입니다

내부 모니터링 중에는 모니터링 서버에 데이터(예: 여유 디스크 공간)를 전송하는 "에이전트"가 모니터링되는 컴퓨터에서 실행됩니다. 외부인 경우 서버는 네트워크를 통해 검사를 수행합니다(예: 핑 또는 웹 사이트 가용성). 각 접근 방식에는 한계가 있습니다. Okerr는 두 가지 옵션을 모두 사용합니다. 서버 내부 점검은 초경량(30Kb) 에이전트나 자체 스크립트 및 애플리케이션으로 수행되며, 네트워크 점검은 각국의 okerr 센서를 통해 수행됩니다.

okrr은 소프트웨어일 뿐만 아니라 서비스이기도 합니다.

모든 모니터링의 서버 부분은 규모가 크고 복잡하며 설치 및 구성이 어렵고 리소스가 필요합니다. okrr을 사용하면 자체 모니터링 서버(무료, 오픈 소스)를 설치할 수도 있고, 클라이언트 부분만 사용하고 서버 서비스를 사용할 수도 있습니다. 또한 무료입니다.

모니터링을 통해 서버와 애플리케이션의 신뢰성 부족을 보완하고 은폐할 수 있다면 철학적인 질문이 발생합니다. 즉, 경비원은 누구입니까? 문제가 어떤 이유로든 별도로 또는 다른 리소스와 함께 "죽은" 경우(예: 데이터 센터 채널이 중단된 경우) 모니터링을 통해 문제에 대해 어떻게 알 수 있습니까? 외부 서비스 okrr을 사용하면 이 문제가 해결됩니다. 서버가 있는 전체 데이터 센터에 전원이 들어오지 않거나 좀비의 공격을 받는 경우에도 경고를 받게 됩니다.

물론 oker 서버 자체를 사용할 수 없게 될 위험이 있습니다. 이는 사실입니다(아시다시피 안정성의 90%는 항상 간단하게 "무료"로 얻을 수 있으며, 99%는 최소한의 노력으로 얻을 수 있으며 이후 99.9개는 모두 기하급수적으로 더 어려워졌습니다.) 그러나 첫째, 이런 일이 발생할 가능성은 낮고 둘째, 서버의 문제와 일치하는 경우에만 문제가 눈에 띄지 않을 수 있습니다. 99.9%의 신뢰도가 있고 0.1%(너무 높지 않은 숫자)인 경우 감지되지 않은 오류가 발생할 확률은 0.1%/0.0001% = XNUMX%입니다. 거의 노력이나 비용 없이 XNUMX개의 XNUMX를 신뢰성에 추가하는 것은 매우 좋습니다!

서비스형 모니터링의 또 다른 장점은 호스팅 제공업체나 웹 스튜디오가 okrr 서버를 설치하고 유료 또는 무료 추가 서비스로 클라이언트에 대한 액세스를 제공할 수 있다는 것입니다. 경쟁업체에는 호스팅과 웹사이트만 있지만 귀사는 모니터링 기능을 갖춘 안정적인 호스팅을 보유하고 있습니다.

Okerr는 지표에 관한 것입니다.

표시기는 "전구"입니다. 녹색(OK) 또는 빨간색(ERR)의 두 가지 주요 상태가 있습니다. 프로젝트에는 여러 그룹화된(예: 서버별) 표시기가 포함되어 있습니다. 프로젝트의 메인 페이지에서 모든 것이 녹색으로 표시되거나(닫을 수 있음) 빨간색으로 켜져 수정이 필요한 항목이 즉시 표시됩니다. 이러한 상태 사이를 전환할 때 경고가 전송됩니다. 하루에 한 번 설정하는 동안 프로젝트 요약이 전송됩니다.

각 okrr 표시기에는 상태를 변경하는 조건이 내장되어 있습니다(Zabbix에서는 이를 트리거라고 합니다). 예를 들어 로드 평균은 2 이하여야 합니다(물론 구성 가능). 그리고 각 내부 검사(로드 평균, 디스크 없음 등)에 대해 감시 장치가 있습니다. 어떤 이유로든 약속된 시간에 성공적인 확인을 받지 못한 경우 오류가 기록되고 경고가 전송됩니다.

우리의 일반적인 업무 패턴은 아침에 이메일을 확인하고, 다른 편지들 중에서 요약을 보는 것입니다(일을 시작할 때 일정을 잡습니다). 모든 것이 정상이면 다른 중요한 작업을 수행합니다(그러나 안전을 위해 okerra 대시보드를 빠르게 살펴보고 현재 모든 것이 녹색인지 확인할 수 있습니다). 경고가 도착하면 우리는 대응합니다.

물론 단순히 "정보" 표시기를 유지하는 것도 가능하지만(모니터링에서 네트워크 그림을 보기 위해) 자동 모니터링 및 경고 전송을 위한 표시기를 간단하고 쉽고 빠르게 생성하기 위해 모든 작업이 수행됩니다.

okrr을 설정하는 목적은 경고에 있으므로 XNUMX분 안에 표시기를 만들 수 있고 XNUMX년 동안 "잠자기"할 수 있으며 업데이트를 수락할 수 있으며 XNUMX년 후 문제가 발생하면 켜지고 전송됩니다. 경고. 지표를 만드는 데 XNUMX분을 투자한 순간부터 다른 사람보다 먼저 문제에 대해 즉시 알게 되었습니다. 누군가가 알아차리기 전에 문제를 고쳤을 수도 있습니다. 빨리 일어난 것은 떨어진 것으로 간주되지 않습니다!

Безопасность

신뢰성을 높이기 위해 모니터링을 설정한다면 안타까운 일이겠지만, 결과적으로 이를 통해 네트워크를 통해 공격을 받게 되고, 각종 모니터링 도구에도 네트워크 취약점이 꽤 많이 존재합니다(자 비츠, 나기 오스).

에이전트(패키지의 okerrmod 확인 업데이트) 시스템에서 실행되는 것은 네트워크 서버가 아니라 클라이언트입니다. 따라서 모니터링되는 서버에는 추가로 열려 있는 포트가 없으며 클라이언트는 방화벽이나 NAT 뒤에서 쉽게 작동하며 원칙적으로 네트워크를 수신하지 않기 때문에 네트워크를 통해 해킹하기가 매우 어렵습니다("불가능"이라고 말합니다). 소켓.

전체 모니터링 범위

이제 우리의 규칙은 okrr로부터 모든 기술적 문제에 대해 배우는 것입니다. 갑자기 규칙을 위반한 경우(okerr은 발생이 임박했거나(가능한 경우) 이미 발생했음을 경고하지 않았습니다), okrr에 검사를 추가합니다.

외부 점검

매우 일반적인 세트:

• 핑
• http 상태
• SSL 인증서의 유효성과 최신성을 확인합니다(만료가 임박하면 경고합니다).
• TCP 포트와 배너를 엽니다.
• http grep(페이지에 특정 텍스트가 포함되어서는 안 됨)
• sha1 해시를 사용하여 페이지 변경 사항을 포착합니다.
• DNS(DNS 레코드에는 특정 값이 있어야 함)
• WHOIS(도메인이 곧 손상될 경우 경고합니다)
• 안티스팸 DNSBL(50개 이상의 안티스팸 블랙리스트에 대해 호스트를 동시에 확인)

내부 점검

또한 상당히 표준적인 세트입니다(그러나 쉽게 확장 가능).

• df (여유 디스크 공간)
• 부하 평균
• opentcp(TCP 청취 소켓 열기 - 무언가가 시작되거나 충돌하면 알림)
• 가동 시간 - 서버의 가동 시간입니다. 변경된 경우 알림을 보냅니다(예: 서버가 과부하됨).
• 클라이언트_IP
• dirsize - 엄격한 제한을 적용하지 않고 가상 머신 rootfs가 허용된 크기를 초과하는 경우와 사용자 홈 디렉터리의 크기를 추적하는 데 사용합니다.
• 비어 있음 및 비어 있지 않음 - 비어 있어야 하는(또는 비어 있지 않아야 하는) 파일을 모니터링합니다. 예를 들어 okrr 서버 자체의 오류 로그는 비어 있어야 하며, 그 안에 한 줄이라도 있으면 알림을 받아서 확인하게 됩니다. 그러나 메일 서버의 mail.log는 비어 있으면 안 됩니다(교체 후 N분). 때로는 시스템 업데이트 후 logrotate가 rsyslog를 올바르게 다시 시작할 수 없을 때 비어 있었습니다.
• linecount - 파일의 줄 수(예: wc -l) 오류 로그가 계속 커질 수 있지만 속도가 느린 경우(예: Googlebot이 일부 닫힌 페이지에 도달하는 경우) 비어 있음을 보다 부드럽게 대체하는 방법으로 사용합니다. 2분당 20줄 제한이 있습니다. 더 높으면 경고가 표시됩니다.

흥미로운 내부 점검

지금까지 '대각선'으로 읽었다면 이제 좀 더 주의 깊게 읽는 것이 더 재미있을 것입니다.

백업

디렉터리의 백업을 모니터링합니다. 백업 파일의 이름은 "ServerName-20200530.tar.gz"와 같습니다. okrr의 각 서버에 대해 표시기 ServerName-DATE.tar.gz가 생성됩니다(실제 날짜는 "DATE" 행으로 변경됩니다). 새로운 백업의 존재 여부와 크기도 모니터링됩니다(예: 이전 백업의 90% 미만일 수 없음).

새 백업을 생성하여 이 디렉터리에 저장한 후 추적을 시작하려면 어떻게 해야 합니까? 아무것도 아님! 이는 다음과 같은 이유로 "아무 것도" 하지 않을 때 매우 편리한 접근 방식입니다.

• "아무것도 하지 않는 것"은 꽤 빠르며 시간을 절약해 줍니다.
• '아무것도 하지 않는 것'을 잊는 것은 어렵다
• 오류로 인해 "아무것도 잘못"하지 않는 것은 어렵습니다. 가장 확실한 방법은 없습니다

갑자기 새로운 백업 파일이 표시되지 않으면 경고가 표시됩니다. 예를 들어, 서버 중 하나를 비활성화했고 더 이상 백업이 없어야 하는 경우 표시기를 삭제해야 합니다(웹 인터페이스를 통해 또는 API를 통해 셸에서).

maxfilesz

가장 큰 파일의 크기를 추적합니다(일반적으로: /var/log/*). 이를 통해 무차별 암호 대입이나 서버를 통한 스팸 전송과 같은 예측할 수 없는 문제를 포착할 수 있습니다.

실행 상태/실행 라인

이는 서버에서 다른 프로그램을 실행하기 위한 두 가지 중요한 프록시 모듈입니다. Runstatus는 프로그램 종료 코드를 표시기에 보고합니다. 예를 들어, okrr은 시스템 서비스가 실행 중인지 확인하는 모듈을 요구하지 않습니다. 이는 runstatus를 통해 수행됩니다(아래 참조). Runline - 프로그램이 생성하는 라인을 서버에 보고합니다. 예를 들어, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" 우리 서버의 Runline 구성에서는 프로세서 온도와 함께 servername:temp 표시기를 생성합니다.

SQL

MySQL에 숫자 쿼리를 실행하고 결과를 표시기에 보고합니다. 간단한 경우에는 예를 들어 "SELECT 1"을 수행할 수 있습니다. 이렇게 하면 DBMS가 전체적으로 작동하는지 확인할 수 있습니다.

그러나 훨씬 더 흥미로운 응용 프로그램은 예를 들어 온라인 상점의 주문 수를 추적하는 것입니다. 시간당 주문이 100개 이상인 것을 알고 있다면 최소 한도를 100개 또는 80개로 설정할 수 있습니다. 그러다 갑자기 매출이 떨어지면 알림을 받고 파악할 수 있습니다.

어떤 예측할 수 없는 이유로 이런 일이 발생했는지는 중요하지 않습니다.

• 서버를 사용할 수 없으며(전원이 끊겼거나 네트워크가 없음) 표시기가 "썩었다"는 사실 때문에 경고가 발생했습니다.
• 서버에 뭔가가 과부하되어 작동이 느리거나 패킷이 손실되어 사용자에게 불편함을 주고 구매도 하지 않고 떠납니다.
• 서버가 스팸 목록에 포함되어 있어 해당 서버에서 보낸 메일이 허용되지 않으며 사용자가 등록할 수 없습니다.
• 광고 캠페인 예산이 소진되어 배너가 회전하지 않습니다.

이유는 다양할 수 있으며 모두 사전에 예측할 수 없고 기술적으로 추적도 어렵습니다. 그러나 최종 매개변수(주문)를 편리하게 모니터링하고 이를 통해 상황이 의심스럽고 처리할 가치가 있는지 판단할 수 있습니다.

논리적 지표

모듈을 통해 부울 표현식(Python 구문)을 사용할 수 있습니다. 검증하다(하브레에 관한 기사). 프로젝트 및 해당 지표의 데이터를 표현에 사용할 수 있습니다. 예를 들어, 위의 SQL 검사에 관한 장에서 약점을 발견했을 수 있습니다. 낮에는 시간당 100개의 판매가 가능하지만 밤에는 20개가 발생하며 이는 일반적이지 문제가 되지 않습니다. 어떻게 해야 하나요? 표시기는 밤에 지속적으로 당황합니다.

낮과 밤의 두 가지 표시기를 만들 수 있습니다. 둘 다 "무음"으로 설정합니다(경보를 보내지 않음). 그리고 20:00 이전에는 주간 표시기가 정상이어야 하고, 20:00 이후에는 야간 표시기가 정상이어야 하는 논리적 표시기를 생성하십시오.

논리적 지표를 사용하는 또 다른 예는 다음과 같습니다. 단계적 확대. 예를 들어, 프로젝트 관리자는 경고 구독을 취소하지만(그는 그렇게 할 필요가 없으며 관리자는 일반적인 문제에 응답해야 함) 프로젝트의 표시기가 할당된 시간 내에 수정되지 않으면 빨간색으로 바뀌는 논리적 표시기를 구독합니다.

또한 출근시간을 새벽 3시부터 5시까지로 설정할 수도 있다. 이 시간 동안 서버와 사이트가 충돌하더라도 우리는 상관하지 않습니다. 하지만 5시에는 일을 해야 해요. 다른 시간에 작동하지 않으면 경고하십시오. 논리적 표시기를 사용하면 서버 중복성을 고려할 수도 있습니다. 웹 서버가 00개 있는 경우 관리자는 언제든지 5~1개의 서버를 끌 수 있습니다. 단, 전투에 참여하는 서버가 2개 중 3개 미만일 경우 경고가 발생합니다.

위의 예는 정상적인 기능이 아니며 활성화 및 구성이 필요한 일부 기능이 아닙니다. Okerra에는 이러한 기능이 모두 포함되어 있지 않지만 이 기능을 구현할 수 있는 논리 모듈이 있습니다. (대략 프로그래밍 언어와 유사합니다. 산술 연산자가 있는 경우 20% VAT를 계산하기 위한 특수 함수가 필요하지 않습니다. 언어에서 언제든지 스스로 할 수 있으며 필요에 맞게 만들 수 있습니다.)

Logic Indicator는 아마도 okrr에서 상대적으로 복잡한 몇 안 되는 주제 중 하나일 것입니다. 그러나 좋은 소식은 필요할 때까지 이를 마스터할 필요가 없다는 것입니다. 그러나 동시에 시스템 자체를 매우 단순하게 유지하면서 기능을 크게 확장합니다.

자신만의 수표 추가하기

나는 oker가 모든 경우에 대해 수천 개의 미리 만들어진 수표 세트가 아니라 무엇보다도 자신만의 수표를 만들 수 있는 간단한 기능을 갖춘 간단한 엔진이라는 아이디어를 전달하고 싶습니다. okerr에서 자신만의 검사를 만드는 것은 해커, 시스템 공동 개발자 또는 최소한 고급 okerr 사용자의 작업이 아니지만 한 달 전에 처음으로 Linux를 설치한 모든 관리자에게는 실행 가능한 작업입니다.

최저임금 확인은 모듈을 통해 이루어집니다. 실행 상태:

구성의 이 줄 실행 상태 /bin/true가 갑자기 시작되지 않거나 0이 아닌 값을 반환하면 알려줍니다.

true_OK=/bin/true

단 한 줄 - 그리고 여기에 우리는 이미 조금 있습니다 확장했다 기능 확인.

그러한 검사에도 이미 그만한 가치가 있습니다. 갑자기 서버가 충돌하면 okrr 서버의 해당 표시기가 적시에 업데이트되지 않으며 시간이 지나면 경고가 나타납니다.

이 검사는 apache2 서버가 충돌했음을 알려줍니다(글쎄, 당신은 결코 알지 못합니다...):

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

따라서 프로그래밍 언어를 구사하고 최소한 쉘 스크립트를 작성할 수 있다면 이미 자체 검사를 추가할 수 있습니다.

더 어렵습니다. 어떤 언어로든 okrrmod용 모듈을 직접 작성할 수 있습니다. 가장 간단한 경우에는 다음과 같습니다.

#!/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

여러 지표를 한 번에 업데이트하고(빈 줄로 구분) 필요한 경우 생성하며 확인 세부 정보와 대시보드에서 필요한 지표를 쉽게 찾을 수 있는 태그를 표시합니다.

텔레그램

텔레그램 봇이 있습니다 @OkerrBot. 별도의 애플리케이션으로 휴대폰을 복잡하게 만들 필요가 없습니다. (Pyaterochka의 경우 지도가 있는 하나의 애플리케이션, Lenta의 경우 다른 애플리케이션, MTS의 경우 세 번째 등 모든 사람을 위해 필요한 애플리케이션이 마음에 들지 않습니다.) 전보는 하나면 충분합니다. 텔레그램을 통해 즉시 알림을 받고, 프로젝트 상태를 확인하고, 문제가 있는 모든 지표를 다시 확인하라는 명령을 내릴 수 있습니다. 우리는 극장/비행기를 떠나 두 시간 동안 맥박을 확인하지 않고 전화기를 켜고 챗봇의 버튼 하나를 누르고 모든 것이 괜찮은지 확인했습니다.

상태 페이지

오늘날 상태 페이지는 IT, 신뢰성에 대한 책임감 있는 태도, 고객/사용자를 존중하는 태도를 갖춘 모든 비즈니스에 거의 필수 요소입니다.

상황을 상상해 보세요. 사용자가 무언가를 하고 싶고, 정보를 보거나 주문하고 싶어하는데 무언가가 작동하지 않는 경우입니다. 그는 무슨 일이 일어나고 있는지, 문제가 누구 편에 있는지, 언제 해결될지 모릅니다. 어쩌면 귀하의 회사가 단순히 기능하지 않는 웹사이트를 갖고 있는 것은 아닐까요? 아니면 XNUMX개월 전에 고장이 났고 XNUMX년 안에 고쳐질까요? 하지만 지금 냉장고를 사야하는데 이미 카트에 들어 있습니다... 그리고 사람이 당신에게 뭔가 문제가 있다는 것을 알게되면 완전히 다른 문제입니다 (적어도 문제가 그의 편이 아니라는 것은 분명합니다). 문제가 발견되어 이미 작업 중이며 대략적인 수정 시간을 적어 두었을 수도 있습니다. 사용자는 문제가 해결되면 구독하고 이메일 알림을 받을 수 있으며 원하는 대로(냉장고 구입) 할 수 있습니다.

문제와 다운타임은 누구에게나 발생합니다. 그러나 사용자와 파트너는 이에 대한 접근 방식에 있어서 보다 투명하고 책임감 있는 사람들을 더 신뢰합니다.

여기에 상태 페이지를 생성할 수 있는 10개의 다른 프로젝트 검토. 다음은 이러한 프로젝트 페이지의 모양에 대한 예입니다. Python и 드롭 박스. okrr 상태 페이지.

장애 조치

글이 더 길어지지 않기 위해 이전 글을 다시 한번 참고하겠습니다. 웹 사이트에 대한 간단한 장애 조치 . 중복 서버를 만들 수 있고 장애 조치를 사용하면 기본적으로 가동 중지 시간이 길지 않습니다. 문제가 감지되는 즉시 사용자는 자동으로 작동 중인 백업 서버로 리디렉션됩니다. 그리고 이것은 어디에서도 거의 사용할 수 없는 매우 흥미롭고 밝은 기능인 것 같습니다.

낮은 시스템 요구 사항

okrr 서버의 경우 RAM이 2GB 이상인 시스템을 사용합니다. 네트워크 센서의 경우 512Mb이면 충분합니다. 클라이언트 부분은 일반적으로 거의 XNUMX입니다. (비닐 봉투 확인 업데이트 무게는 26Kb이지만 Python3 및 표준 라이브러리가 필요합니다. 클라이언트는 cron 스크립트에서 실행되므로 지속적인 메모리 소비가 없습니다. 우리가 모니터링한 기계 중에는 센서(512Mb RAM을 갖춘 매우 저렴한 VPS)와 Raspberry Pi가 있습니다. 클라이언트 부분이 없어도 가능합니다 컬을 통해 업데이트 보내기! (아래 참조)

이것을 고려하면 아마도 okrr 일 것입니다. 가장 무료 Zabbix나 Nagios와 같은 다른 무료 오픈 소스 시스템을 사용하더라도 여기에 리소스(서버)를 할당해야 하는데 이것이 이미 돈이기 때문입니다. 또한 일부 서버 유지 관리가 여전히 필요합니다. okrr을 사용하면 이 부분을 제거할 수 있습니다. 또는 가장 마음에 드는 것에 따라 이를 제거하고 자체 서버를 사용할 필요가 없습니다.

API 및 독점 소프트웨어로의 통합

단순하고 개방적인 아키텍처. okrr에는 꽤 간단한 것이 있습니다 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

클라이언트 모듈이 없어도 컬을 통해서만 표시기를 업데이트할 수 있습니다.

# 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/

프로그램에서 직접 표시기를 업데이트할 수 있습니다. 예를 들어, okrr이 실행 중임을 알 수 있도록 하트비트 신호를 보내고 충돌하거나 멈춘 경우 경보를 발생시킵니다. 그건 그렇고, 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))

Python 프로그램에서 표시기를 업데이트하기 위한 라이브러리가 있습니다. 확인 업데이트, 다른 언어의 경우 라이브러리가 없지만 okerrupdate 스크립트를 호출하거나 okerr 서버에 HTTP 요청을 할 수 있습니다.

okrr이 우리를 돕는 방법

오커는 우리의 삶을 변화시켰습니다. 물론. 아마도 다른 모니터링 시스템도 동일한 작업을 수행할 수 있지만 oker를 사용하여 작업하는 것은 우리에게 쉽고 간단하며 필요한 모든 기능을 갖추고 있습니다(없었던 기능을 추가했습니다). 그런데 누락된 기능이 있으면 물어보세요. 추가하겠습니다. (약속하지는 않지만 okrr이 중소 규모 프로젝트에 가장 적합한 모니터링 시스템이 되기를 바랍니다.) 아니면 직접 추가하는 것이 더 좋습니다. 쉽습니다.

우리는 "케라의 모든 문제에 대해 배운다"는 원칙에 따라 생활했습니다. okrr에서 알지 못한 문제가 갑자기 발생하면 okrr에 검사를 추가합니다. (이 경우 "우리"는 공동 개발자가 아닌 시스템 사용자를 의미합니다.) 처음에는 이런 일이 흔했지만 지금은 매우 드물어졌습니다.

모니터링

okrr을 통해 우리는 모든 서버의 로그 크기를 모니터링합니다. 물론 눈으로 로그의 모든 줄을 신중하게 읽는 것은 불가능하지만 단순히 성장률을 모니터링하는 것만으로도 이미 많은 것을 얻을 수 있습니다. 이를 통해 우리는 스팸 메일링과 무차별 암호 검색을 발견했으며, 일부 응용 프로그램이 "미친" 경우 문제가 발생하여 계속해서 반복합니다(로그에 몇 줄을 추가할 때마다). ).

SSL 인증서. 출시되자마자 거의 바로 LetsEncrypt 우리 고객은 클라이언트(약 천 개)에게 무료 SSL 인증서를 제공하기 시작했습니다. 그리고 그것은 행정에 있어서 지옥으로 판명되었습니다! 사실은 사이트가 "라이브" 상태이고 클라이언트가 정기적으로 사이트에 무언가를 요청하면 프로그래머가 이를 수행한다는 것입니다. 예를 들어 사이트를 다른 DocumentRoot로 완전히 자유롭게 전송할 수 있습니다. 또는 virtualhost 구성에 무조건 재작성을 추가하십시오. 당연히 그 후에는 인증서 자동 갱신이 중단됩니다. 이제 패키지의 또 다른 유용한 유틸리티를 통해 자동으로 모든 SSL 호스트가 okrr에 추가되었습니다. a2conf. 그냥 발사하자 a2okerr.py — 서버에 여러 개의 새로운 사이트가 나타나면 자동으로 oker에 나타납니다. 어떤 이유로 갑자기 인증서가 갱신되지 않으면 인증서가 만료되기 XNUMX주 전에 우리는 이를 알고 있으며 왜 업데이트되지 않는지 알아낼 것입니다. a2certbot.py 동일한 패키지에서 - 이것에 많은 도움이 됩니다(가장 가능성이 높은 문제를 즉시 확인하고 잘 확인된 내용과 문제가 있을 가능성이 가장 높은 위치를 기록합니다).

우리는 모든 도메인의 만료 날짜를 모니터링합니다. 또한 메일을 보내는 모든 메일 서버는 50개 이상의 다양한 블랙리스트와 비교하여 검사됩니다. (그리고 때로는 그것들에 빠지기도 합니다). 그런데 구글 메일 서버도 블랙리스트에 올라 있다는 사실을 알고 계셨나요? 자체 테스트를 위해 모니터링되는 서버에 mail-wr1-f54.google.com을 추가했는데 여전히 SORBS 블랙리스트에 있습니다! (이것은 "스패머 방지"의 가치에 관한 것입니다)

백업 - 나는 이미 okrr로 백업을 모니터링하는 것이 얼마나 쉬운지 위에서 썼습니다. 하지만 우리는 서버의 최신 백업과 Amazon Glacier에 업로드하는 백업(oker를 사용하는 별도의 유틸리티 사용)을 모두 모니터링합니다. 그리고 그렇습니다. 때때로 문제가 발생합니다. 그들이 지켜보고 있었던 것도 당연합니다.

우리는 에스컬레이션 표시기를 사용합니다. 어떤 문제가 오랫동안 해결되지 않았는지 보여줍니다. 그리고 나 자신도 어떤 문제를 해결할 때 때때로 그 문제를 잊어버릴 수 있습니다. 에스컬레이션은 자신을 모니터링하는 경우에도 좋은 알림이 됩니다.

전반적으로 우리 작업의 질이 한 단계 더 높아졌다고 생각합니다. 다운타임이 거의 없고(클라이언트가 눈치챌 시간도 없고 그냥 쉿!), 작업량이 줄어들고 작업 환경도 차분해졌습니다. 우리는 테이프로 구멍을 메우는 비상작업에서 많은 문제를 미리 예측하고 예방할 시간이 있는 차분하고 신중한 작업으로 전환했습니다. 발생한 문제도 수정하기가 더 쉬워졌습니다. 첫째, 고객이 패닉에 빠지기 전에 문제에 대해 알아내고, 둘째, 문제가 최근 작업과 관련된 경우가 종종 발생합니다(한 가지 작업을 수행하는 동안 다른 작업이 중단되었습니다). 그래서 뜨겁습니다. 흔적이 처리하기가 더 쉽습니다.

그런데 또 다른 사건이 있었는데..

인기 있는 Debian 9(Stretch)에서 phpmyadmin과 같은 인기 패키지가 여전히 (수개월 동안!) 취약한 상태에 있다는 것을 알고 계셨습니까? (CVE-2019-6798). 취약점이 나타났을 때 우리는 이를 다양한 방식으로 신속하게 처리했습니다. 하지만 언제 "아름다운" 솔루션이 나올지 알기 위해 oker의 보안 추적 페이지 모니터링을 설정했습니다(콘텐츠의 SHA1 합계를 통해). 표시기가 여러 번 깜박이고 페이지가 변경되었지만 보시다시피 2019년 XNUMX월 이후에도 여전히 문제가 해결되었음을 나타내지 않습니다. 그런데 이렇게 중요한 패키지가 XNUMX년 넘게 여전히 취약하다는 문제가 무엇인지 아는 사람이 있을까요?

비슷한 상황이 또 발생했습니다. SSH의 취약점 이후 모든 서버를 업데이트해야 했습니다. 그리고 작업을 설정할 때 실행을 제어해야 합니다. (부하들은 오해하고, 잊어버리고, 혼란스러워하고, 실수하는 경향이 있습니다.) 따라서 먼저 모든 서버의 okrr에 SSH 버전 확인을 추가했고, okrr을 통해 업데이트가 모든 서버에 출시되었는지 확인했습니다. (편리합니다! 이 유형의 표시기를 선택했는데 어떤 서버에 어떤 버전이 있는지 즉시 확인할 수 있습니다.) 모든 서버에서 작업이 완료되었다고 확신하면 표시기를 제거했습니다.

특정 문제가 발생했다가 저절로 사라지는 상황이 몇 번 발생했습니다. (아마도 모두에게 친숙할까요?) 당신이 알아차릴 때쯤에는, 확인할 것이 아무것도 없을 때쯤에는 모든 것이 이미 잘 작동하고 있는 것입니다. 그런데 또 또 깨집니다. 예를 들어 Amazon Marketplace(MWS)에 업로드한 제품에서 이런 일이 발생했습니다. 어떤 시점에서 로드된 재고가 잘못되었습니다(상품 수량 및 가격이 잘못됨). 우리는 그것을 알아 냈습니다. 하지만 그것을 파악하기 위해서는 문제를 바로 알아내는 것이 중요했습니다. 아쉽게도 MWS는 모든 Amazon 서비스와 마찬가지로 조금 느리기 때문에 항상 렉이 있었지만 그래도 문제와 문제를 일으키는 스크립트 사이의 연관성을 최소한 대략적으로 파악할 수 있었습니다. okrr에 연결하고 즉시 경고를 받아 확인했습니다.)

최근 우리 고객이 사용하는 크고 값비싼 유럽 호스팅 업체가 흥미로운 사례를 컬렉션에 추가했습니다. 갑자기 모든 서버가 레이더에서 사라졌습니다! 첫째, 고객 자신이 (okerra보다 빠릅니다!) 자신이 작업하고 있는 사이트가 열리지 않는 것을 발견하고 이에 대한 티켓을 만들었습니다. 하지만 한 사이트만 다운된 것이 아니라 모든 사이트가 다운되었습니다! (나타샤, 우리는 모든 것을 버렸어요!) 여기에서 Okerr는 자신에게 불이 켜진 모든 지표가 포함된 긴 발 랩을 보내기 시작했습니다. 공황, 공황, 우리는 원을 그리며 달립니다(그 밖에 무엇을 할 수 있습니까?). 그런 다음 모든 것이 상승했습니다. 데이터 센터에는 정기적인 유지 관리(수년에 한 번)가 있었던 것으로 밝혀졌으며 당연히 경고를 받아야 했습니다. 하지만 그들에게 어떤 문제가 발생했는데 그들은 우리에게 경고하지 않았습니다. 음, 심장마비가 더 많이 발생하고 심장마비가 덜 발생합니다. 하지만 모든 것이 복원된 후에는 모든 것을 다시 확인해야 합니다! 내 손으로 어떻게 했을지 상상이 안 가네요. Okerr는 몇 분 안에 모든 것을 테스트했습니다. 대부분의 서버는 일시적으로 사용할 수 없지만 작동하는 것으로 나타났습니다. 일부는 과부하가 걸렸지만 역시 그래야 하는 대로 일어섰습니다. 모든 손실 중에서 우리는 두 개의 백업을 잃었습니다. 왕관에 따르면 이 백업은 전체 바나나가 진행되는 동안 생성되고 로드되어야 했습니다. 나는 그것을 만드는 데 신경 쓰지도 않았고 하루 만에 모든 것이 정상이고 백업이 나타났다는 경고가 도착했습니다. 나는 이 예를 정말 좋아합니다. 왜냐하면 okrr은 우리가 사전에 생각조차 하지 않았던 상황에서 매우 유용하다는 것이 밝혀졌기 때문입니다. 그러나 그것이 모니터링의 목적입니다. 즉 예측할 수 없는 것에 저항하는 것입니다.

Okerr 센서의 경우 가장 저렴한 호스팅을 사용합니다(품질과 신뢰성이 중요하지 않은 경우 서로를 보장합니다). 그래서 우리는 최근 매우 좋은 호스팅과 매우 저렴한 것을 발견했습니다. 벤치마크는 정말 훌륭합니다. 하지만... 때로는 가상 머신에서 나가는 연결이 다른(이웃) IP에서 이루어지는 경우가 있습니다. 기적. Client_ip 모듈 https://diagnostic.opendns.com/myip 잘못된 IP를 얻습니다. 그리고 표시기의 서버 로그를 보면 업데이트도 이 인접 IP에서 나온 것이 분명합니다. 이제 지원을 다루겠습니다. 평시에 이것을 알아 차려서 다행입니다. 그러나 예를 들어 IP 화이트리스트에 따라 액세스가 등록되는 경우가 종종 발생하며 서버가 때때로 이렇게 짧은 시간 동안 깜박이는 경우 매우 오랫동안이 문제를 포착하려고 노력할 수 있습니다.

글쎄요, 한 가지 더 – VPS 호스팅에 대해 이야기하고 있기 때문에 우리는 항상 저렴한 호스팅(hetzner, ovh, scaleway)을 사용합니다. 벤치마크와 안정성 측면에서 정말 마음에 듭니다. 우리는 또한 다른 프로젝트에 훨씬 더 비싼 Amazon EC2를 사용합니다. 그래서 okrr 덕분에 우리는 우리 자신의 의견을 갖게 되었습니다. 둘 다 넘어진다. 그리고 오랜 관찰 기간 동안 hetzner와 같은 저렴한 호스팅이 EC2보다 눈에 띄게 덜 안정적인 것으로 판명되었다고는 말하지 않겠습니다. 그러므로 다른 Amazon 기능에 묶여 있지 않다면 왜 더 많은 비용을 지불합니까? 🙂

다음은 뭐지?

이 단계에서 아직 Okerr로부터 겁을 먹지 않았다면 시도해 보세요! 해당 링크로 바로 이동하실 수 있습니다 oker 데모 계정 (지금 클릭하세요!) 하지만 모든 사람에게 하나의 데모 계정만 있으므로 귀하가 무언가를 하면 동일한 계정에 있는 다른 사람이 동시에 귀하를 방해할 수 있다는 점을 명심하십시오. 또는 (더 나은) 링크를 통해 등록하십시오. 오프사이트 오케르 - SMS 없이 모든 것이 간단합니다. 실제 이메일을 사용하고 싶지 않다면 mailinator와 같은 일회용 이메일을 사용할 수 있습니다. getnada.com). 이러한 계정은 시간이 지남에 따라 삭제될 수 있지만 테스트에는 문제가 없습니다.

등록 후에는 교육을 받아야 합니다(별로 어렵지 않은 몇 가지 교육 작업 수행). 초기 제한은 매우 작지만 교육이나 단일 서버에는 충분합니다. 훈련을 완료하면 한도(예: 최대 지표 수)가 늘어납니다.

문서에서 - 우선 위키 서버 측과 클라이언트(오케르업데이트 위키). 하지만 불분명한 점이 있으면 okrr.com 지원팀에 편지를 보내거나 티켓을 남겨주세요. 모든 것을 신속하게 해결하도록 노력하겠습니다.

심각하게 사용하고 있는데 이러한 증가된 제한이 충분하지 않은 경우 지원팀에 문의하시면 (무료로) 늘려드리겠습니다.

귀하의 서버에 okrr 서버를 설치하시겠습니까? 여기 okrr-dev 저장소. 깨끗한 가상 머신에 설치하는 것이 좋습니다. 그런 다음 설치 스크립트를 사용하여 간단히 설치할 수 있습니다. 가상 머신에서는 제한이 없습니다 :-). 다시 한 번 말씀드리지만, 무슨 일이 생기면 항상 도와드리도록 노력하겠습니다.

우리는 이 프로젝트가 성공하여 우리 덕분에 세상이 더욱 신뢰할 수 있게 되기를 바랍니다. 무료 소프트웨어와 서비스 덕분에 세상은 더욱 친근해졌고, 더욱 역동적으로 발전하고 있습니다. 소스는 무료 github에 저장할 수 있으며 메일의 경우 무료 Gmail을 사용할 수 있습니다. 우리는 무료로 사용합니다 신선한 작품 지원을 위해. 이 중 어떤 경우에도 서버 비용을 지불할 필요가 없고, 다운로드 및 구성할 필요도 없으며, 다양한 운영 문제를 해결할 필요도 없습니다. 모든 새 프로젝트, 모든 팀에는 즉시 메일, 저장소 및 CRM이 있습니다. 그리고 이 모든 것은 매우 높은 품질이며 무료이며 즉시 제공됩니다. 우리는 모니터링에도 동일하기를 원합니다. 소규모 회사와 프로젝트는 okrr을 무료로 사용할 수 있으며 심지어 탄생과 성장 단계에서도 성인 진지한 프로젝트의 신뢰성을 갖습니다.

출처 : habr.com