웹 애플리케이션 모니터링 모범 사례

웹 애플리케이션 모니터링 모범 사례

---

웹 애플리케이션을 마무리하고 배포를 계획하고 있습니다. 프로덕션 배포에서 매우 중요한 측면은 시스템 상태를 모니터링하는 것입니다. 소규모의 개발자 / 지원 팀을 보유하면 잠재적 인 문제에 대한 조기 알림 을 받고 사용자에게 영향을 미치기 전에 해결하는 것이 매우 중요 합니다.

Nagios 솔기를 좋은 옵션처럼 사용하지만 일반적으로 웹 애플리케이션, 특히 Django 앱을위한 최상의 모니터링 도구 / 관행에 대해 더 많은 의견을 얻고 싶습니까? 또한 명백한 CPU, 메모리, 디스크 공간, 데이터베이스 연결을 제외하고 모니터링해야 할 사항에 대한 권장 사항을 환영합니다.

우리의 웹 앱은 Django로 작성되었으며 PostgreSQL 데이터베이스를 사용하는 Apache + Fast CGI에서 Linux (Ubuntu)에서 실행됩니다.

편집 우리는 Linode 아래에 완전히 가상화 된 환경을 가지고 있습니다.

편집 우리는 django-logging을 사용하고 있으므로 별도의 정보, 오류, 중요한 문제 등이 있습니다.

---

Nagios는 훌륭합니다. 시스템 테스트 (Selenium)를 정기적으로 실행하는 것이 좋습니다.

편집 : Hyperic 및 Groundwork 도 흥미로워 보입니다.

압력 테스트를 계속할 수있는 테스트 스위트 시스템이있을 것입니다. 나는 내 머리 꼭대기에서 이름을 기억할 수 없습니다. 누군가 아래에 언급 할 수있을 것입니다.

내가 좋아하는 다른 일 :

인프라에 대한 최고의 모토는 항상 수정, 감지, 수리입니다. 일어나서 뿌리를 찾아서 가능하면 치료 / 예방하세요.

시스템은 여러 수준에 존재하므로 여러 수준에서 테스트해야합니다.

편집 : 모든 오류 또는 경고를 이메일을 통해 케이스 관리자에게 직접 게시합니다. 이렇게하면 한 곳에서 발생을 추적 할 수 있습니다.

1) 연결 : 서버와 외부에서 인터넷 연결을 모니터링합니다. 어딘가에 기록

2) 서버 : 실행 중인지 확인하고 서버를 고정하는 데 필요한 모든 프로세스를 모니터링합니다. HP 서버 또는 BIOS 수준에서 수행 할 수있는 하드웨어 오류 알림과 동등한 것을 사용합니다. 그럴 경우 통보하고 기록하십시오.

3) 소프트웨어 : 항상 실행해야하는 핵심 소프트웨어를 식별합니다. 성능 수준을 설정 한 다음 모니터링합니다. Nagios가 도움을 줄 수있을 것입니다. 창문에서는 조금 더 많을 수 있습니다. 예외가 발생하면 스크립트를 실행하여 프로세스를 자동으로 다시 시작할 수 있어야합니다. 내 꿈의 시스템은 서버가 허용해야하는 예외로 간주하거나 SMS로 취소하지 않는 한 자동으로 발생하는 예외로 서버가 인식하면 SMS를 통해 서버와 상호 작용할 수 있습니다. 언젠가 ..

4) 원격 전원 : 원격 전원 재설정 기능이 당신의 손에 있는지 확인하십시오. Windows를 사용하는 경우 매주 재부팅을 예약 할 수 있습니다.

5) 비즈니스 로직 테스트 : 시스템의 워크 플로를 테스트하는 스크립트를 정기적으로 실행합니다. Selenium은 아마도이 중 일부를 달성 할 수 있지만 결과를 로깅하여이 시간에 실행되었으며 이러한 파일에 오류가 있다고 말하는 것을 좋아합니다. 가능하면 시스템이 스크립트를 통해 자체 모니터링하도록하십시오.

6) 백업 : 설정하고 잊을 수있는 백업을 만듭니다. 가상 머신으로 사물을 가져올 수 있다면 인프라의 모든 부분을 확장, 이동 또는 배포 할 수 있기 때문에 이상적 일 것입니다. 문제를 해결하는 동안 죽은 서버를 랩톱으로 옮긴 경우 VM웨어에서 실행되도록 두었습니다.

---

웹 서버와 데이터베이스에 대한 연결 수를 모니터링하는 것도 추적 할 수있는 또 다른 좋은 방법입니다. 지붕을 뚫고 쏘면 무언가 자원이 부족하고 사이트가 무너질 가능성이 있습니다.

또한 시스템에 대한 합리적인 종단 간 테스트 인 URL에 대한 정기적 인 요청이 있는지 확인하십시오. 사이트가 검색을 지원하는 경우 nagios가 검색을 실행하도록합니다. 검색 색인이 정상인지, 웹 서버 및 데이터베이스 서버가 올바른지 확인해야합니다.

또한 사용자에게 오류가 표시되거나 처리되지 않은 예외가있을 때마다 애플리케이션에서 이메일을 보내야합니다. 이렇게하면 현장에서 애플리케이션이 어떻게 실패하는지 알 수 있습니다.

---

한 가지 유형의 테스트를 선택해야한다면 시스템의 최종 사용자 기능을 테스트하는 것입니다. 고려해야 할 중요한 것은 사용자입니다. 데이터베이스 가용성, 서버 가동 시간 등과 같은 테스트가 모두 중요하지만 원격 UI 테스트 시스템을 통해 시스템을 통한 워크 플로 테스트는 이러한 모든 기반을 다룹니다. 최종 사용자가 시스템의 중요한 부분을 사용할 수 있다는 것을 알고 있다면 시스템이 거의 정상임을 알 수 있습니다.

1. 시스템의 중요한 워크 플로우를 식별하십시오. 예를 들어, 전자 상거래 사이트를 작성한 경우 "제품 검색, 장바구니에 제품 담기 및 제품 구매"의 워크 플로우를 식별 할 수 있습니다.
2. 워크 플로의 우선 순위를 정하고 우선 순위가 더 높은 테스트를 먼저 구축하십시오. 프로덕션으로 롤아웃 한 후 언제든지 추가 테스트를 추가 할 수 있습니다.
3. 사용 가능한 UI 테스트 프레임 워크 중 하나를 사용하여 UI 테스트를 빌드합니다. 자동화 된 방식으로 실행할 수있는 많은 무료 및 상용 UI 테스트 프레임 워크가 있습니다. 중요한 워크 플로우를 해결하는 핵심 테스트 세트를 먼저 구축하십시오.
4. 테스트를 실행할 원격 위치를 하나 이상 설정하십시오. 시스템의 모든 측면을 테스트하려고합니다. 즉, 원격으로 테스트해야합니다. 인터넷에 연결되어 있습니까? 웹 서버가 실행 중입니까? 데이터베이스 서버에 대한 연결이 작동합니까? 기타 등등. 원격으로 테스트하는 경우 시스템을 외부에서 사용할 수 있는지 확인해야합니다. 즉, 시스템이 종단 간 작동 할 가능성이 가장 높습니다. 이러한 테스트를 내부적으로 실행할 수도 있지만 외부에서 실행하는 것이 중요하다고 생각합니다.
5. 솔루션에보고 및 알림이 모두 포함되어 있는지 확인하십시오. 중요한 워크 플로 테스트 중 하나가 실패하면 다른 사람이 문제를 최대한 빨리 해결하도록 알려야합니다. 중요하지 않은 작업이 실패하는 경우 대역 외에서 문제를 해결할 수 있도록보고 만 할 수 있습니다.

이 최종 사용자 테스트는 데이터 센터의 시스템 모니터링을 제거해서는 안되지만 최종 사용자 테스트는 웹 애플리케이션에 대해 수행 할 수있는 가장 중요한 테스트 유형이라는 점을 반복하고 싶습니다.

---

Ahhh, 모니터링. 내가 당신과 당신의 진동을 새벽 3시에 얼마나 사랑하는지.

기본적으로 애플리케이션의 내부 상태를 검사 할 수있는 방법이 필요합니다. 특정 순간뿐만 아니라 일정 기간 동안 (후자는 문제가 발생하기 전에 감지하는 데 매우 중요합니다). 그것을 생각하는 또 다른 방법은 영광스러운 단위 테스트입니다.

자체 (매우 멋진) 모니터링 시스템이 있으므로 Nagios 나 다른 앱에 대해 언급 할 수 없습니다. 우리의 사용 사례는 귀하의 사례와 유사합니다 (아파치의 cgi 앱).

1. 정보를 디스크에 기록하는 logging.monitor () 유형 메서드를 추가합니다. 이것은 최소한 간단한 숫자와 숫자 사전 기록을 지원해야합니다 (키 => 값 연결은 매우 편리 할 수 ​​있습니다).
2. 모니터링 로그를 스크 레이 핑하여 데이터베이스에 저장하는 프로세스가 있습니다.
3. 데이터베이스 정보를 가져 와서 규칙과 비교하여 확인하고 경고를 보내는 프로세스가 있습니다. 무언가가 벗겨 질 수 있음을 명심하십시오. 한 번 404를 받았다고 해서 앱이 다운되는 것은 아닙니다.
4. 알림을 음소거하는 방법이 있습니다 (유지 관리 또는 이메일 읽기에 매우 유용함).

그것은 모두 꽤 높은 수준입니다. 중요한 것은 시간이 지남에 따라 응용 프로그램의 상태에 대한 기록이 있다는 것입니다. 그런 다음 "초당 쿼리가 두 배가되면 SlashDotted 경고를 보내십시오."또는 "응답의 50 %가 404 인 경우 경보". 또한 업, 다운, 빠르거나 느린 지에 대한 의견을 정량화 할 수 있기 때문에 관리가 눈에 띕니다.

모니터링 할 항목에는 http 상태, 포트 액세스 가능, http로드, 데이터베이스로드, 열린 연결, 쿼리 대기 시간, 서버 액세스 가능성 (ssh, ping), 초당 쿼리, 작업자 프로세스 수, 오류 비율 , 오류율.

Simple end-to-end tests are also very handy, though they can be brittle. Its best to keep them simple, but you should have one that tries to touch core pieces of the app (caching, database, authentication).

---

I use Munin and Monit, and have been very happy with both of them.

---

Internal logging is fine and dandy but when your whole app goes down or your box/enviro crashes you need an outside check too. http://www.pingdom.com/ has been very reliable for me.

My only other advice is I wouldnt spent too much time on this. my best example is twitter, how much energy did they put into the system being able to half-die instead of just investing that time and energy into throwing more hardware / scaling it out.

Chances are what ends up taking you down, your logging and health systems will have missed anyway.

---

The single most important way to monitor any online site is to monitor externally. The goal should be to monitor your site in a way that most closely reflects how your users use the site. In 99% of cases, as soon as you know that your site is down externally, it's relatively easy to find the root cause. The most important thing is to know as soon as possible that your customers are unable to load your site.

This generally means using an external performance monitoring service. They very from the very low end (mon.itor.us, pingdom) to the high end (Webmetrics, Gomez, Keynote). And as always, you get what you pay for. The things to look for when shopping around for a monitoring service include:

• The size and distribution of the monitoring network
• Whether or not the monitoring solution is able to monitor your site using a real browser (otherwise you aren't testing your site like a real user would)
• The scripting language (to script the transactions against your site)
• The support department, to help you along the way, and provide expertise on how to monitor correctly

Good luck!

---

Web monitoring by IP Patrol or SiteSentry have been useful for us. The second is a bit like site confidence but slightly prettier lol.

---

Have you thought about monitoring the functionality as well? A script (either in a scripting language like Perl or Pyton or using some tool like WebTest) that talks to your application and does some important steps like logging in, making a purchase, etc is very nice to have.

---

Aside from what to monitor, which has already been answered, you need to make sure - whatever system you use - that you get only one notification of an error that happens multiple times, on each request. Or your inbox will run out of memory :) Plus, it's plain annoying...

Divide the standby shifts among the support/dev team, so one person does not have to be on call every single evening. That will wear people down. Monitoring is a good thing, but everyone needs to get a chance to have a life once in a while. Your cellphone buzzing at 2AM for a few nights will get very old pretty soon, trust me. And not every developer is used to 24/7 support, so you need to find the balance between using monitoring and abusing monitoring.

Basically, have distinct escalation levels, and if the sky is not falling, define a "serenity now" window at night where smaller escalation levels don't go out.

---

I've been using Nagios + CruiseControl + Selenium for running high-level tests on mission critical web applications. I got burned pretty hard by a simple jquery error that stopped users from proceding through an online signup form.

http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/

---

You can take a look at AlertGrid. This web application allows you to filter and forward alerts to your team (worldwide). It has also nice ability to monitor if something did not happen.

---

To paraphrase Richard Levasseur: ah, monitoring tools, how your imperfections frustrate me. There doesn't seem to be a perfect tool out there; Nagios is pretty easy to set up but the UI is kinda old fashioned and you have to have a daemon running on each server being monitored. Zenoss has a much nicer UI including trend graphs of resource usage, but it uses SNMP so you have to have some familiarity with that to get it working properly, and the documentation is not the best - there are hundreds of pages but it's really hard to find just the info you need to get started.

Friends of mine have also recommended Cacti and Hyperic, but I don't have personal experience with those.

One last thing - one of the other answers suggested running a tool that stresses your site. I wouldn't recommend doing that on your live site unless you have a reliable quiet period when nobody is hitting it; even then you might bring it down unexpectedly. Much better to have a staging server where you can run load tests before putting changes into production.

---

One of our clients uses Techout (www.techout.com) and is very pleased with the service.

There is no charge for alerts, no matter what kind or how many, and they offer email, voicemail and SMS alerts -- and if something major happens, a phone call from a live person to help you out.

It's all based on service -- you don't install the software and you have a consultant who works with you to determine the best approach for your business. It's one of the most convenient web application monitoring services because they take care of everything.

---

I would just add that you can predict error likelihood somewhat based on history of past errors and having fixed them. With smaller scale internal testing if you were to graph the frequency and severity of problems that have been corrected to this point you'll have an overview of predictable new problems. If everything has been running error free for some time now, then the two sources of trouble would be recent changes or scalability issues.

From the above it sounds like scalability is your only worry, but I just mention the past-error frequency test because the teams I've been on invariably think they got the last error fixed and there are no more. Until there is.

---

Changing the line a little bit, something I really think is useful and changed a lot how I monitor my apps is to log javascript exceptions somewhere. There's a very nice implementation that logs that directly from user browsers to Google Analytics. This is a must for Javascript centered web applications, and can give you results based directly on users browsers what can lead to very unexpected errors (iE and mobile browser are pain)

Disclaimer: My post bellow

http://www.directperformance.com.br/en/javascript-debug-simples-com-google-analytics

---

For the internet presence monitoring, I would suggest the service that I am working on: Sucuri NBIM (Network-based integrity monitor).

It does availability and integrity checks, looking for changes on your internet presence (sites, DNS, WHOIS, headers, etc) and loss of connectivity. It is free and you can try it out here.

참고URL : https://stackoverflow.com/questions/495985/web-application-monitoring-best-practices